OT: IT Project Failure Rates

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.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.
Jordan R. wrote:
> 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 t
he
> 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.
>|||On Mon, 14 Nov 2005 20:47:25 -0800, "Jordan R."
<JordanRemoveThis3481@.ComCast.net> wrote:
in <Oyk9q#Z6FHA.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 th
e
>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 st
ars
but they probably won't win the World Series or otherwise be successful with
out
a great team effort. Every successful project requires a team effort. In t
he
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 tha
t he
and Microsoft have all the answers to help you bring your projects to a
successful conclusion.
Stefan Berglund|||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/|||Jordan R. wrote:
> 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/
Get your own Travel Blog, with itinerary maps and photos!
http://www.blogabond.com/|||"Jason Kester" <jasonkester@.gmail.com> wrote in message
news:1132109997.310334.198890@.g44g2000cwa.googlegroups.com...
> Jordan R. wrote:
rates
come
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|||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.|||Joe Delphi wrote:
> The reason IT projects fail is because people think like you do. They thi
nk
> that all you need is a bunch of "smart" programmers.
That's not actually what I think. Nor is it what I said. I was simply
stating the obvious, that it's impossible to deliver functioning
software with a team that cannot code its way out of a sack. And it's
my observation over the years that most developers are simply not up to
the task of writing commercial software.
But that's only one reason why so few projects make it. You also need
upper management that truly understands software, and people that want
to pay good money for your product. Take away any of those three key
pieces and you're basically hosed.
Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/
Get your own Travel Blog, with itinerary maps and photos!
http://www.blogabond.com/|||"Jordan R." <JordanRemoveThis3481@.ComCast.net> wrote in message
news:OFIOLwm6FHA.2384@.TK2MSFTNGP12.phx.gbl...
> 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.
>
Academic type study of IT projects: The Mythical Man-Month
"in the trenches" study of IT projects (old old joke -probably predates the
above book):
Stages of an IT project:
1. Euphoria
2. Disenchantment
3. Chaos
4. Search for the guilty.
5. Promotion of the uninvolved.
-Fred|||"Jason Kester" <jasonkester@.gmail.com> wrote in message
news:1132109997.310334.198890@.g44g2000cwa.googlegroups.com...
> Jordan R. wrote:
...
> 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.
There's your problem Jason.
Don't hire the people that ask the questions, hire the ones that answer.
On the other hand, I've found that the worst developers are the ones that
DON'T ask questions.
Either they think they know everything or they think that by asking
questions they'll come off as knowing nothing.