This website covers topics on knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

How to Spot a Failing Project

Rick Cook at has a piece on How to Spot a Failing Project.  The article seems to be a promotion for a software company that is trying to help solve the problem.  I can't help but comment on the article after yesterday's post

The piece is broken into the early warning signs (lack of interest, poor communication, no-bad-news environment) and concrete signs (more overtime, diverted resources, financial metrics, unmet milestones, scope changes).  All of these sound almost too obvious as evidence the project is falling off the beam. 

Wouldn't it be interesting to have a mechanism to know how well a project is going to go before you start?  One item that the article mentions is that (IT) projects with labor costs over $10 million rarely succeed, and that those with labor below $750,000 tend to succeed.  This doesn't seem like enough information.

Here are some sure ways to doom projects.  Maybe this list is far too obvious too:

  • Start projects without having the full list of everything you need to complete the project.  In manufacturing, this would be the equivalent of starting a production run while missing raw materials.  Or shutting down key equipment for maintenance when the engineers are on break.
  • Initiate a project early "because we have the time."  This is a sure way to confuse the people assigned to multiple projects and create multitasking, which will slow ALL active projects.
  • Corollary: Release work into the system to "give people something to do."
  • Corollary: Require an individual to make "progress" on all their active tasks, rather than complete one at a time.
  • Too much detail in the project network can cause LOSS of control, not additional control.
  • Embedding safety at individual task level, rather than at the project level.
  • Management is asked to mediate every change or disruption in the project.  In other words, everything looks like an emergency for lack of metrics around priority / severity of impact.

Doing some or all of these things will give you the warning signs pointed to in the original article.

Managing distribution according to TOC principles

Why is my project late