So, you have a great idea for an application.
You’ve spent hours thinking over each and every single detail. Or maybe you just have an initial vision that you’d like to bring to life. You’ve prepared a presentation that has been approved either by investors or by your management. You have made some people follow your idea. It seems that you can make some good stuff out of this vision: improve a process in your company, ease your colleagues’ tasks or simply change the world if you were creative enough to build something with the market potential of Facebook, Twitter or LinkedIn (or smaller, but equally impressive).
Who to engage?
It all looks great, you’re certain it’s going to work, but – unless you’re a coder yourself – someone still needs to do it. Obviously, no matter if you’re a start-up, a self-made man or woman, an investor, or a corporate warrior fighting for a share in next year’s budget, you’d surely like to know how much it is going to cost, and of course why it will be so expensive.
So you start searching for software houses and asking around:
“Hey, how much would it be for this app?”
It may come as a surprise to you, but almost nobody is willing to simply say:
“Well, that will be XYZ EUR, and we will finish in ABC weeks”. Instead, they will start giving you some “engineering hours”, “development outsourcing” and other stuff, which just contradicts the common sense of any buyer in the world. Why on earth should you pay someone by the hour of their service if you simply need a product done? Another option which you may encounter is an estimation which is triple of what you thought it would be, or even a question which you may find rude: “Tell me what your budget is and I’ll tell you how much we can theoretically do for that sum”. A bit different from buying a car or a house, isn’t it?
Why it happens? There are many reasons.
The most important one is something that project management calls the “Vasa syndrome” – there is an interesting article on Wikipedia about it here and in more details here.
Long story short: it was one of the greatest naval disasters of the 17th century, which ended up sinking the most expensive warship of the Swedish fleet roughly 1300 meters from the harbor. The direct reason was that the center of gravity was located way too high, which was caused by the installation of an additional unplanned deck with heavy cannons on it. The root cause: constant interference of a powerful stakeholder in the project management process. The King (Gustavus Adolphus of Sweden), who was the sponsor of the project, was continuously changing its scope, interfering with the details, keeping high pressure on the project team leader (Henrik Hybertsson), and from something that was supposed to be a typical shipbuilding project he made an innovative experiment of naval technology. Without having the necessary know-how, people and technology to cope with the task.
How not to be the King os Sweden?
Imagine now that the team of developers is the shipyard crew and you’re the King of Sweden. They’d love to please you and make sure you are satisfied with what they produce. But they have no idea what ideas will come to your head in the course of the project. They would also be crafting the product which – per definition – is at least partially innovative. And one more thing – please don’t forget that the King of Sweden had limitless financial resources at his disposal, and you’re coming to ask for a price, adding one more piece of uncertainty into the puzzle.
The software house, to which you’re turning to obtain the quote on “how much will it be, and how long will it take”, never knows what’s inside your head. Until they start working with you, they cannot judge if your vision is coherent and logical, and they’re also unable to assess whether – without a complex specification made upfront – they would be able to finish working on your project within X weeks. It’s just simply not that easy – the scope changes dynamically throughout the project, and every extra feature takes extra time.
I’ll tell you more: even you don’t know what’s in your head before you actually start doing it! Seeing the job being done and solutions appearing will boost your creativity enormously. I’m sure you know this feeling when some idea just pops up and “it would be such a loss not to try to squeeze it in”.
Developers’ experience shows that in the course of works you’ll come up with more and more of those or you’ll realize: “Hmmm, I imagined it differently”. Having time and budget constraints in mind, you might want to try to extend or change the scope while the development team will for sure try to defend it. And it takes a hell of a Project Manager to oppose the King of Sweden, while at the same time the King of Sweden also doesn’t like to be told that his great idea will have to wait for an indefinite period of time. If developers agree for a fixed price – they’ll try to keep you happy and implement all your wishes – but then you can imagine what is going to happen with the quality.
Just to picture it for you, project management is a delicate balance between quality, time and costs:
And stakeholders’ interferences have a tendency to follow this pattern:
But OK, let’s say that someone agrees to do your project at a fixed price. You sit together with the Business Development Manager of the software house and you try to foresee everything that your application may contain. The Business Development Manager needs to take into consideration some “cap” in his estimations. For him, you are still the King of Sweden. But at the same time, his job is to sell, so he’ll have the tendency to minimize potential obstacles on the way and offer you a decent price and if you press him hard enough, he’ll minimize the safety margin.
Both of you will want to secure yourselves at this stage, so you prepare: a backlog, a very, very, very detailed specification, a contract, service level agreements and so on. It ends up in three weeks of negotiations, some money spent on lawyers, but everyone feels secure. You put your signatures on paper, and the project can set off. Agendas are set, backlogs are ready, user stories are written, money is secured on the bank account. Hurray!!!
What can possibly go wrong from now on? The short answer is: everything, but if you’d like to see some specific examples, here they are:
- Your creativity will exceed the expectations, and you’ll want to add/change something.
- You’ll show the product to some other people for additional feedback – and they may also bring up great ideas which were not described in the initial scope.
- Your investor may say that he “imagined it somewhat differently”, and you’ll need to make the necessary adjustments.
- Someone crucial for the project may get sick, and you’ll get stuck for a longer moment without progress.
- There is something that any of the parties forgot at the planning stage – in the end, we are all just people, and IT projects are complex.
- You may need some extra time to decide on something.
- You may realize in the course of the project that there is actually no point in completing it, because i.e. someone has done it much better and has just released it.
8.The developer might not have predicted that the creation of some feature will require long research. - There will be differences in understanding when the particular feature is completed. To give you an example:
This is a login button…
…and these are the login buttons as well:
All in all: everything may go wrong, and at the same time – not everything is predictable.
Who and how to evaluate who is responsible for the projects failure? One may say: the court – but do you really want to waste your precious energy in the courtroom?
The customer is the King, indeed. But surely even the customer wouldn’t want to be Gustavus Adolphus of Sweden, and neither would a software house want to be Henrik Hybertsson (he died before the ship was completed), and no project would like to end in the “Vasa” way – with a full-scale failure immediately after the launch.
It is really much easier to work with the engineering hours model and simply trust your partner – they are right around the corner. There are companies committing to the best using the time you pay for, and once you can’t continue – they’ll click ‘pause’, and wait for you. There are companies that also won’t let you release a bad product. But just like the others – they don’t know what’s inside your head, or what may happen on the way to deliver the scope. They’re also not 100% sure if everything you imagine is doable without research or without acquiring new competences. With their expertise, they can help you figure out the best possible solution for your software, choosing from the ones which are known to them or learning new ones for you. * There are companies for whom Your success is their success.*
Sources:
1. Vasa Syndrome
2. Vasa Case Study
