Global Software Development: Fixed price or not? Global Software Ontwikkeling: Vaste prijs of niet?Global mjukvaruutveckling: Fastpris eller inte?Globale Softwareentwicklung: Festpreis: Ja oder nein?
Internet and software projects are often executed on a fixed price & fixed date contract. The customer outsourcing the project feels ‘protected’ against delays and misunderstandings in delivery. But are you as a customer really protected or does it make the risk of project failure only bigger? I spoke to a customer yesterday who had outsourced the development of his website to one of our competitors in the Netherlands with a branch in Asia. He had made a functional specification that covered all his needs and were clear to him. The supplier made an estimate and they agreed on a deadline. Few months ahead, the deadline wasn’t made and the result of the project was far from what he expected.
I believe the problem of using fixed price agreements, specifically in an offshore cooperation are:
1. The need to specify everything 100%
The biggest obstacle in software development is making requirements clear. Although we humans have the illusion that we’re able to specify everything upfront, it is usually not possible. Firstly, it’s very hard to think of every functionality upfront. Second, if my mind can think of everything upfront, then I should also be able to communicate this to the person who’s going to build it. And that’s also not what we’re particularly good at. The solution the software industry has come up with for this is agile software methods. But the problem is that because these methods work with incremental deliveries, it’s very hard to do this on a fixed price.
2. Who’s responsible?
The customer thinks that he has specified everything. It is clear to him what needs to be built and he is sure that everything is covered clearly in the requirements document. Now if the programmer who’s reading that document doesn’t get anything of it but still says he’ll start building it, who’s wrong? The sender or the receiver? The contract will say the receiver. But that doesn’t help the customer, because it doesn’t bring the project to an end. A more active participation from the customer is often required to finish the project, but as he’s outsourced his project, he feels that ‘all is on paper, so just do it and deliver according to our agreement’.
3. Lack of human bonding
As the project delivery is 100% the suppliers’ responsibility, the customer is usually not involved in who’s working on his project. He has sent his project into a black box and expects it to come out of that as and when agreed. To ensure (on time) delivery, a project manager will typically be the intermediary between customer and programmer. Sometimes even one onshore + one offshore. So there is no human connection between the one inventing the software and the one building it. This lack of human connection promotes misunderstanding about requirements and about people. Of course there are many projects that are delivered without any problems, but I have seen the above happen very often when projects are done on a fixed price basis.
Dear readers,In my next article I will describe the solution that I believe in. As input to that, I would like to know the suggestion of you. What model do you use? What works and doesn’t work when sending a project offshore? If you are interested to learn more about global IT staffing, Hugo recommends you to visit www.bridge-global.com
About Hugo Messer
Hugo Messer is a Dutch entrepreneur, distributed agile team specialist, and author. He is the founder and owner of Bridge Global, a software services provider, and ekipa.co., an agile coaching agency. He has been building and managing teams around the world for the past several years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. Whether it’s offshoring or nearshoring, he knows what it takes to make global cooperation work.
View all posts by Hugo Messer →