Software development, value and a Pagani Zonda
Let’s pretend for a moment that you are rich enough to buy a custom-built Pagani Zonda. You go to the Pagani factory and design your perfect supercar, but you have to wait nine months to have it delivered. Suddenly, after just four months, Mr. Pagani calls you: your car is ready! What’s your reaction? Happiness, of course! You’ve had your car delivered five months in advance. Yahoo!
Now you need to create a new software product, and you have a crystal-clear idea of what you need and how to communicate it to a development firm (it’s easier to get enough money together for a couple of Zondas, but let’s pretend, OK?). You get the quotation, and you have to wait for the usual nine months. But suddenly, after four months, guess what? Your beautiful piece of software is ready. No bugs; it’s perfect, just like a custom-built Zonda. What’s your reaction here? After a second of happiness, you start wondering why the development firm overestimated your project. You think they did it on purpose to cover the risk and eventually take more money out of your pocket, or they don’t know how to do their work. In any case, you are now not so happy to pay the price you initially accepted, and you feel cheated and entitled to a discount or more features. Why?
Why will no one think of asking Mr. Pagani for a discount or more horsepower for a faster delivery, and instead will ask for more features or a discount while developing a digital product? Why does no one care if new technology was introduced in the Pagani factory that enabled faster delivery? And why, if the same happens during a development project, does it become a problem?
The key is “value.”
The Zonda has a definite value for the buyer, so it doesn’t matter how much it costs to the manufacturer or whether he finds a smart way to save some money while building it.
On the other hand, while developing a new project, usually, there’s no clue or only a very vague idea of the value of the solution being developed, and therefore, the value became the cost.
That’s the problem, because not being able to measure or estimate the value of a project generates a lot of bad things.
Here are some questions to reflect on:
How can you estimate a Return on Investment and decide if the project is worth it?
How can you set up a reasonable budget for the project?
Why should your supplier try to find a better solution and cut development efforts if he’s paid on those efforts and not on value?
At Byte-Code, we’re trying to develop a discovery and development framework that helps our customers define value clearly so we can focus on generating quality options to achieve that value as fast as we can, maximizing the Return on Investment.
If you want to know more on how we levereage interactive workshops to accellrate our customers development efforts reach out at Byte-Code website. To stay updated and recive the latest articles you can subscribe to our newsletter!
