Why Waterfall-Based Cost Estimation Is Practically Impossible for Modern Digital Products
In the software development world, fixed-price projects often mean fixed scope — just like in the Waterfall methodology. To prepare a fixed scope, you need to make lots of upfront planning.
But today’s software development is a highly volatile environment where technology trends and customer preferences change rapidly.
In the end, all the effort put into upfront scope planning can crumble, either at the product launch or during development itself. Learn what makes estimating fixed-price projects practically impossible if you want to target shifting customer needs.
Waterfall-Based Cost Estimation for Modern Digital Products — Possible Pitfalls
The Evolution of Complexity in Software Development
But in the 2000s, Python 2.0, C#, and JQuery were released, allowing developers to build safer and more robust software and websites. With the release of these technologies, the complexity of software increased. More complex software took longer to develop, and the standard approach to development at the time — the Waterfall methodology — started showing cracks.
Complex projects often resulted in irrelevant software that fell short of customer expectations — by the time the solution was released, the market and customers already had different needs.
Welcome Agile Manifesto
Because of these growing complexities in software development, fixed-price contracts became increasingly difficult to estimate accurately. The need for a change was recognized, which gave birth to the Agile Manifesto.
Following the Agile principles let developers release software in iterations and collect feedback that guided further development. Agility in that sense meant delivering relevant and highly user-focused digital products.
Note: Even the projects that can be built in a Waterfall model, should be broken up into chunks for the stakeholders to review and give feedback. This helps avoid a situation where the product has already lost its relevance at the launch date (by that time so much development work has been done that any changes are simply not viable financially).
Let's see what may happen if we try to build successful projects in a strictly fixed-price model.
Relevant products depend on flexibility during development to keep addressing user needs
When a software agency can’t deliver a complete product within budget, they might restructure the initial team and let junior developers finish the work. This frees up their senior devs to pursue more profitable projects.
Scope cuts or workarounds to meet the deadline
When a vendor nears the deadline but the product is far from being finished, the company might turn to quick workarounds or scope cuts. Quick workarounds make the product unstable and unreliable in the long term. On the other hand, scope cuts result in an unfinished product that doesn’t meet the initial requirements fully.
Inability to get all details prior to project’s kickoff
The fast and hectic decision-making process in software development projects makes it difficult to collect all the details upfront. Even with a detailed specification, there's always some level of assumptions on both sides.
For example, during development, it might turn out that certain parts of the app have to be written from scratch to secure a fully custom code that’s not limited by OS policies or third-party solutions. Another example can be the inability to use certain paid tools and libraries.
It’s close to impossible to learn which parts of the product need a custom approach before the contract begins.
It’s difficult for developers to validate all open-source libraries and plugins before they actually start implementing them. Conversely, when there’s nothing reliable in the currently available resources, the necessary plugins have to be written from scratch. If the available libraries are outdated, developers have to update them.
This goes on to show just how difficult it is to accurately estimate what will and won’t be available in projects that run for, say, half a year.
If a software agency doesn’t have any inflow of cash and is waiting for product release, it can run out of money to operate and as a result, abandon your project altogether.
With a partially finished product, it might be difficult for another vendor to take over the development work and meet the release deadline. The second team needs to familiarize itself with your business and the product.
Once a fixed-price and fixed-scope contract is signed, you can make very few changes. If a better solution enters the market during development, you’ll still have to go with what’s agreed on in the scope.
A vendor might also use the opportunity and valuate something simple as complex to make up for the loss.
That said, you might end up releasing a product that’s already irrelevant technologically.
Missed market fit at launch
Some complex software solutions take upward of six months to develop. Half a year is enough for consumer preferences to shift. As a result, once you release your product, market fit might already be lost.
What Makes Fixed-Price Project Estimation Difficult
Problems with internal infrastructure
When you want to add a mobile product to your existing infrastructure, this process greatly depends on what’s already there. For example, connecting a mobile app to the backend API is determined by the quality of that API. In this context, the software agency has to work with existing solutions. If these are low quality, this can generate time losses.
Performance issues with existing assets
Working with existing architecture that is complex and influences the performance of the app requires developers to create solutions that improve performance within the available ecosystem. The development of such solutions takes time. This can also generate issues difficult to predict.
Any integrations with existing systems are tricky to estimate time-wise because they are not repetitive code elements. A vendor can estimate based on similar past experiences, but solutions are rarely the same. Thus, these estimations can compound inaccuracies.
New government regulations
A new regulation that changes how a certain application should behave can go into force halfway through development. The application then needs to be adjusted to meet the new requirements enforced by the regulation.
Most mobile applications rely on integration with other services. When there’s a change in 3rd-party integration policies (e.g., inability to import contact information from Facebook or Instagram), depending on the application type, a pivot or a change in scope might be necessary.
Consider Contract Alternatives to Build Relevant Products
Trends and customer preferences change rapidly. The competition rarely sits quiet, eagerly pursuing new and better ways of serving customers.
An estimate for a mobile app that will offer solutions no one is looking for once it enters the market will be drastically skewed. If you don’t want to drop your idea, you’ll have to act. You will have to include the costs of potential pivots to save the legacy and still deliver a working product that can have a shot at saving ROI.
+10 years experience in Business Relations (+5 centered around digital products including SaaS and custom app development for start-ups and corporates). Managed to build sales and growth strategies for a brand new SaaS start-up (meeting application). It all resulted in competing successfully with a giant like Eventbrite and engaging multiple Fortune100/Fortune500 companies into collaboration. Once done, decided to get into closer relations with clients who also try to build successful products, as seeing how new things fail, rise, and grow is inspiring.
You may also like
Explaining Waterfall vs. Design Thinking, Lean Startup, and Agile