First of all, why use it? Is it that my software development service provider doesn’t believe in himself? Maybe; if your software provider is a tiny one with very little experience, they’re probably just trying to put all the risk on your side, because they know they’re going to have a hard time building your software. However, why do large companies with tons of experience ask for these kinds of contracts? Precisely because of their experience; building custom software is not like building a bridge or an office building. Every piece of software is a completely new product, a prototype.
Think about your product, you probably don’t have the exact list of functionality that the system must do and you haven’t answered every possible question regarding the functionality of your system. If you do know every answer to every question, then you probably don’t have it very well documented to that level of detail because it would take literally hundreds of pages.
Let’s even suppose that you have those hundreds of pages perfectly written. Are you sure that the functionality described there is exactly what your stakeholders want? Don’t they want a little something more somewhere? What if your business environment changes? Maybe the requirements will change. Basically, software is too abstract and ethereal for a user to understand fully when you’re trying to draw it in the air while writing requirements and software developers know that they will never understand your system fully until they’re finished implementing it.
This is where agile software methodologies come in. They know this happens. The solution they propose is simple: build a little bit of the most important functionality, show it to your users, they’ll come up with stuff that’s missing in the system and repeat the process. Do you know how many times you need to do this? No; no one does, because requirements will constantly change and be added or removed from the project. So, how can you know before-hand how much the project will cost? Hence, the failure of all projects that customers may try to execute under a fixed cost contract. So why are companies so in love with fixed cost contracts? It’s probably a cultural thing. Software is unique, in comparison to other engineering practices, in the sense that it’s always going to be something completely new. Users will have a very hard time trying to grasp the concepts of the system before it’s built. Because of this, the actual business value of the piece of software that you’re trying to build is impossible to measure.
A fixed cost contract means the company is saying: “I am willing to only spend this much for that system” (for whatever reason) or “I only have this much for that system”. So, if you don’t have a business value to the software you’re planning to build, how are you able to put a dollar value to it? You’re guessing the business value and thus giving it a ceiling. Why guess the business value if you can actually see it for yourself BEFORE you put a dollar value to it? How do you do that, you ask? Use a burn rate budget for your system, says your software development provider, and you ask yourself: “How do I manage that? When does it stop? I’m going to spend tons more! They’re trying to rip me off or this guy is simply crazy!”.
The funny part is that the truth is exactly the opposite: you’re going to spend tons less (according to the Chaos Report and many other sources). The technique works like this: basically, every time your software provider gives you a release of the system, ask yourself: “Is adding this additional functionality to the system worth this amount of money?”. Basically you’re analyzing if adding the next highest priority items from the Product Backlog is worth a few more iterations for another release. If the answer is “yes” is because you’ve measured the business value of the requirements you’re about to build and put a dollar value to it. Now you have a ROI to the iteration and you’re measuring the true value of what you’re doing.
Did all of this sound interesting? Want to know more? Want to give it a try? Contact us.
