This Guest paper was originally published on LinkedIn in May 2016.*
It is reproduced here with the permission of the author.
Copyright Craig Imlach © 2016.
Published here April 2017

Introduction | Project Tradition | Elements of Change
Validation of Assumptions and Estimates | Constraints and Business Rules | Postscript

Craig Imlach is an independent consultant providing services covering business improvement, transformation of IT services, development of business strategy, implementation of support teams and processes, and improving project delivery. He has undertaken work ranging from simple implementation projects to managing highly complex business change initiatives. For example, over the years he has been required to review or takeover a number of projects that were facing difficulty. From this work he has developed a number of leading indicators that he uses to evaluate a project's risk of failure. Craig may be reached at

The approach I use to evaluate an Information Technology (IT) project's probability of failure is very much a heuristic one. My Leading Indicators are designed to steer the thinking through the issues rather than provide specific results. Thus the approach is a subjective review rather than any clearly defined objective approach.

There are many sources of information that point to specific examples of how projects fail, ranging from lack of stakeholder engagement, to poor requirements definition, to constant requests for change. In my view many of these are symptoms of more fundamental underlying problems. Therefore, from my experience the following are the items that, if addressed during a recovery effort, provide the basis of a project turnaround.

1. Size

The easiest leading indicator of increased risk of project failure relates to the size of the project as reflected by the budget; the schedule; the team size; and number of teams involved. Indeed, risk of project failure seems to double as the project:

  1. Exceeds a budget of $1M
  2. Exceeds a schedule of 12 months
  3. Crosses a budget period change (e.g., FY2015/16 to FY2016/17)
  4. Team size exceeds 30 people (+/- 8)
  5. There are more than 3 teams responsible for delivering elements.

Statistics from the Standish Group's Chaos Report seem to validate this by reporting that small projects are far more successful than larger projects.


Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page