OT: IT Project Failure Rates

[Jordan R.]

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.

 

[jeremiah johnson]

in my experience, projects fail because key talent leaves the company.

I've seen it happen a dozen times at least, and in most cases,
management speaks of how important [key person] is, but according to
[key person], no attempt is made by management to keep [key person]
happy. I'm not talking about exhorbitant demands, i'm talking about
things like paying for overtime worked, and allowing vacation time to be
taken instead of rejecting vacation requests.

management ALWAYS make these mistakes, and they NEVER see it coming when
[key person] leaves.

 

[Stefan Berglund]

On Mon, 14 Nov 2005 20:47:25 -0800, "Jordan R."

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.

If you'll excuse the analogy, a baseball team can have a lot of high paid stars
but they probably won't win the World Series or otherwise be successful without
a great team effort. Every successful project requires a team effort. In the
absence of that team effort and the factors that go together to motivate it, the
road to failure is an easy one. No doubt Ballmer would have you believe that he
and Microsoft have all the answers to help you bring your projects to a
successful conclusion.

 

[Chris2]

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.

Jordan R.

The issues involved are complex.

Here are some thoughts:
http://www.stsc.hill.af.mil/crosstalk/2005/03/0503Humphrey.html.


Sincerely,

Chris O.

 

[shiv_koirala]

I think the percentage would be more.But falure factors can be many
resource retaining , bad architecture or over smart architecture ,
client changing blah blah. I think a proper project management is
answer to failures
---------------------------
Regards ,
C#, VB.NET , SQL SERVER , UML , DESIGN Patterns Interview question book

http://www.geocities.com/dotnetinterviews/
My Interview Blog
http://spaces.msn.com/members/dotnetinterviews/

 

[Fred Exley]

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.

A timeless classic still in book stores today:

http://www.amazon.com/exec/obidos/t...bs_b_2_1/103-2274678-1107869?v=glance&s=books

(and scroll down to the spotlight reviews of the book)

-Fred

 

[JT]

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.]

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?

 

[Raymond D'Anjou]

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.

 

[Jordan R.]

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.

 

[JT]

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/product.asp?isbn=0130146595&redir=1

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?

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.

 

[Jon Paal]

There is a basic concept that needs to be understood at the outset of every project.

Each project has three types of tasks:

1] the known knowns
2] the known unknowns
3] the unknown unknowns.

budgeting and scheduling can only account for the first 2.

 

[Rick Lones]

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?

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-

 

[JT]

Jordan R. was the OP, but any of us who have been in IT for more than 10
years have a story to tell.

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?

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.]

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 week 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.

 

[Jason Kester]

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?).

Ah, there's your false assumption. There are no "smart" programmers
out there. I've been in the industry for 11 years, and have come
across exactly three developers that I would ever want on a team.

Seriously, have you ever tried to hire in this industry? Even back in
2001, when EVERYBODY was out of work, it was still impossible to find a
developer who could find his arse with both hands. At best, maybe one
in three "senior level" programmers is capable of building production
code that works at all.

If you disagree, try reading the five most recent posts to any one of
these newsgroups. Ask yourself if you would hire the guy who asked the
question.

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

 

[Rick Lones]

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 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.

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 week 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.

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 to
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-educated
guy - and completely appropriate for use on large engineering projects by other
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 to
use them well. And if you are using them less than well then IMO you just might
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 in
many organizations OTHER than the one I was in.

Everybody always seems to overestimate other people's competence. It's still
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 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.

Hmm, I *think* I see what you are getting at here - the proposed remedies seldom
rise above being just more magic bullets. "Do A, do B, do C, then your problems
will be over and your organization will have (somehow) become competent." It
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 to
make a living. Now if what you are pointing out is, "beware, the whole system
is badly broken", then I might even agree - but IT system development is hardly
the most pressing example of that.

Regards,
-rick-

 

[Joe Delphi]

Other?).

Ah, there's your false assumption. There are no "smart" programmers
out there.

The reason IT projects fail is because people think like you do. They think
that all you need is a bunch of "smart" programmers. You also need
leadership, process discipline, and good management. Most of the IT project
failures that I know of had more than enough smart programmers, just none of
the other items required for success.

JD

 

[Jordan R.]

Re:
<< The reason IT projects fail is because people think like you do>>

Ah, I see both of your points and agree with both. Yours and Jason's are in
no way mutually exclusive so I won't try to take sides. I agree with Jason
completely - I've been playing the game for about 11 years as well, moved
around a bit as a consultant and worked with a bunch of large teams (within
and between organizations). Every successful (working) production system I
have ever seen had only one or two developers (rarely even a 3rd) who truly
comprehended the system. Please note that I'm in no way being pessimistic.
I'm reporting on my observations - so is Jason, apparently. But let's not
wander off topic too far... incompetent developers are only *part* of the
reason for all these failures.

It would be interesting as everything for me to see some stats on the
management of [systems that fail] vs [systems that succeed]. I'm sure one
could come up with some objective analysis of the extent to which each of
the relevant factors contribute to the failure or success of a project
(greed, incompetent programmers, poor communication, scope creep, etc). To
tease out [greed] I'm sure one could look at factors like "penalty for
failure" and "rewards for success". Chances are their are no real penalites
for failure on many of the 35% that fail. The rewards for failure -
accompanied with absence of penalty for failure - are obvious in many
cases... at a minimum, "we all get job security while we keep on keeping on
beyond our deadlines and budgets". Again, I'm just trying to find rational
explanations for the 35% that Ballmer was referring to and well documented
elsewhere.

I believe that those "in the trenches" have a unique perspective on this
topic that is easily missed by the academic types who study the issue.

Thanks again for your input here.

 

[Jordan R.]

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.