Waterfall Projects Are Always In Trouble

Project Management Solutions conducted a survey of senior executives and project managers to determine “Strategies for Project Recovery” (pdf download). What I found most interesting is the section titled “Causes of Troubled Projects”.

They came up with these top five causes of troubled projects…

  1. “Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
  2. Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
  3. Schedules: Too tight, unrealistic, overly optimistic.
  4. Planning: Based on insufficient data, missing items, insufficient details, poor estimates.
  5. Risks: Unidentified or assumed, not managed.”

There is no mention of any specific project methodology in the report but the causes above strongly suggest to me that waterfall was widely followed. Here’s why I say that.

1. Requirements are frequently cited as a problem area on waterfall projects — and they are. Why managers continue to believe that they can fully specify every feature and function of a software system at the outset of the project baffles me. In a dynamic business environment, it cannot be done. (In static environments, it’s possible but I’ve never worked in a static environment and I refuse to do so.)

2. Resources are often under-estimated and it’s easy to see why. If you don’t fully understand the requirements, how can you possibly define the resource needs? Unfortunately, the waterfall approach demands resource estimates up front.

3. Schedules are always overly optimistic — always. Add in items 1 and 2 above and the project is in huge trouble before it even starts. Again, waterfall needs to have schedules defined at the start.

4. Planning with accuracy is impossible in light of the above. It becomes a complete waste of effort. Waterfall advocates like to plan, re-plan and plan some more. How do they get anything done?

5. Risk management is a largely overlooked area on many projects. It seems that managers just don’t want to think about risks and their potential adverse effects. Face it, most of us don’t want to plan for catastrophic illness or death. The same is true for our projects. (This problem is not unique to waterfall. Agile projects also have this issue.)

What’s the solution?

  • Forget requirements and tell stories instead.
  • Bring in resources as needed including using temporary workers to cover peak demand.
  • Either allow schedules to flex or fix them and allow features to flex. You can’t have it all.
  • Plan less, deliver more. Let the deliverables guide the planning.
  • Evaluate, prioritize and mitigate risks on every project.

Be agile.

Agile approaches to software development like Scrum, XP and Kanban do not guarantee success. Nothing does. But, agile approaches reduce risk, improve quality and keep the software development and business teams in sync. It’s worth a try, isn’t it?

Updated: April 5, 2011 — 10:13 pm