Slashdot Mirror
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.'"
That 31%-flat-failure rate sounds just about right; about a third of the projects I've worked on over the last 15 years have been complete flops (with the usual list of various reasons from "bad idea to begin with so it needed killin' " to "we changed bosses and since your project wasn't the new boss' idea..."), but I'd have to challenge the notion from TFA that they "produced nothing useful", because I've learned something I didn't know and wouldn't have otherwise known from each of them -- in other words, I'd count them all as at least partial successes because I personally gained something from them.
This space intentionally left (almost) blank.
'Twas the night before implementation and all through the house,
Not a program was working not even a browse.
The programmers hung by their tubes in despair,
with hopes that a miracle would soon be there.
The users were nestled all sung in their beds,
while visions of inquiries danced in their heads.
When out in the machine room there arose such a clatter,
I sprang from my desk to see what was the matter.
And what to my wondering eyes should appear,
but a super programmer (with a six-pack of beer).
His resume glowed with experience so rare,
he turned out great code with a bit-pusher's flair.
More rapid than eagles, his programs they came,
and he cursed and muttered and called them by name:
On update! on add! on inquiry! on delete!
on batch jobs! on closing! on functions complete!
His eyes were glazed-over, fingers nimble and lean,
from weekends and nights in front of a screen.
A wink of his eye, and a twitch of his head,
soon gave me to know I had nothing to dread.
He spoke not a word, but went straight to his work,
turning specs into code; then turned with a jerk;
And laying his finger upon the "ENTER" key,
the systems came up and worked perfectly.
The updates updated; the deletes, they deleted;
the inquiries inquired, and closings completed.
He tested each whistle, and tested each bell,
with nary an abend, and all had gone well.
The system was finished, the tests were concluded.
The users' last changes were even included.
And the user exclaimed with a snarl and a taunt,
"It's just what I asked for, but not what I want!"
One problem I see, is that many IT projects begin with the goal of making the project manager look good.
The proper way to start a project is: How can we fix BAD THING. Instead of the usual "We should migrate this to SAP cause that would look so cool on my review".
Many times IT projects become a destination, instead of a method to reach the companies destination be it ( manufacturing / sales / service ).
- High Tech workers, please say NO to Union Carpenters, their Union sees fit to control our compensation.