There has been a change of heart about a Fixed-price model (FPM) of engagement recently. Many IT companies have reservations about signing fixed-price contracts and even reject this option outright, citing numerous negative experiences while praising the Time & Material model (T&M). Others settle for merging an FPM with Agile methodology.
In this post we will examine the specifics of utilizing a fixed-price model by IT professionals, possible pitfalls and how to avoid them.
What is a Fixed-price model?
In a Fixed-price model both the price and the time span are fixed. The contractor agrees to accomplish a product or provide a service within a set time frame in exchange for a fixed payment. Non-delivery may entail considerable penalties. Thus the scope of work and specification are very clearly defined right off. By the contract, most risks (such as non-delivery or cost overrun) are shifted to the contractor. Similarly, the role of a process organizer is wholly assumed by the service provider.
How does a FPM impact Waterfall process flow?
A Fixed-price model secures the time frame of a Waterfall process with its regular stages: requirements analysis and documenting, system design, implementation, verification, and maintenance. These activities cascade one after another in a waterfall manner – hence the name. Because the time frame is fixed, the risk of meeting the deadline increases with every consecutive stage.
The recent statistics have reported only 11% of all Waterfall projects being successful, compared to 39% of Agile ones. What can possibly go wrong with the remaining 89%?
What problems can you face with a Fixed-price model?
Let’s decipher the statistics above. Problems arise when a project fails to meet one of the three criteria of success: ‘on budget’, ‘on time’, and ‘on target’.
Specifically, clients complain about:
- A project’s not being on time;
- Exceeding the planned budget;
- Low level of satisfaction with the quality;
- Low value of the end product.
The major drawbacks of this model from developers’ perspective are:
- Not having enough flexibility;
- Insufficient resources to deal with scope creep;
- Cost overrun;
- Having to ‘cut corners’ in order to meet deadlines.
These complaints seem fairly reasonable, considering the consequences of an early cost and time fixing. So shall we simply jump on the Agile bandwagon like others and regard the FPM as outdated and obsolete? Obviously, we should know better and try to analyse possible reasons for a FPM not working the way it should be.
Why doesn’t my Fixed-price contract work?
In our view, there might be a couple of reasons for that:
- the projects chosen are NOT compatible with this model;
- the preliminary requirements analysis is not conducted properly.
Next we will explain what we mean and provide solutions.
What projects are fit for a fixed-price model?
FPM and Waterfall are more suitable for some projects than others.
To begin with, there are a number of situations when fixing the price is an essential business requirement, such as:
- projects, in which financial risk outweighs all the others;
- when a customer doesn’t want to own the risks of delivery, people and quality, but will be ready to own risks related to scope through change request;
- government, medical, or military projects where the quality benchmark is so high that all the provisions have to be clearly defined and strictly documented in advance, otherwise any change will entail additional licensing procedures.
And that makes it worthwhile to invest time and money into detailed specification and estimation.
Secondly, a client may have a very clear idea of functionality needed and may be familiar with all the ins and outs of a Waterfall process of software development and willing to stick with it. They may already have a detailed specification and business analysis. Then their verification and estimation will be prompt and more precise.
Finally, with an MVP, you may start on a Fixed-price contract with Waterfall. After receiving users’ early feedback, we would recommend switching to a T&M model with Agile for efficiency.
Our solutions to make your Fixed-price contract work
Our empiric observations accrued over years of practicing an FPM with Waterfall prove that delivering a high-quality product on time and on budget with a Fixed-price model is just a matter of experience.
To secure time and cost estimates, invest into a detailed preliminary analysis. By choosing an FPM the client agrees to pay more, as risk-taking (such as changes in scope) comes at a price. However, further overhead payments tend to breed frustration. Especially if change requests come out of insufficient requirements analysis and specification lacking the necessary level of precision. In that case, having a full-blown preliminary stage of estimation can be a solution.
We practice a two-stage modification of the Waterfall process. Stage 1 (Project planning) deals primarily with documentation (requirements elicitation, specification writing and detailed estimation) and UX design; Stage 2 (Project development) includes the regular activities of implementation, testing, and deployment. By separating a project planning stage, we attach greater importance to the in-depth requirements analysis and so can guarantee precision and accuracy of estimates.
Read also: How to Do Software Project Estimation: Our Techniques and Advice
Quality is directly impacted by a human factor. Quality deterioration is not the regularity of an FPM. Despite frequent complaints that an FPM stifles creativity, we maintain, it’s all about peopleware and skilled management. After all, if the developers estimating the scope are real professionals with sufficient experience under their belt, meeting a deadline won’t be a problem and the client will get all the functionality that they primarily requested and documented in the spec. For the same reason, having well-documented acceptance criteria will guarantee quality. So if a client has a clear vision and expectations about the product or is willing to invest time and resources into pinning down all the features in advance, quality won’t be an issue in an FPM, provided that there are low outer risks for the product to devalue. Thus achieving the desired level of quality is clearly possible if not necessary.