Standish: Project Success Rates Improved Over 10 Years

Twelve years ago my technical writing, training and usability company salespeople used to quote a new study called "Chaos" done by The Standish Group of West Yarmouth, MA, to show the desperate condition of IT-generated projects. We had solutions, of course, centered around communications and more frequent feedback. At that time, IT project failure rates ran close to one-third. Adding in troubled projects, brought the complete-success rate down to about 20%.

Now some good news, The Standish Group has updated the study every two years, and things have improved, as the article below from softwaremag.com shows. Note that projects have gotten smaller and more iterative. This means more cycles of user feedback are being incorporated. In other words, the SYSTEM for developing has better communication built in, which is particularly responsive to changing conditions. David Orr

"The 10th edition of the annual CHAOS report from The Standish Group, which researches the reasons for IT project failure in the United States, indicates that project success rates have increased to 34 percent of all projects. That's more than a 100-percent improvement from the success rate found in the first study in 1994.

Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, "The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward." The Standish Group has studied over 40,000 projects in 10 years to reach the findings. Project failures have declined to 15 percent of all projects," more.........http://www.softwaremag.com/L.cfm?doc=newsletter/2004-01-15/Standish
_____

Orr's Aphorisms™08/29/2006 (updated weekly)

• Clients don't care about process, just results. Process is, nevertheless, important to teamwork.
• Don't rescue clients or teammates. People begin to expect to be rescued, in fact, plan on it.
  Decentralize/coordinate rather than centralize/control.
• Mentor , mentor, mentor junior people. Delegate juicy things, not just unpalatable things, to subordinates to keep their enthusiasm high.
• Some people start learning with the big picture; some people start with the details. Either way is OK.
• Some people move very fast in a certain direction and change course very fast if the direction is wrong. Others don't move until they have researched and planned carefully to choose the right path. Both ways work, and often the two types of people get to the same place at about the same time.

David Orr

Assumptions

Assumptions are deadly in business. 1. We assume something has been done, that has not. 2. We assume something has not been done that has. 3. We assume someone believes something that they don't. 4. We assume someone knows something that they don't. 5. We assume someone doesn't know something that they do. 6. There may be other examples, but you get the idea. Here's a user interface designer's experience with assumptions.

Attack of the killer Assumptions (and how to overcome them)0 Comments Published August 22nd, 2006 in user experience, process, Carrie Bradshaw moments
Assumptions are something we battle in kinds of ways. I know when I was doing more project management, trying to get a handle on project assumptions and documenting them was a necessary challenge. Understanding and documenting assumptions was critical to managing my client’s expectations, and making sure that it was actually possible for me to […]