Why fixed cost, fixed scope software development projects fail, and what to do about it

So your Board or CEO want to know exactly how your new custom software project or digital transformation is going to work and what it’s going to cost. 

And to be honest, we’d all like that level of certainty. 

But it can be an expensive and painful mistake to approach software development in that way.  

Here’s why:

The project is not actually delivered within the time or the budget 

Most projects are not delivered within the promised time and budget, so why lie to ourselves.

“On average, 45% of large IT projects run over budget, 7% of projects run over time while only delivering 44% of the predicted value.” *

Fixed cost, fixed scope projects work well for repeated tasks, things that have been done hundreds of times before because they can be estimated with precision (and often these simple projects are covered by SaaS platforms and shouldn’t be developed as custom software).

If on the other hand, you’re trying to build a competitive advantage via custom software:

1. You’re doing something new.
2. Doing something new involves discovery and investigation.
3. Because of 1 and 2, there’s a high likelihood that things will change: your estimates may be wrong, or your project direction may change or new technology may emerge that changes the work required.

The project delivers the scope – but not value for the business 

Fixed cost and fixed scope projects are based on the fundamentally flawed assumption that everything is already known before starting a project.

They ignore the fact that custom software development done well is an iterative process, where learnings occur, and better decisions are made based on those learnings, real results and user feedback (instead of all decisions being made before starting).  User needs, and ultimately the needs of the business can be met in different and better ways via an iterative discovery process.

A competent software team with an absolutely fixed scope will have blinkers on, and remain laser focused on delivering the agreed scope to get paid, instead of delivering actual business value.

The common outcome is the business saying “we got exactly what we asked for, but not what we needed”. 

It sacrifices quality – which costs more in the long term

If we look at the classic triangle of Quality, Cost, Features. 

If the cost is fixed, and the features are fixed, it leaves the team with only one lever to pull – quality. 

Cutting corners by doing things half-assed, not developing in a modular, sustainable way does get the job done faster and cheaper in the short term – but results in bugs and creates massive technical debt that you’ll pay for months, even years afterwards.

The worst part is that this technical debt is not usually visible – the features are delivered and usable. It’s just when you come to make changes that it takes you double/triple the time and is riddled with bugs that the debt is recognised. 

It creates a combative, not collaborative relationship 

There is a natural clash of incentives: 

The team or agency developing the solution is incentivised to develop the software as quickly and cheaply as possible to maximise their profitability. 

The business is incentivised to squeeze every little feature out of the agreed scope to maximise the return on their fixed price spend.

The result – a relationship that from the start is based on conflict, not collaboration and value creation. 

The agency focuses on pushing anything they can interpret as ‘Out of Scope’ to an additional charge, and the business focuses on arguing that it definitely should be interpreted as inside scope. 

All of this wasted time could instead be invested in achieving the goals of the project, and prioritising feature development based on value.

Big deadlines, big burnout

As the massive launch deadline looms, your team work themselves into the ground to hit the deadline, taking shortcuts, making costly mistakes, and burning out the team.

The conclusion: Fixed cost, fixed scope projects just don’t work for custom software.

So what’s the solution?

There is a solution – that provides the best of both worlds: 

✅ Fixed price – giving management and finance the certainty they need. 

✅ Fixed time frame – a specific deadline, with regular (at least fortnightly) releases in between.

✅ Fixed goals – enabling every action to contribute to the outcome.

✅ Non fixed scope – (ie not having every field and feature pre-decided) giving your business and the development team the flexibility to make great decisions and to deliver maximum value.

Implementing the above using an Agile approach, enabling your team to work on the highest value deliverables for you at any given time, which you approve as you go, reduces risk and increases delivered value every sprint. 

The budget is fixed, the goals are understood, and the team are empowered to get you the outcome you need. 

Cheeky plug: Contact us to discuss how we’ve delivered successfully for companies like yours. 

But what if I have absolutely fixed requirements with no room for change?

There aren’t many projects like this, but they do exist. 

If you find yourself in this circumstance, it’s worth considering some flexibility or contingency around budget, because if the cost and the scope can’t change, it only leaves quality to be reduced, or budget to be increased. Typically an increased budget in the short term produces better long term value.

*Mckinsey

About The Author

Dane Eldridge

Passionate about helping companies build competitive advantage using technology. I love working with people to achieve amazing things, helping my teammates grow, and perform at their peak.

See author's posts