The problem with fixed-price software projects (and contracts) is not really fixed-price; the problem is fixed-scope.
In this article, when I say fixed-price, I also mean fixed-budget. It is perfectly normal for an organization to provide a budget (maximum allowed monetary expense) for the creation of software to solve their problems. It is good that the organization determines how much they can afford to spend for the software, and put a cap on it; and anything beyond that is something they couldn’t afford.
So, if fixed-price is not the problem, then why is fixed-scope the problem?
People in the I.T. world often hear fixed-bid or fixed-price projects. We rarely hear fixed-scope projects. But underneath it all, any fixed-price project that has a lengthy detailed requirements document (more popularly known as RFP or request for proposal, or RFI or request for information) has a big chance of having fixed-scope. Instead of focusing on requirements, the lengthy RFP document goes on to specify a solution design. This solution design causes fixed-scope! This fixed-scope could be dangerous. Was the solution design tested? Was it verified to successfully satisfy the requirement and solve problems? If not, this fixed-scope becomes the problem.
Good business analysts can readily distinguish requirements from design. A good requirement should be design free. It should also be verifiable with acceptance tests. If the contractor has difficulty writing design-free requirements, it’s probably better to just write user stories.
With the detailed requirements document, the contractor (the organization looking for a vendor to develop its software) is already assuming that the solution (albeit incomplete and untested) is solving the problem, and is just looking for a vendor to supply the developers who’ll build the system (according to spec).
Detailed requirements are "actually" solution design
I watched Mary Poppendieck on her talk about Agile Under Contract. She points out the following lessons learned:
- Detailed requirements are "actually" solution design.
- Development is a learning process.
- Start with a clear understanding of the critical business results that must be delivered.
- Mitigate development risk with frequent delivery/assessment.
I won’t go through all four (4) lessons. I’ll focus on the first one, as it is most relevant here. Detailed requirements are "actually" solution design. Mary goes on to say that,
The responsibility of success lies with the solution designer.
Responsibility of success lies with the organization that specifies the detailed "requirements".
The problem is that the so-called detailed "requirements" in the RFP are "actually" solution design. Unfortunately, the solution design are done by amateurs who didn’t care enough to test and verify their solution. What if the solution design in the RFP was incorrect or incomplete? What if it conflicts with another section of the lengthy RFP? Who should be the one to fix/change it? The vendor that was hired to build the software, or the organization that approved and sent out the RFP?
For me, it should be the organization that approved the RFP in the first place. Since they’re the ones who "designed" the solution, they should be the one to correct it, and pay accordingly for the changes. Instead of coming up with a "pieced" together solution, they should go through the solution design (cut out a single flow from start to finish with some meaningful end, with limited options along the way) and have tests to prove that it works.
I often encounter RFPs that go into detail and even provide UI wireframes and screenshots. This level of detail gives them the false impression that the requirements/solution have been detailed. But they fall short of not having a domain model (or even a data model). It’s as if they copied portions of solutions that they liked (only God knows where they got them), and compiled them together. Any good business analyst would see that the solution does not "come together".
I hope to see more fixed-price projects that go through a more collaborative initial phase to flesh out the requirements, and develop a solution design that can be proven to work and solve stated problems. But be careful! I don’t want to go back to doing big design up front (BDUF). I prefer to see a time-boxed (two weeks or less) envisioning iteration (called iteration 0 in agile modeling) where the requirements are understood, and just enough modeling is done. This should allow for a better (understood) detailed "requirements" or solution design. And the development can start to build a small portion of the whole solution and have users (and other stakeholders) providing feedback. This feedback builds trust between contractor and vendor. Ideally, if the solution design is well done, it can be contracted to a another vendor (and not the vendor that helped design the solution).
What if the contractor does provide a good complete tested solution design (not the half-baked detailed requirements), can a vendor go fixed-price? The answer is definitely, yes! An experienced vendor (who has done something similar) can develop the system (based on the provided solution design) with great accuracy with the effort and its cost.
In fixed-price and fixed-scope projects, the only variable left is quality. Do we really want the quality of our software suffer? Can any contractor really live with fixed-price and fixed-scope projects knowing that quality is going to suffer?
References:
