Companies that look to hire an outside firm to help them create or deploy new software often will look to pay for that project using a fixed price agreed upon at the outset. This is so they can reduce the perceived risk associated with the project. This is usually the wrong thing to do, though, if you care about creating the best product. To find out why, we first need to examine why software goes wrong in the first place.
Software is almost never right the first time
As I have written before, knowing what to put in your software is more important than hiring great developers in getting your software completed successfully. Yet the industry spends more time finding ways to create better code, not create better solutions. Furthermore, business stakeholders aren't in a position to help. They typically think that they know what they want, and very often think they know how to turn what they think they want into working software. But in reality, knowing how to turn what is usually a failing process into successful software requires knowledge of both the business and of creating software.
On top of that, business needs usually change. Businesses never stand still. New competitors emerge, businesses grow, new opportunities emerge, and so on. Even if you know what you need when you launch your software project, that might be different than what you need when the software gets delivered. But sometimes the change is caused by the software itself. As individuals see what is possible to achieve with the new software, they get more ideas as to what they want the software to do.
Getting software right means small, frequent deliveries
To combat all these problems, successful software teams deliver their product in small, frequent deployments. As more of the software gets completed and delivered, the team and the business stakeholders both gain a better understanding of what the need is and the possibilities for solutions. Mistakes are caught and fixed early (when they are relatively inexpensive to fix).
What does all that have to do with how one pays for a project?
There are two reasons why this affects your method for paying for a project:
The biggest reason cited for choosing to pay a fixed fee for a new software project is to reduce your risk. However, your most important risk is not failing to meet an arbitrary time and budget, but that your software won't meet your needs. If your goal is to minimize your risk, minimize the risks that matter most to your business. For almost every business, a truly successful delivery requires a process that is adaptable to change. But fixed-fee projects, almost by definition, entail a fixed scope and so do not easily accommodate such flexibility.
The second reason for choosing to pay for new software via time and materials rather than a fixed bid is that nothing prioritizes what's most important like being forced to put a dollar amount to each request. In the initial stages of the project, when the delivery team and the business stakeholders are still getting to know each other and the project, it's impossible for any individual to be able to understand the true priorities. Business stakeholders almost always want everything they can think of. On fixed bid projects, trying to deliver everything can derail the whole project. Instead, being forced to pay for each feature individually keeps the business team focused and the project on track.
If you're still not convinced
On nearly all of the fixed-bid projects I've been on, the communications between the delivery team and the business stakeholders were dominated by arguments about whether particular requests were in scope or not. On time and materials projects, we focused on determining whether it was worth putting in new requests. In other words, the delivery team needed to keep control of scope to protect our financial interests on fixed-bid projects. On time-and-materials projects we merely focused on doing what was right. Which approach would you take? I know which I'd choose.
No comments:
Post a Comment