We had a visitor the other day at Bizbrains’ Vejle office. The visitor was Martin Michael Frederiksen, who works with e-commerce and has done a lot of interesting things that he wanted to tell us more about.
We will definitely be working together and planning events in the future (stay updated on our blog for this).
Martin left a book with the title “The CEO’s guide to IT projects that must not go wrong”. I’ve read it and if you’re facing a new IT project – or facing challenges concerning a current project, then I’ll highly recommend that you read it as well.
Here’s a brief summary to convince you why:
It’s not an all technical nerdy book because it actually gives good advice to leaders who are in charge of IT (and that’s all leaders who use IT in their departments according to the book – not just the head of the IT department).
The book is simply a gold mine full of educational and visual explanations to advanced problems.
For example, a description of a case with an IT project for an eyeglass production company, where an old system needs further development, is described by using pictures of an old but exciting house and an opera house, and it immediately makes perfectly sense why the one solution is better than the other.
Another good example is when the difference between frontend and backend is described with a picture of an iceberg. The picture shows how everything can look fine above the water, but it can be a whole other story underneath where the level of pollution is much bigger than you think .
All the chapters throughout the book contain short stories. Some of these stories are anecdotes, like one about a company that ended up with 14 different search features on the same site. Another short story is the one about my two favorite patterns in the whole world: “Separation of concerns” and “loosely coupled architecture”. All these short stories are good entertainment and gives you a little break from the more focused sections of the book:
Every section has a theme which is summarized on the very last page of the book.
"Simplicity is a prerequisite for reliability."
Bet on partnerships
In the first section, which is about strategy, the author gives a number of tips that all deal with the topic of simplicity.
One of the best advices, if you ask me, is that one must not believe that a project can be described and delivered according to specifications.
Instead, he recommends that you as a customer make a partnership with the supplier, so that you can be on the same page instead of going into a counterproductive war against each other along the way. I very much agree with this point of view, but I also know that it can be very difficult to reach such level of trust in a short amount of time, if it’s a supplier that you haven’t worked with before.
At Bizbrains, we always help our new customers by showing great confidence from the very beginning. For example, we may offer free trials on products, offer refunds on dissatisfaction, or something else.
I am not mentioning this to advertise our own business, but to emphasize that trust issues between customers and suppliers is a real problem, which you can overcome by showing that you’re open and approachable and by giving the supplier some extra benefits – show them that you want to reach out and invest in a good relationship.
The right values
Later on in the governance section, the argument for simplicity continues. For example, with points that the business must include IT in its strategies from the very beginning. Something that seems obvious, but which we have all experienced, is missing every time.
The author recommends agile methods in all the sections of the book (the examples are primarily taken from Scrum). Scrum, and other agile methods, require trust from both customer and supplier, which is something that you have to invest in massively when you start building a new project together.
Focus on results instead of getting stuck in formalities and execute small high-quality stages rather than doing a whole lot of development before testing and quality control – thus avoiding the false security that may appear to be comply with the plan, in terms of implemented features.
- Individuals and interaction are valued higher than processes and tools.
- Functioning software is valued higher than comprehensive documentation.
- Collaboration is valued higher than contract negotiations.
- Responding to change is more important than sticking to the plan.
Trust, trust, trust
The section on execution illustrates the benefits of agile estimation with a picture of the task “digging a trench 10 meters long”. The point is that from the start you cannot know how long it will take you to dig all 10 meters, but once you have dug one meter you can make a more qualified bid -similar to agile estimation methods. This is something that can be very difficult for customers to accept at first, because many are used to the old-fashioned methods where you highly value the fact that time, content, and price can be predicted with great accuracy before you start.
Just as in the section on governance, this section also emphasizes the importance of trust between customer and supplier in the everyday life where execution takes place. A good example of this could be that the software buyers must not push the supplier too hard when it comes to the price of a new piece of software.
Because it’s not a finished product that can be traded as a horse on a market. The supplier will throw the towel in the ring sooner or later if he ends up not being able to make a profit, and then another supplier will have to take over instead. Not only is this expensive but also a lot of trouble. Therefore: Bet on trust, and pay a reasonable price.
“Simplicity is a prerequisite for reliability” – this is the pervasive argument throughout the book. This is just as true in code and processes as it is in organizations and their collaboration.
The last chapter is a summary of all the good advice from each section. It’s so direct and cut to the bone, that we at Bizbarins had them made in posters and hung them up at all the Bizbrains leaders’ offices.
So, to sum up, I highly recommend “The CEO’s guide to IT projects that must not go wrong”.