What is the Success Potential of Your Projects?

Introduction

The Standish Group releases a periodic Chaos report that summarizes typical IT and software development project success and failure rates in industry. Within the (very expensive) report is a table of success factors that have been gleaned from numerous surveys and interviews of IT managers during the previous period. In summary, 29 percent of projects were successful, 52 percent were challenged, and 19 percent failed.

Below is the list of the project success factors from 1994 to 2015* that contributed to a successful project.

Standish report success factors for projects

Great practices don’t change much over time

There is a lot of similarity in these lists over the years, with a few wording changes. For example, “Smaller Project Milestones” has been replaced with “Agile” which encompasses smaller milestones and feedback. Some terms have new names, such as, “Optimization,” which is the optimization of requirements and scope. This is similar to “Realistic Expectations.”

The fact that User Involvement was ranked first in 1994 and third in 2015, or that Proper Planning was then ranked fourth and is now ninth is mostly immaterial. Unless all the practices are being done to the degree an organization needs, no small subset of practices alone will make a project successful.

For example, gravitating to “Agile” alone without the other practices is like buying only the subframe of a new car; essential but not complete. Having a “proficiency” for Agile simply means that team members can do three things at a rudimentary level: planning, tracking and demos for feedback.

This list is a good (although ambiguous) set of criteria and provides a benchmark to consider. The overlap with other project management and engineering frameworks indicates that it is also an enduring list of basic practices that cannot be skipped without consequence.

How does your project score?

The table below includes the 2015 Standish list, and a rudimentary mapping to PMBOK**, CMMI** and Agile. The score column is the relative importance Standish has given each factor. Use that scale and score your projects against the criteria in the first column.

The absolute score doesn’t matter, only your next step

The absolute number does not really matter. The relative score gives you a simple baseline. What really matters is that you were able to identify strengths to repeat, and weaknesses to address.

Since the success criteria in the report is somewhat ambiguous, consider the details offered by PMBOK and CMMI (and other published frameworks) to define what to do.

If you have comments or questions about this article, or would like to get some helpful complementary feedback regarding your current state, contact us.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link.

Keep learning

If there are challenges your group is having that you would like us to anonymously address in future blogs let us know.

If you would like to know more about great practices, consider our Anytime webinars.

 

* 1994-2012 report summary by C. Carroll, — 2015 report summary by S. Hastie, S. Wojewoda.
** CMMI: Capability Maturity Model Integration, PMBOK: PMI Project Management Body of Knowledge

 

Our clients hire us to provide quick and effective improvements in their project management and engineering activities to reduce project delays, problems and rework. Try us.