What is this thing? (Requirements)
What can I use it for? (Design/Blueprint)
What can I make with it? (Build/Develop)
Who can use it with me? (Implementation)
What could we change / adapt? (Review)
This process has been ingrained in all of us for many years, maybe as long as humans have been around. In the 1800s, manufacturing became the model for project management. Eventually there was an Executive Project Sponsor who provided the budget and a classically trained specialist Project Manager who controlled the project. They pushed resources through an assembly line and the same new thing came out every time. Each person worked on some small part. There are still small business problems with very clear deliverables and little risk that can benefit from this approach, but most of our projects are too chaotic for this to work.
With multitasking and multiple projects, it’s common practice to focus on lots of different things for short periods of time. It’s hard on the brain to flitter between different discussion. You’ve likely felt the exhaustion of this yourself about 3 PM every day. Our brains are not set up for this.
The Waterfall (also called Top Down) model, which worked well in the less chaotic days of manufacturing, is simple and clear: Analysis, Design, Build, Implement, Transition. If you could work on the project alone, the project was small and it wouldn’t take long to finish it, this approach might be the best bet. As soon as the requirements get more complex, multiple people need to make choices or your building something that’s innovative (never done before), Waterfall is not the best approach.
There used to be a clear hierarchy of control – the Project Sponsor owns the business ROI (how will this project grow revenue and/or avoid cost?), and the Project Manager, who reported to the Sponsor, controlled the project. The problem was change.
Pretend you’ve done a great job on Analysis. You proudly head to Design. Halfway through, a stakeholder changes something. No problem – just jump back, fix Analysis, fix what’s done in Design. Then another change, one after another. Every time you jump back, you create errors. You start to dislike the people making the changes even though they are your customer and it’s their project. You implement strong controls for them limiting their ability to change things. They start not liking you and stop coming to meetings. Finally, you think you’re done and the customers show up with all their changes. Ultimately you build something they’re not that crazy about, and you aren’t either.
In summary, Waterfall (Top Down) is a good process when the requirements aren’t going to change (for example, compliance work), the project is small and won’t take long, and there isn’t a lot of debate about what the deliverables are. Otherwise, read on for other options.