How to Challenge Waterfall Project Management

Posted on: July 26th, 2012 - Written by: Tom Metz

Waterfall project management is basically a relic of how IT worked in the slower and more predictable 20th century. Its prevalence is deteriorating – giving way to more responsive ways of operation in our 21st century real-time environment – such as agile project management. At a very basic level, the difference in the two is defined by how they treat change. The waterfall method reacts to change and agile methodology embraces it and works in it. Despite the changes in the nature of IT, there are still instances where waterfall methodology is still used.

To adopters of agile development and project management methodologies, it seems ridiculous that there are those who are intent on sticking with the with big bang deployments that employ waterfall project management.

A deeper dig may reveal that a slash-cut from one system to another is a management demand and that IT needs a few pointers on how to push back when their development methodologies are being dictated to them. If this is all transpiring at the whim of management, IT needs to intervene immediately.

A potential push-back agenda:

  1. There are several items they should have on their agenda when they deliver their push back:
  2. Can they illustrate how the big bang or slash-cut deployment is the best business value?
  3. What are the risk factors and are they lower than other methods or deployments?
  4. Will the systems’ integration have to be staged out or will this take place at the same time as initial deployment? If it is staged, how will that impact availability of all business processes?
  5. How will the transition impact data? Will it be ready for transition at deployment and will it be transitioned all at once? If everything is transitioning at the same time, how is risk to the data mitigated?
  6. How will the transition impact users on the employee and customer sides? Will these groups be able to make immediate transition?

There is actually a valid reason for staying with waterfall project management and it is more of a challenge to change because it has real merit. A new system is replacing an existing one. There are valid business reasons for not running two systems in parallel and for refusing to needlessly duplicate data sets.  There are times when – due to logistical and customer reasons – a single cutover must be done.

If this must happen, the best advice is to be realistic. There is no chance that this transition will take place in one weekend or one month – even when the corporate plan dictates it.  Part of being realistic is having a plan to accommodate the near-impossible task: Build in waves. Liken it to redecorating one room of a house at a time instead of creating havoc in all over the place.

  • Break large projects down into smaller components.
  • Identify areas of stability and change.
  • Design change to be autonomous, transparent and safe.
  • Add new features incrementally.
  • Make additions in sprints, regularly testing for stability.
  • Validate infrastructure, integrations and data.
  • Expose the user features last.
  • Gain the trust of the organization by quickly and predictably delivering small components.

This – in essence – applies agile principles to a waterfall schedule.

Replacing a system or merging two running systems makes the process more complex.

Staging the cut-over is the best – and least risky – approach that will accomplish the changes while minimizing business disruption:

  • Keep the existing system(s) running as the system(s) of record throughout the construction and validation of the new system.
  • Use pilot users and provide them with a clean subset of the data they work with.
  • Bring the pilot users into the system as the validation phase is being completed. At this point, they should be using the old system as well as the new one.
  • Do not expand the new system and data to other users until the pilot users have validated it. Keep tight control over the expansion to other users – even when management is screaming for more, faster now. Slow down the deployment to new users if issues crop up. Moving incrementally eliminates the necessity to back-track.
  • Use the pilot users’ success to market the project with those who are resisting.

In this wave approach, the date of the final user group’s move to the new system should fall months after the pilot go-live date.

What will it take to lower risk and increase the potential for good project ROI, besides robust data synchronization and a configuration-control infrastructure that spans the old systems and the new one? The buy-in of management that will hopefully be won by presenting the aforementioned push-back agenda.

Tags: , , ,

Leave a Reply