Identifying (and Fixing) Failing IT Projects

Esther Schindler writes "Often, the difference between the success and failure of any IT project is spotting critical early warning signs that the project is in trouble. CIO.com offers a few ways to identify the symptoms, as well as suggestions about what you can do to fix a project gone wrong. ' The original study (which is still sometimes quoted as if it were current) was shocking. In 1994, the researchers found that 31 percent of the IT projects were flat failures. That is, they were abandoned before completion and produced nothing useful. Only about 16 percent of all projects were completely successful: delivering applications on time, within budget and with all the originally specified features. "As of 2006, the absolute failure rate is down to 19 percent," Johnson says. "The success rate is up to 35 percent." The remaining 46 percent are what the Standish Group calls "challenged": projects that didn't meet the criteria for total success but delivered a useful product.'"

Re:Not just "minds". But also people.

[j-pimp]

The big projects fail because they take long enough that people change their minds (so requirements don't stay fixed) and because there's too much communication overhead (the old "management wants status reports more often, because we're falling behind" situation).

Try planning a project that will take 5 years and $10 million.

People WILL leave the organization during that time. They will be replaced. If it was a tech, will the new tech do things the same way as the old one? Will you have hammered down your process so that s/he will HAVE to do it the same way?

Will any tech worth his salt WANT to do things the same way as the old guy without questinging anything? Personally when I enter a new company, a large part of "getting adjusted" is fighting every foreign idea tooth and nail. I come to terms with them shortly, but I can't accept them as useful until I see them.

Re:As long as you're up front about it

[Dan Ost]

Marry a doctor. I really do like what I do, but I also like the fact that what I do is OPTIONAL.

What I'm guessing

[mcalwell]

In 1994, a person of my ability and intelligence would have struggled to write software that delivers. Because so much can be achieved now with scripting languages, standards like XML, and with so much support and documentation available online, so much more can be done more quickly, and be done more transparently, with less intelligence, than in the past.

I did systems support in a big financial in 1997. Software was written in C++ on Windows. Builds would run overnight. Something wrong? Could be an OS thing, or a progam thing. DLL hell ensued. Process: debug problem, relink, recompile. Next day, retest. OK, so software passes testing. Next - software distribution - a process that itself needs testing in dev environments. Package software. Hit button to distribute to X000 clients. Some Windows NT, some older.

So much to go wrong, so many people involved. I'm not saying there isn't complexity in modern environments, but standards, and particularly web based apps take so many variables out of the equation.