Waterfall is dead!
I think it is!
To start, let me ask you when you last flawlessly followed the by-the-book, Waterfall process (Maybe PRINCE2 without the Tailoring)?
Now, I’m not specifically targeting PRINCE2 in this article. I know that one of its core principles is to tailor your project management approach to the environment. However, how far can we take tailoring before we’re just doing something differently? And then would that even be “Waterfall”?
A rigid Waterfall process no longer has a place in our ever-evolving world where we have near endless development possibilities.
Controversial? Possibly… But before you roll your eyes and close this tab, give me a chance to explain my thinking more deeply.
Waterfall is a linear process whereby each phase of the project lifecycle is worked through to completion prior to the next phase beginning.
Now that does sound great in principle; let’s work out what we want, how we’re going to do it, and how much it’s going to cost. Build it, test it, implement it. Amazing. What could possibly go wrong?
Well firstly, how many sponsors know exactly what they want when the initial idea for the project springs to mind? In my experience, none. Not truly at least. Many may have a very clear vision at the start, sure. But there are so many mitigating factors which can impact it during the project:
Okay stop shouting “scope creep” or “change control” at me. How often have we bent these rules to keep our stakeholders happy?
These reasons above are enough for me to suggest a rigid Waterfall process doesn’t work, at least broadly speaking.
To add some further context, I’ll draw on my personal experience with an example.
In a previous role where we tried to follow Waterfall methodology, we had a project sponsor who wanted to fully automate a manual process.
It was a compliance process which involved:
And what our sponsor wanted:
Our sponsor did appreciate the complexity of the work. We had 12 months to design, build and implement the process, all in one go.
Sounds reasonably straightforward at a high level don’t you think? Well, what wasn’t considered at inception was the fact that there were several departments within this process structure, and several different teams that may interact with the data at any point. Plus there were different external parties who would need access to the system to input and receive data.
Working as a Business Analyst at the time, what I wanted to do was to pick one specific area, for one specific part of the process for one external party. Build it, roll it out and get some feedback. Then iteratively moving onto the next areas so that we could slowly work towards the end goal.
A more “Agile” approach you could say.
However, it was felt it would be too confusing to have different processes flying around. To be fair, this was an understandable concern.
But then, the reality of the Waterfall project approach hit us. We ended up spending the next 12 months (yep, the entire initial timeline) in the Design phase of the project. With the sheer number of stakeholders, each with their own needs for their own departments, we could never agree how the end-to-end solution was going to look. We had over 500 requirements and a catalogue of process flows.
After another three to four months of deliberation, we decided to narrow down on one area and build it out as a “proof of concept”. Over the next few months, we did make some great progress. We moved through build and test fairly unhindered, helped by the fact that every possible conversation had been had.
At roughly the 20 month mark we had finally implemented our first part of the process. And from there-in, the development really sped up and we got into our stride.
I’m not saying that my initial suggestion was perfect or even well thought out. It is a shame though that it took us nearly one and a half years to realise that this project was too big to conquer all at once. A simple, iterative approach would have allowed us to gain some value back far more quickly.
I appreciate this is just one example, and I’m sure there are many Waterfall success stories out there. However, from my point of view, this experience doesn’t stand alone. Maybe not always to the same extremes, but often there’s an opportunity cost to the Waterfall way. For me, it’s about how quickly can we gain value from this project?
My goal as a project professional is to help deliver something that can provide a return on investment, as quickly and efficiently as possible.
I’d be willing to cede that a well-managed, well-structured Waterfall project could allow for the best solution to be delivered as the first solution. But is the best solution being first best? Or is it the first solution that works the best?
I think the latter and that’s why I preach about the importance of MVP (minimum viable product); stay tuned for my ponderings on that one.
