This isn’t a post about 90’s R&B sensation TLC, this is about project management. No wait, don’t go. Come back!
Until recently, the standard way to manage any sort of software project was to use the waterfall approach. It’s a sequential process which flows steadily downwards from the conceptual stage through to actually delivering the system or product.
Seems really simple huh? Analyse the thing you’re trying to fix. Design a solution. Implement it. Test it and iron out the rough edges. When all bugs are squashed, deploy to the masses and enter into maintenance & support mode.
Where all the variables are known and unlikely to rapidly shift, this approach makes absolute sense. The only problem is that when it comes to technology everything is rapidly shifting, all the time, everywhere.
Waterfall project management is a product of a bygone era. Originally dreamt up by enterprise mainframe programmers, they didn’t have the luxury of going back to modify their work because it was too cost prohibitive. Instead they made a trade off and hoped to try and catch all contingencies at the outset.
In software development circles, waterfall has been largely replaced by Agile project management. Agile uses short iterative windows of time to build functional bits of work which can be put into the hands of users. Users are actively encourage to feedback improvements or requests which can then be incorporated into the next iteration.
The obvious advantage here is that the development team don’t spend long fruitless hours working on stuff that is of no use to the end user. Instead of trying to define requirements at the outset, they uncover them as they work through iterative cycles.
Think of any large online business and they’ll use some variation of this approach. Could you imagine Amazon doing yearly site updates? In fact Amazon deploys an update to their site every 11 seconds! (on average).
In IT circles however we seem to persist with waterfall project management, perhaps as a throw back to the days of those big mainframes. And to a certain degree I can understand why when we’re largely implementing ‘off the shelf’ solutions provided by external suppliers.
All the variables should be known and the requirements shouldn’t change.
Except.. they’re often not and they often do.
Here’s my first major issue with waterfall project management.
If the analysis and system specification are not accurate at the outset, then everything that follows is wrong.
Despite best intentions, initial analysis can go wonky for a number of reasons. Like the project sponsor not totally understanding the issue they’re trying to fix. Or the project group hasn’t actually spoken to the people closest to the problem. Or the specification slowly creeping to encompass non-essential stuff (aka user wants over user needs). Or the sales guy over promising and later under delivering.
Because waterfall is a sequential process, you may not uncover any of these until you are right in the middle of it. By which time there’s very little you can do other than tinker at the fringes.
The deeper you get into a project, the harder it is to make changes because you have to build on the existing unmovable foundations.
Because the investment in these projects is often heavily front loaded, they’re almost impossible to course correct or indeed stop once they’re under way. Not just in terms of financial investment, but cognitive investment too. It’s a brave person who can stand up in the middle of a project meeting and suggest that the plug should be pulled. Us humans have a desire to make things work and avoid failure, even if all signs seem to suggest otherwise.
The larger the project, the longer it’ll take to get it into the hands of your users. It might be out of date before it gets to them.
Suppose it takes a year to deliver a project from the point that a specification is written. A year is a long time in technology terms. Your solution might be partially redundant before it’s even seen the light of day. It’s also a long time to maintain enthusiasm for a project. Will people still be as invested at the end as they were at the beginning? Does it meet any of their current requirements? Do your projects launch with a fanfare or a whimper?
Assuming you want to go back and tweak the system to incorporate some new requirements or features, how responsive is your supplier? Is that another couple of months for minor changes? Do you have to wait until they roll out their next release? Can you get financial support to do this or is the whole organisation already fatigued and ready to move on to something else?
I’m being overly critical here and there are totally legitimate cases for waterfall project management to be used, but those are becoming the exception rather than the rule. Perhaps only where we’re talking about physical hardware which won’t change that rapidly. That seems like a time limited situation because as predicted, software is eating the world.
And make no mistake, Agile isn’t a magic bullet either. It comes with its own unique set of pitfalls.
However I remain fairly convinced that if we actually want to try and keep pace with the world around us, we need to be working with people and processes that utilise Agile methodologies.
In an increasingly ambiguous operating environment it’s the only realistic option for delivering more work in less time, with actual flexibility.