Comments for How many of your IT projects fail? Too many

Comment from Jim McGee on 2007-11-12

2007-11-12T23:03:16Z

I've generally been quite skeptical of the Standish data.

As for failure rates, I actually think that a 1/3 failure might be about right and that most organizations ought to be shooting to increase their failure rate (essentially by increasing their overall number of "at bats").

Comment from Jack Vinson on 2007-11-13

2007-11-13T14:32:08Z

There are two takes on the failure rate. Mine was under assumption that these projects are (presumed) money-makers or operationally required. Essentially failed projects = lost revenue. I assume that you are thinking along the lines of innovation, where we should be trying as many different ideas as possible, rather than trying to analyze the idea to death before giving it a whirl. Here a failed project would not be lost revenue, but gained experience. Sure there is the expense associated with trying, but that has to be there.

Where else would you want to be increasing the number of "at bats" and be willing to lower your batting average?

Comment from Jim McGee on 2007-11-14

2007-11-14T14:17:43Z

I was thinking in terms of the overall portfolio of projects and risk assessments at both the individual project level and the overall portfolio level. And risk, of course, is a dynamic thing.

If you have no risk in your project portfolio, you should likely have no project failures. You're also likely to be outsourced as an IT organization as you aren't adding value to the organization (no risk = no reward). If you are taking risks, then you will have project failures. One question for an IT organization is whether your project management practices contribute to raising or lowering the overall risk of a project.

Comment from Jack Vinson on 2007-11-17

2007-11-17T06:58:49Z

One more test comment. Should not get automatically published, right?

Comment from Jack Vinson on 2007-11-17

2007-11-18T04:55:14Z

Thanks again, Jim.

I hadn't thought along these dimensions. Risk is clearly important. No risk, and "anyone can do it." Too much risk, and you don't have any customers. Where does the risk appear in accepting projects? Is it risk that the project will work at all, or risk in that some specific features / capabilities will make it?

At some point the organization needs to be making money... What does a high IT failure rate say about the ability to make money today -- an in the future? I'd find it difficult to believe anyone would hire a company that has 33% or 67% failure rates.