Kicking Waterfall Project Management Habits Requires Agility
When dealing with hardware and physical architecture, it’s relatively obvious what the sequence of activities will be, where you are in the project and where the variances will be. As a result, a pre-determined schedule with Program Evaluation and Review Technique (PERT) milestones is good for both the client and the suppliers. Of course there will be contingencies, but you can make logistical decisions months or even quarters in advance of the move-in date. Typically, schedule and budget over-runs are less than 20 percent and can be handled with simple incentives and penalties.
Waterfall project management also works fine in computer and network hardware design projects, thanks to design automation and simulation tools that support fairly deterministic results. In a distributed asynchronous system such as cloud software, not so much. The bigger the project, the higher the range of over-runs-sometimes beyond 100 percent. As Weinberg’s second law puts it, “If architects built buildings the way programmers build software, the first woodpecker to come along would destroy civilization.”
Two Major Challenges to Waterfall Project Management
There are two key reasons for Big Bang deployments, when there’s a decisive go-live date at which point all users cut over to the new system all at once.
The first reason is that management likes to check off the box, declaring victory on that expensive project authorized all those months ago. This is just a bad habit that you really need to push back on, using the following arguments:
Will a slash-cut really yield the best business value?
Will it be the lowest risk approach?
Will users-both employees and customers&mdashbe able to make the transition immediately?
Will the data be ready all at once, and at the same time as the system?
Will outside systems’ integrations be ready to make the transition at the same time, or will some of them need to hang back for a while?
If the only reason for a Big Bang deployment is “management wants it that way,” drive a stake in the heart of that monster as early in the project definition cycle as you can.
The second reason for sticking to waterfall project management is more of a challenge because it’s real-a new system replacing an existing one. There are solid business reasons for not wanting to have two systems running in parallel, and to prevent a Tower of Babel in the data sets. Sometimes, for logistical and customer reasons, there is no realistic alternative to a singular cutover.
But the likelihood of this transition actually succeeding in one weekend or one month just isn’t that great. There are too many examples of hits to the stock price, and even shotgun-wedding corporate mergers, which were triggered by large systems projects that really couldn’t go live all at once, even though they had every corporate plan to do so.
The Antidote is Building in Waves
See original here: Kicking Waterfall Project Management Habits Requires Agility
