Success/Failure Criteria: Some Surprises Editor’s Note: the following article originally appeared in the July 2006 issue of The Software Practitioner, which is edited and published by Robert L. Glass. developer.* is grateful to Mr. Glass for allowing us to republish it here. Brisbane, Australia - At a breakfast seminar here June 6 on "Factors for IT Project Success and Failure," Prof. June Verner of NICTA (the National Information and Communication Technology institute of Australia) provided a fascinating mix of surprises and predictables related to her subject topic. The findings came from NICTA’s study of 400 projects in the U.S., Australia, and Chile, using questionnaires and interviews to discuss success and failure factors with practitioners. What were the surprises? Most projects that had no schedule were successful

Requirements are needed for project success, but not necessarily early in the project

Projects often continue successfully for some time with unclear requirements

The choice of requirements methodology does not matter; UML was "no help"

Using a development methodology was a success factor, especially when it was "appropriate to the application"

Very few projects use risk management, and those that do rarely manage those risks

Post mortem reviews are rarely held, and when they are it is almost always on successful projects

In the U.S. (but not elsewhere), developers are involved in project estimation only when there are poor requirements (Verner speculated that this is because the powers that be were looking for someone to blame!) And the predictables? Success comes from a culture that investigates and deals with problems

The vision for the project (its business goals) must be shared among all project personnel, especially the project manager

Project managers should be involved in the estimation activity

Project managers should be good at customer and developer communication; they need not be good at the technology There was some interesting data from the study, as well: 60% of organizations have no process to measure benefits

86% of projects had a business case, but 60% ignored it

33% of projects said they had no risks, but 62% of those failed

49% or organizations have had (one or more) project failures

In one-third of the projects, the project manager had no say in schedule/budget targets

75% of projects were underestimated, none were overestimated

5% of projects had no project manager; 16% changed project manager at least once (and that was correlated with project failure) Verner also asked developers what their criteria were for project success. They said: They had a sense they had delivered a quality product

They had a sense of achievement

They had enough independence to work creatively

The requirements were met and the system worked as intended ### Please visit this page for more information about The Software Practitioner. Robert L. Glass held his first job in computing in 1954. Author of over 25 books, he is one of the true pioneers of the software field. He is the editor and publisher of The Software Practitioner, and also writes regular columns for Communications of the ACM and IEEE Software. In 1995 he was awarded an honorary Ph.D. from Linkoping University of Sweden, and in 1999 he was named a Fellow of the ACM professional society. His unique viewpoint and timeless writings have for decades offered insights to practitioners, managers, professors, entrepreneurs, researchers, and students alike.