The Independent Magazine
for Software Developers
developer.*
Books Articles Blogs Subscribe d.* Gear About Home

Success/Failure Criteria: Some Surprises

Published July 4, 2006

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.
RSS Feeds
Articles
Software Engineering Articles and Essays Feed Icon
Blogs
Software Engineering Blogs Feed Icon
Our newsletter policy:
No list sharing of any kind.
No "special offers" from "partners."
No "webinars." No "Special Reports."
No junk.
New developer.* Shirts & Accessories
A Jolt Award Finalist!
Software Creativity 2.0
Foreword by Tom DeMarco
Google
Web developer.*

All content copyright ©2000-2006 by the individual specified authors (and where not specified, copyright by Read Media, LLC). Reprint or redistribute only with written permission from the author and/or developer.*.

www.developerdotstar.com