IT Project Failure Rates

Different projects have different definitions of "failing". I can tell you
that from my perspective more than 35%, perhaps 50% or more, of projects at
least go over budget. It's entirely plausable that 35% are either aborted
before completion or completely re-engineered before their original life
expectancy expires. The weakest link is typically poor system design
documentation and middle tier project leadership.
"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:Oyk9q%23Z6FHA.4012@.TK2MSFTNGP14.phx.gbl...
> I'm posting to this question to the selected NGs because I'm interested in
> getting the viewpoint from within the "trenches" (not from academia or the
> big consulting firms).
> At the launch last Monday, one of Steve Ballmer's early slides presented
> the fact that something like 35% of IT projects fail. I just did a bit of
> research and found lots of studies supporting that point (e.g.,
> http://www.it-cortex.com/Stat_Failure_Rate.htm).
> Apparently projects fail on a number of measures... way over budget, way
> behind schedule, business objectives of the system not met within one year
> of going live, etc...
> Just wondering what some of your opinions are for *why* the failure rates
> are so high? I mean, with all the "smart" programmers out there, how come
> projects fail so often (or is it the IT managers who fail? Both? Other?).
> I'm thinking there has to be common thread amongst these failures and
> lessons to be learned.
> Thanks.
>Thank you JT and others.
What do you all think is the *likelihood* that big projects fail because,
for various reasons many people on the project *want* for the failure to
happen? Apparently the larger the budget the more likely the failure. Of the
various definitions of "failure" two involve [over budget] and [way beyond
deadline]. Practically everybody on a large team *benefits* from those
specific and prevalent types of failure (EXCEPT perhaps for the people who
are *paying* for the system in question and of course the users). You budget
8 million dollars for a project and suddenly you need a whole army of people
to manage (spend) that money. Anyone who can pay 8 million for a system can
surely pay 9 million and maybe even 10 million. You get to 10 million,
you're 6 months behind schedule and you can finish it for just another 1.5
mil. What happens if things happen on budget and on time. Well, that whole
army hired to build the system is suddenly out of work. The cash cow is gone
and everybody has to suddenly justify thier positions. But keep the project
going and... well.. you get the picture. Of course we all know how easy it
is to diffuse responsibility on any IT failure of any size (i.e. get off the
hook "scott free").
Thoughts?
"JT" <someone@.microsoft.com> wrote in message
news:uTET03e6FHA.2192@.TK2MSFTNGP14.phx.gbl...
> Different projects have different definitions of "failing". I can tell you
> that from my perspective more than 35%, perhaps 50% or more, of projects
> at least go over budget. It's entirely plausable that 35% are either
> aborted before completion or completely re-engineered before their
> original life expectancy expires. The weakest link is typically poor
> system design documentation and middle tier project leadership.
> "Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
> news:Oyk9q%23Z6FHA.4012@.TK2MSFTNGP14.phx.gbl...
>|||"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:OTPacAg6FHA.2156@.TK2MSFTNGP14.phx.gbl...
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of
> the various definitions of "failure" two involve [over budget] and [way
> beyond deadline]. Practically everybody on a large team *benefits* from
> those specific and prevalent types of failure (EXCEPT perhaps for the
> people who are *paying* for the system in question and of course the
> users). You budget 8 million dollars for a project and suddenly you need a
> whole army of people to manage (spend) that money. Anyone who can pay 8
> million for a system can surely pay 9 million and maybe even 10 million.
> You get to 10 million, you're 6 months behind schedule and you can finish
> it for just another 1.5 mil. What happens if things happen on budget and
> on time. Well, that whole army hired to build the system is suddenly out
> of work. The cash cow is gone and everybody has to suddenly justify thier
> positions. But keep the project going and... well.. you get the picture.
> Of course we all know how easy it is to diffuse responsibility on any IT
> failure of any size (i.e. get off the hook "scott free").
> Thoughts?
First of all, if you work for a company where all software projects fail,
how long do you think that company will stay in business?
I find that Cash Cows have a very short life span (if you exclude
government).
If you're out for a quick buck, find a cash cow.
If you want to make a career of this, find a company that has a proven
development track record, one that takes budgets and deadlines seriously.
Second, I'd rather have on my resume the fact that I work(ed) for a company
that had a 50% development success rate than a 10% one.
I'd rather also hire that person.|||Thanks Raymond. I agree with all your points. Also, this isn't about me.
It's about those 35% that reportedly fail. Also, in a big mega corporation
or big bank, 8 million can get totally blown and nobody gets fired and the
business just keeps chugging along. Small cash cows can't last long - but if
the cow is big enough it can get repeatedly milked.

> First of all, if you work for a company where all software projects fail,
> how long do you think that company will stay in business?
> I find that Cash Cows have a very short life span (if you exclude
> government).
> If you're out for a quick buck, find a cash cow.
> If you want to make a career of this, find a company that has a proven
> development track record, one that takes budgets and deadlines seriously.
> Second, I'd rather have on my resume the fact that I work(ed) for a
> company that had a 50% development success rate than a 10% one.
> I'd rather also hire that person.|||In many cases the scope of the system currently under development bears
little resemblance to the scope as defined in the original requirements
documents. It's not that the developers are taking twice or thrice as long
to complete the project, but that the project management and client allowed
the scope to creep wihout going back and extending the requirements and
budget. Some clients actually like this informal arrangement, becuase they
don't feel painted into a corner, and becuase they think they are saving
money by not putting additional effort into hard analysis and design. They
simply expect the contractors to keep them happy from one day to the next,
and in return they keep the money trickling in. In that case, you are
basically an IT whore. If this is what you choose or if your options are
limited, then at least make sure they are paying you well.
As for situations where the developers (or even the factions within the
client's own organization) actually want the project to fail; this is can
happen for a number of reasons. If you think you are observing it, then it
may not simply be your paranoid imagination, and if you are independent
consultant, then it was probably the plan from the very start. Ed Yourdon
describes this in his book "Death March: The complete software developer's
guide to surviving projects that are "doomed to fail.".
http://www.informit.com/bookstore/p...0146595&redir=1
"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:OTPacAg6FHA.2156@.TK2MSFTNGP14.phx.gbl...
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of
> the various definitions of "failure" two involve [over budget] and [way
> beyond deadline]. Practically everybody on a large team *benefits* from
> those specific and prevalent types of failure (EXCEPT perhaps for the
> people who are *paying* for the system in question and of course the
> users). You budget 8 million dollars for a project and suddenly you need a
> whole army of people to manage (spend) that money. Anyone who can pay 8
> million for a system can surely pay 9 million and maybe even 10 million.
> You get to 10 million, you're 6 months behind schedule and you can finish
> it for just another 1.5 mil. What happens if things happen on budget and
> on time. Well, that whole army hired to build the system is suddenly out
> of work. The cash cow is gone and everybody has to suddenly justify thier
> positions. But keep the project going and... well.. you get the picture.
> Of course we all know how easy it is to diffuse responsibility on any IT
> failure of any size (i.e. get off the hook "scott free").
> Thoughts?
>
>
> "JT" <someone@.microsoft.com> wrote in message
> news:uTET03e6FHA.2192@.TK2MSFTNGP14.phx.gbl...
>|||Jordan R. wrote:
> Thank you JT and others.
> What do you all think is the *likelihood* that big projects fail because,
> for various reasons many people on the project *want* for the failure to
> happen? Apparently the larger the budget the more likely the failure. Of t
he
> various definitions of "failure" two involve [over budget] and [way beyond
> deadline]. Practically everybody on a large team *benefits* from those
> specific and prevalent types of failure (EXCEPT perhaps for the people who
> are *paying* for the system in question and of course the users). You budg
et
> 8 million dollars for a project and suddenly you need a whole army of peop
le
> to manage (spend) that money. Anyone who can pay 8 million for a system ca
n
> surely pay 9 million and maybe even 10 million. You get to 10 million,
> you're 6 months behind schedule and you can finish it for just another 1.5
> mil. What happens if things happen on budget and on time. Well, that whole
> army hired to build the system is suddenly out of work. The cash cow is go
ne
> and everybody has to suddenly justify thier positions. But keep the projec
t
> going and... well.. you get the picture. Of course we all know how easy it
> is to diffuse responsibility on any IT failure of any size (i.e. get off t
he
> hook "scott free").
> Thoughts?
The likelihood? No earthly idea how to evaluate that. It *can* happen that
way
- but might that not suggest that management is somehow providing an incenti
ve
when it does?
Really I have to agree with Fred E. here - there are a *lot* of holes that l
arge
projects can fall into - and most of them were identified quite well by Broo
ks
many years ago.
JT, in your original post you sounded like you were just curious in an acade
mic
way about how and why IT projects fail. Now though you are sounding more li
ke
someone who has been badly burned recently. Is this correct? If so, this m
akes
me curious about your POV - developer, architect, project manager, product
manager, innocent bystander or . . . ?
-rick-|||Re:
<< JT, in your original post you sounded like you were just curious in an
academic
> way about how and why IT projects fail. Now though you are sounding more
> like someone who has been badly burned recently. Is this correct? If so,
> this makes me curious about your POV - developer, architect, project
> manager, product manager, innocent bystander or . . . ?
Are you referring to JT or the the original poster? I'm the latter.
To answer your question, I was the "technical lead" (that's the title they
gave to me anyway) on a large system at a large company. The system was
great. Me and another guy architected then built it from scratch (designed
the database, wrote all the code, and lead a team of support developers to
complete the implementation). We delivered, hit our Y2K deadline with room
to spare, and life was good for a couple of years. Then new management came
in and they wanted [a system] like ours that had - say 14 features. We went
to them with "good news" and said we already had 11 of those features and
the remaining could be added within 9 months (a perfectly acceptable time
line to them). Strangely, a few of us who knew how easily the existing
system could be extended to meet all desires/needs got railroaded out of
town. After I left they ended up budgeting millions of dollars for a
complete new/replacement system. Fast forward 2.5 years to the present. They
just canned the whole new system and completely migrated back to the one I
had left them with years before. In fact they never completely migrated OFF
of my system. In other words they are part of the 35% that fail (in their
case both over budget and way over deadline). They even hired an outside
consulting firm to come in and advise on how to fix the replacement system.
The outside firm basically told them it could not be fixed. In essence -
they totally failed. Then last w Ballmer presents his 35% failure rate
and I do some research to see who else is saying that. Until learning that
this sort of huge failure happens all the time, I had chalked up my former
client's situation to the particular organization. But if it's happening all
them time, then come on - there's more going on than just bad planning or
poor project management. I think it's plain and simple *greed* at
practically all levels that may be the "Super Explanation" from which the
poor planning and managemnet and communication etc flow. Yes, all those
other things happen all the time. But come on. They are continually
*allowed* to happen. Why are they allowed to happen all the time? Greed -
IMO.
Please don't think this thread is all about any old grudge. I'm several
years removed from all that. I was just surprised to see that it happens in
many organizations OTHER than the one I was in. That's why I'm looking to my
peers here in these NGs to learn what you are all seeing. I think I have to
ask you because if I were to just listen to academia and big consulting
firms or software vendors peddling their Team solutions then I'd be lead to
believe that we just need to communicate better; test earlier; test more
systematically; have UML save the day; organize ourselves into 2-person
developer teams (i.e. Extreme methodologies). etc. But none of those address
greed and the associated desire (unconscious perhaps) for systems to go over
budget and beyond deadline or ultimately fail.
Thanks for your feedback.|||Jordan R. was the OP, but any of us who have been in IT for more than 10
years have a story to tell.
"Rick Lones" <WrlonesX@.YcharterZ.net> wrote in message
news:%Psef.73821$RG4.16336@.fe05.lga...
> Jordan R. wrote:
> The likelihood? No earthly idea how to evaluate that. It *can* happen
> that way - but might that not suggest that management is somehow providing
> an incentive when it does?
> Really I have to agree with Fred E. here - there are a *lot* of holes that
> large projects can fall into - and most of them were identified quite well
> by Brooks many years ago.
> JT, in your original post you sounded like you were just curious in an
> academic way about how and why IT projects fail. Now though you are
> sounding more like someone who has been badly burned recently. Is this
> correct? If so, this makes me curious about your POV - developer,
> architect, project manager, product manager, innocent bystander or . . . ?
> -rick-|||Jordan R. wrote:
> Re:
> << JT, in your original post you sounded like you were just curious in an
> academic
>
>
> Are you referring to JT or the the original poster? I'm the latter.
To you, Jordan - thanks for the clarification.

> To answer your question, I was the "technical lead" (that's the title they
> gave to me anyway) on a large system at a large company. The system was
> great. Me and another guy architected then built it from scratch (designed
> the database, wrote all the code, and lead a team of support developers to
> complete the implementation). We delivered, hit our Y2K deadline with room
> to spare, and life was good for a couple of years. Then new management cam
e
> in and they wanted [a system] like ours that had - say 14 features. We wen
t
> to them with "good news" and said we already had 11 of those features and
> the remaining could be added within 9 months (a perfectly acceptable time
> line to them). Strangely, a few of us who knew how easily the existing
> system could be extended to meet all desires/needs got railroaded out of
> town. After I left they ended up budgeting millions of dollars for a
> complete new/replacement system. Fast forward 2.5 years to the present. Th
ey
> just canned the whole new system and completely migrated back to the one I
> had left them with years before. In fact they never completely migrated OF
F
> of my system. In other words they are part of the 35% that fail (in their
> case both over budget and way over deadline). They even hired an outside
> consulting firm to come in and advise on how to fix the replacement system
.
> The outside firm basically told them it could not be fixed. In essence -
> they totally failed.
Wow - quite a story. Any chance you can still sell them those remaining 3
enhancements? Your credibility should be way up with them by now. :)
Then last w Ballmer presents his 35% failure rate
> and I do some research to see who else is saying that. Until learning that
> this sort of huge failure happens all the time, I had chalked up my former
> client's situation to the particular organization. But if it's happening a
ll
> them time, then come on - there's more going on than just bad planning or
> poor project management. I think it's plain and simple *greed* at
> practically all levels that may be the "Super Explanation" from which the
> poor planning and managemnet and communication etc flow. Yes, all those
> other things happen all the time. But come on. They are continually
> *allowed* to happen. Why are they allowed to happen all the time? Greed -
> IMO.
Truthfully, I think that the demand for large complex systems has way
outstripped the supply of people qualified to build them. Hence the rise of
RAD
environments and powerful paradigms and languages such as OO and C++ which t
o
some hold out the promise of some silver bullet. To take C++ as an example:
IMO
this is a sophisticated language, quite well worked out by a smart well-educ
ated
guy - and completely appropriate for use on large engineering projects by ot
her
smart well-educated people. But in the wrong hands it's just a great way to
make a huge mess quickly - and with the best of intentions. I don't mean to
claim that most programmers are too stupid to understand OO or C++, but many
who
use these tools seem insufficiently prepared and/or lacking the experience t
o
use them well. And if you are using them less than well then IMO you just m
ight
have been better off with COBOL . . .

> Please don't think this thread is all about any old grudge. I'm several
> years removed from all that. I was just surprised to see that it happens i
n
> many organizations OTHER than the one I was in.
Everybody always seems to overestimate other people's competence. It's stil
l
true that 90% of *everything* is crap - and this includes management teams.
Programming isn't easy and most people can't do it at all, let alone well.
That's why I'm looking to my
> peers here in these NGs to learn what you are all seeing. I think I have t
o
> ask you because if I were to just listen to academia and big consulting
> firms or software vendors peddling their Team solutions then I'd be lead t
o
> believe that we just need to communicate better; test earlier; test more
> systematically; have UML save the day; organize ourselves into 2-person
> developer teams (i.e. Extreme methodologies). etc. But none of those addre
ss
> greed and the associated desire (unconscious perhaps) for systems to go ov
er
> budget and beyond deadline or ultimately fail.
Hmm, I *think* I see what you are getting at here - the proposed remedies se
ldom
rise above being just more magic bullets. "Do A, do B, do C, then your prob
lems
will be over and your organization will have (somehow) become competent." I
t
seems a bit naive, but the overselling of methodologies is ubiquitous.
I am not so sure about fingering greed and spooky unconscious motivations as
the
root of all problems though. Among other things we are all in this hoping t
o
make a living. Now if what you are pointing out is, "beware, the whole syst
em
is badly broken", then I might even agree - but IT system development is har
dly
the most pressing example of that.
Regards,
-rick-|||Re:
<<Any chance you can still sell them those remaining 3 enhancements? Your
credibility should be way up with them by now. :) >>
No way man! I had all the credibility I needed back when they initiated this
debacle. It's not at all about credibility - never was. I had as much of
that as anyone can get. (actually had one of those "only heard about" 20
minute - to - 20 second process enhancements to my credit; the internal
customers loved me for that one).
It apparently was *really* about them spending 8 mil.
Here's how it went (I'm pretty sure, in retrospect)
Me: "hey - check this out - you can have everything you want - all for about
300 large in about 9-10 months"
Them: "ohMyGosh - I can't build my little internal corporate empire if word
about this gets out. I just proposed a multimillion dollar system that got
approved. There's no way I can go back on that. Plus I just hired my
Alcoholics Anonymous Buddy as my admin assistant. I can't put us both out of
work..."
Now, looking forward for them, they're back a "square 1" with this system.
No one was fired over this - so we can know there were no *real* penalties
for failure. So this leaves them to do - guess what - propose the next
system! It's going to get its own budget too... same people in charge...
Re:
<<I am not so sure about fingering greed and spooky unconscious motivations
as the root of all problems though. Among other things we are all in this
hoping to make a living.>>
LOL - agreed about the spooky motives thing. But there is more of a living
to be made in many situations when the project fails (when, of course, there
is no real penalty for failure). That's all I'm trying to find out here - if
others see the same thing in their organizations.
I appreciate your perspective Rick.