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…
- “Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
- Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
- Schedules: Too tight, unrealistic, overly optimistic.
- Planning: Based on insufficient data, missing items, insufficient details, poor estimates.
- 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?
Related posts:
Leave a comment
Protect the Fourth Amendment
Intro
Recent Posts
Categories
Archives
- May 2012 (8)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)
BrainsLink on Twitter
- The world's hottest social network isn't #Facebook http://t.co/MEAOQ01n via @ifw_cringely / go #twitter! 5 hours ago
- Top 7 Smart #Mobile #Apps for Commuters http://t.co/vYfw90pe via @arkarthick / good list 11 hours ago
- Here's a #FF shoutout to: @Colabpro @VersionOne @AllanKellyNet @flowchainsensei @ChristopherAver @SQAConnect @rkelly976 @agilescout 12 hours ago
- It Takes 6 Days to Change 1 Line of Code http://t.co/A024IgmT via @edw519 / not #funny but so true 13 hours ago
- Retweet New post: Define Audiences, Specify Outcomes, or #Failure Will Stalk You http://t.co/Es35VM7C #swdev #pmot 13 hours ago




