The problem with fixed price, fixed scope (and dubious quality) IT projects

Can projects based on a fixed price, fixed scope methodology ensure good quality IT products? In this article, we argue that it’s highly likely that this approach leads to dubious quality.

Classic project management triangle

According to the classic project management triangle, the best way to ensure product delivery is to pick two of three constraints – time, cost, and quality – and adjust the third when needed. The model has been around since the 1950s. Put into practice, it means that it is possible to infinitely increase the number of workers to speed up the project without compromising the quality.

This may have worked in some (especially small) teams, where velocity increases proportionally to the number of developers in a team. Nowadays, however, we know that it doesn’t hold in IT projects, especially not once a dedicated software development team hits 10-12 people. Sometimes, it can even have the opposite effect.

Most people agree that time equals money. Whether you have your developers or hire a software agency, at the end of the day their time equals money. As you can’t keep increasing the team size infinitely, you won’t be able to manipulate the budget infinitely and still be able to deliver a fixed scope within a fixed deadline.

If you hire your team of developers, you will notice this dependency pretty fast. You will also notice its effects when discussing a fixed-scope and fixed-price project with an agency.

Quality is remembered long after the price is forgotten

If we agree that time is money, the project management triangle leaves only two dimensions besides quality you can play with. You either pay more to get everything you want or cut the scope to fit your budget. Or… and this is when the third dimension that nobody speaks about enters the stage… the quality will suffer.

It is also worth noting that unrealistic budgets that don’t cover hiring competent people will hurt quality, no matter how much time you have for implementation.

Is it always wrong to compromise quality?

So what should we do if we have to deliver a scope that has already been cut to the critical minimum, and the deadline can’t be moved, and we realize that we are not going to make it regardless of how many extra developers we hire? Should we insist on keeping the quality at a high level no matter the cost and risk the project doesn’t get finished? Not at all! On the contrary, sometimes, the best thing we can do is to make a conscious decision to compromise the quality temporarily. It would, however, be a big mistake to make that decision unconsciously.

As it’s really hard to measure quality on the go – most quality measures are “lag metrics” that affect results over time – it is even likely that the decision to cut the quality goes unnoticed. Just be aware that it can catch up with you later as so-called “technical debt”.

Technical debt

If you have experience in software product development, and I know that most of our readers have, you have probably heard of the mystical “technical debt” many times. Technical debt is something that seems to appear out of nowhere and ruthlessly destroys a seemingly perfect project. When technical debt enters the scene, the developers usually come up with some excuse that means they can’t deliver new features at the same pace you got used to. This might look like laziness or sudden incompetence, but that’s not the case. It’s just the result of a quality decision taken in the past, most probably unconsciously.

There are many common symptoms of unconscious quality decisions: You may experience higher bills for your production support interventions, which now has to react to urgent issues 24/7. You might see your product ratings drop. The number of bugs reported by the team may rise, and you may have to hire (more) testers to fix those bugs.

On the other hand, consciously cutting quality means that you know what you are doing, you are aware of the short and long-term consequences, you have a plan of how and when to improve the quality, and most importantly, you are doing it when you planned to do it.

So what exactly is the danger of a fixed price, fixed scope approach?

First of all, you probably agree that it’s unlikely that project management methods from the 1950s are still valid in 2020.

Secondly, when you order a fixed price, fixed scope project from a software development agency and it has been delivered as agreed, you can be sure of one of these three things:

1. You have overpaid because the agency is good at estimating and considering the unknown risk, so they could keep the quality at a good level and still make a lot of money on that.
2. You have underpaid, and although the project will be delivered in full within the budget/time, you will have to pay a lot for fixing the quality later on.
3. The agency is incompetent and/or inexperienced. They priced the project below the actual budget needed, but as they are ambitious in terms of quality, they will deliver decent quality and cover the extra costs with their savings. Hurray, you are the winner. They are the losers. Well, you won this time, at least. If you need any additional development, you will probably need to look for it somewhere else or be prepared to pay a lot more than you got away with this time.

Sometimes, the result is a mix of the above. Fixed price and fixed scope projects are rarely win-win situations.

The only true wisdom is in knowing you know nothing

Last but not least, having a fixed scope means that we think that we know what our users need and want. In reality, we will be plain wrong in at least half of the cases. Statistics show that only around 20% of a product’s functionalities are used always or often, another 16% are used sometimes, 19% are used occasionally, and as much as 45% are never used.

Depending on the amount and quality of any market and UX research carried out, these statistics may be better. But in many, if not most cases, a significant part of the scope delivered is of no use. That means that even if we “won” (third case above), we have already overpaid for the product since the scope could have been smaller or different.

It’s important to remember that the price does not equal the total cost. Even if a product has been delivered on time and within budget, it’s just the beginning of the actual costs. And that cost depends on the way the initial product was delivered.

So what’s a better way to build products than methodologies developed 70 years ago? Luckily, there are plenty of modern methods that have been shown to work way better: Agile, Scrum, and Lean software development, for example.

Conclusion

We hope that this article has highlighted the danger of fixed-price, fixed-scope IT projects. Viewed in light of the Project Management Triangle, a fixed price and scope only leave one dimension to adjust, namely quality. Instead of hanging on to project management methodologies from the 1950s, we strongly recommend modern alternatives.

Check how to choose a software development agency that knows modern product development methods and does not sign fixed price/fixed scope contracts in this article.

And, you you want to learn more about how fixed-scope stacks up against time&material and fixed-price, scope controlled models, check our article: Which software development pricing model to choose? Fixed price vs. T&M vs. FPSC