Why Waterfall Procurement Needs To Get More Agile

Over the years, we’ve been through many procurement processes — and one thing has stood out time and again. This is something that we think could change, and if it did, it’d allow for a more successful procurement process for all organisations involved. 

The thing is this: most software procurement processes are waterfall in nature. Whereas most software companies today work with an agile methodology (and for good reason). 

Why does procurement use a waterfall approach?

Before we get into this, it is important to mention that we understand why organisations feel the need to take a waterfall approach to their procurement process. It feels safer. You put out exactly what you want and companies tell you exactly how they will do it, how much it will cost, and when it will be finished. That inherently feels like it lowers any risk. 

There’s also the fact that the current way in which procurement processes are run do make it easier to differentiate between applicants. Right at the start of the project you can see that company A is cheaper than company B, but company B fulfils your criteria for experience in the industry, for example. Again this gives the idea of lower risk.

Why do we think it’s important that the process changes?

But the move away from waterfall within the software community in general shows the reasons why this idea of lower risk is potentially a fallacy. 

The waterfall methodology has always put all of the thinking in a project right at the start. You know your final goal, and you build the software to that set of criteria, in the hope it will later meet requirements and produce that end product within a set time scale and budget.

However, this process fails to take into account three key factors. 

1. That the solution you produce at the start, remains the right approach, as the project unfolds and learnings are unearthed.
2. That user testing doesn’t throw up surprises as you test the solution in the real world.
3. That unforeseen discoveries or technical issues won’t derail your project.

If a procurement process uses this approach, it’s likely to get you many promises regarding outcomes. But it also increases the likelihood that the project will either go over-time, be rushed and therefore see quality reduced, or fail completely. (See the video below for a bit more on this - otherwise known as the iron triangle).

Agile is the answer

Here’s where the agile approach can actually de-risk your project.  

When using an agile methodology for your software build, you ensure that “thinking” happens throughout the project. By creating stages of analysis – test and learn – throughout the project and working in short sprints, your project becomes much more flexible. 

Say, for example, you discover in the first third or a project that a certain user interface isn’t quite right, or an API integration won’t provide the data that you had envisaged. With waterfall, this would likely only be picked up at the end of the project. With agile, this will likely be picked up before the code is even written, allowing you to course correct and resulting in a better final product. 

It’s an overall much more agile (pardon the pun) and flexible way of working that de-risks projects and routinely delivers better results.

The difficulty is that knowledge is not front-loaded, it’s built throughout the project and fed back into the creation of the final product. And this makes it hard for people looking to procure software services.

Why agile doesn't fit current procurement practices 

Part of the problem is that the agile methodology does mean that it’s difficult to lay out an entire project right from the outset, which means procurement processes can’t get the kind of information they feel they need in order to make an informed decision. 

After all, how can you choose between a selection of companies that need to get stuck into the project and complete at least a workshop or two before they can begin to give a project shape? 

We think it is possible. 

The reality is that very few clients come to a potential partner with a detailed brief, and the ones who do, or at-least attempt to, quickly learn that their assumptions were wrong once the project starts. That means what was cost for in the procurement process, quickly becomes obsolete and then the provider has to re-cost further down the line.

At the very least, it would be beneficial for organisations that are putting work out to tender to allow for companies to apply by detailing their agile process, rather than attempting to shoe-horn a tried and tested agile approach into a waterfall-shaped brief. 

It’s not that companies like Newicon can’t work within a brief that demands a waterfall approach, it’s that we know there’s a better way, and that the company putting out the work is missing out on a company who works in a manner that can achieve better results. 

For every tender that we win, we often win another project that’s essentially saving a job that’s gone out to tender and failed because of this waterfall approach. The number of project rescues that we’ve taken on that started out this way is quite alarming. That's why we decided to write this article!

What is the solution to getting the right partner? 

Do your due diligence on the company, that goes without saying when you are parting with considerable money. So satisfy yourself that the company has a rich heritage of delivery —  testimonials , case studies, some customers who you can speak to. And ensure that project management, processes and testing is all considered and their methods tried and tested. 

But (and here comes the controversial, turn-procurement-on-its-head statement) don’t procure for the whole project unless you have a good referral to the company, or you are sold on their methods and track record from the off. Instead, we recommend that an exploration phase is procured and commissioned first. We call this an Architecture Phase, which incorporates Discovery, Design Sprints and a Technical Analysis. 

Ultimately you wouldn’t build a house without designing it with an architect first, and we believe with software it’s no different. So decouple the discovery phase from the build phase and save yourself a whole world of pain compared to a waterfall procurement approach, which will more often than not set you up for failure.

But what about the cost?

You might be thinking, but how can we possibly take this approach when it’s likely budgets will spiral. Well, our suggestion is to go into projects with a budget in mind, and ask the provider “what can you provide for my budget?” Then work together to design a solution that fits. This results is typically a much better quality solution, with much less risk along the way. 

If you have no idea of the budget, then we often provide a RoM (Rough Order of Magnitude) price estimate. We essentially have a few brackets based on both the information we have at that time and our experience of similar projects. Typically we can design a solution at either end of a RoM cost, it just comes down to collaborating to decide upon the features of high impact, so we can deliver an initial solution that solves the biggest problems first.

That’s agile. That’s sensible. And it’s how we’ve successfully been delivering projects for over 15 years.

Find out more

If you’re thinking about procuring software services or putting a project out to tender, and simply want to know which questions you can ask to get better results and de-risk your software project, then get in touch. We’re always happy to help.