Investing in a software project feels risky. Let’s face it, building custom software for your business isn’t cheap and just like any other investment, it comes with its own risks which need to be managed both during the build process as well as into the future, over the entire life of the system.
Buyers typically work to mitigate these risks through fixed price contracts with their vendors; fixed price contracts freeze all four magical factors at once — money, time, quality and scope. Assuming quality is not negotiable, we accept that what is built must work, the three other factors have a direct impact on each other. For instance, if scope increases, either budget or time, or both, need to increase correspondingly.
A real problem with fixed price contracts is the last of these magical factors: scope. Generally, the scope is fixed in terms of what exactly should be built instead of how much should be built.
When starting out with a development project, naturally you want to know how much you will pay (who doesn’t want to know that?) and when you will get it. The only thing you don’t know is what exactly you want to get (even if you insist you do know, you don’t. Nobody ever really does).
For example, we could build everything you’re asking for, to the letter, and under budget, but what about performance, scalability, usability, maintenance etc.? None of these are specified anywhere so we could easily argue that we’ve implemented the functionality that you asked for and when the system doesn’t scale as you expected it to, you would argue that we haven’t. At what point do we agree? On the one hand, it’s in our interest to do the bare minimum to ensure that we don’t exceed the project budget and on the other hand, you would be looking after your interest and asking for more and more and more. We are both incentivised to get the most out of the deal and the project is doomed to failure before we start.
So then we need requirements, surely?
Every fixed price contract has a companion document, the “Requirements Specification” or something similar. This document tries to reduce the risk of forgetting something important and tries to set a common understanding of what should be done to provide an illusion of predictability. The problem is, one cannot document every single requirement upfront. One cannot document that the user experience should be great (what does that mean?) One cannot document that the system should respond quickly. How quickly? One cannot document that the system should be easy to maintain. (What does that mean? Who’s doing the maintenance?) This sets us up for a fight before we even start.
The outward benefits of a requirements document are obvious: you can plan the cost and project timeline easier. Any risks in overruns are carried by the software vendor. Perhaps you want to impose penalties for deadline misses, in which case the vendor carries double the risk: both the cost to complete the project as well as the penalties.
In theory, a fixed-price project could work if the project scope and requirements are perfectly known and never change. In practice, this is never the case. Often the requirements are vague with a lot of edge cases (sometimes important, sometimes not) not being described. Sometimes the client and the developer have differing views of what’s obvious and sensible. And sometimes, the scope and requirements are changed based on the new knowledge gathered during the course of development. Furthermore, what you say is not necessarily what I hear. Humans are not perfect communicators.
To protect against these risks the developer has no other choice but to estimate the risk, add some padding to the project cost and hope it wasn’t underestimated.
The hidden costs for the client of the fixed-price contract are the increased cost (padding), a real probability of the project slipping and missing deadlines, and the inability to adapt the project as new requirements are uncovered.
What do we do?
We look at software as a living thing; just like the business it supports, it changes over time. What’s needed by the business when the project starts may no longer be a priority later on and the successful project works with – not against – this knowledge.
We approach this by trying as hard as possible to accurately estimate project time and cost up front, giving us a high-level project budget. Thereafter the team provides regular (at least weekly) feedback showing how they are burning through budget and features which, combined, allow us to extrapolate when we will run out of money and/or when we will run out of features to implement. Couple this with weekly reviews and demos of what has been done and weekly planning and prioritising meetings for what we do next. The customer always remains completely in control of their budget. They can control the what, the when and the how much to spend, the team delivers everything they can within those constraints.
Chris Ainslie
Manager : Innovation & IoT
Comments