IT Strategy

10 Truths about Project Planning

October 9, 2009 by Raj Sheelvant

Baseline Article titled “10 Truths about Project Planning” lists these 10 items.  I have listed them below.  Issues with software project planning are well known but when you start quantifying them it looks scary.  I think we in the IT area should take these finding seriously and looks for way to improve these numbers.  With the focus on cost cutting and belt tightening in the corporate world, IT Project Manager needs to be proactive in systematizing project variability.

1. Approximately 68% of companies surveyed were statistically unlikely to run a successful project, based on the findings in the survey.
2. Companies with poor business analysis are three times as likely to see their projects fail.
3. Bad project requirements can exact up to a 60% hike in budget and time.
4. For a $3 million budgeted project using a set of poor requirements, companies will pay an average of $5.87 million.
5. The typical organization tends to use up 41.5% of new project development dollars on unnecessary or poorly specified requirements.
6. When non-IT business leaders set project requirements, projects come in at:
   • 196.5 % of the target budget
   • 245.3 % of the target time
   • And 110.1% of the target functionality originally set by requirements
7. When IT leaders set project requirements, projects come in at:
   • 162.9 % of the target budget
   • 172 % of the target time
   • And 91.4 % of the target functionality originally set by requirements
8. When a mixed team of IT and non-IT leaders set project requirements, projects come in at:
   • 143.4 % of the target budget
   • 159.3 % of the target time
   • And 103.7 % of the target functionality originally set by requirements
9. Over 50 % of organizations do not have the basic business processes and procedures in place to establish effective business and software requirements for new projects.
10. Project failure associated with poor requirements can be slashed on over 80 % of projects by auditing three areas within requirements documentation:
    • Uncovering interdependencies
    • Setting ambiguous goals
    • Documenting information required to support the process.

Popularity: 1% [?]

Related posts:

1. 2010, The Year of IT Project Managers?
2. IT Project Manager with Leadership skills
3. Evolving role of the IT Project Manager
4. What’s the role of IT Business Analyst?
5. Smaller and Faster IT Projects