Kicking Waterfall Project Management Habits Requires Agility
Things that won't die are great for the movies, but bad ideas that won't go away can really hurt cloud projects. Unfortunately, management likes classic, counterproductive waterfall project management and binary go-live deployments for cloud projects.
Fri, May 11, 2012
CIO — In last week's article, we covered the stuff of zombies, vampires and antidotes for bid-to-win behaviors that can suck the life out of cloud projects—you know, the sort of images that are the standard fare of CIO articles. This time, we're looking at one of the underlying causes of bid-to-win: the classic waterfall project management habits that come straight from, you guessed it, the construction industry.
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.