OT: IT Project Failure Rates

[Jason Kester]

The reason IT projects fail is because people think like you do. They think
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/

 

[Fred Exley]

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 think most IT debacles trace back to politics at management levels far
removed from IT, rather than competence at the programming level.
Especially in your case -sure has the look and feel of personal empire
building being the driving force. We all have horror stories about IT
debacles, but really, has anybody here seen a disaster hatched where the
organization had competent senor management, clearly defined objectives for
the system, the necessary resources to accomplish the goal are provided, yet
the system failed because the analysts wrote the wrong specs, or the
programmers couldn't figure out how to code it?
-Fred

 

[Fred Exley]

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

 

[JT]

OK, so you were the architect of a system, currently in use by Big Name
Client, which replaced a poorly implemented 8 million dollar system built by
Big Name Consulting Firm? Sounds like a great resume enhancer, and you can
say it with all honesty. Not a bad position to be in. If life hands you a
sack of lemons, then turn them into sweet lemonade. ;-)

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.

 

[Raymond D'Anjou]

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.

 

[jxstern]

Ah, I see both of your points and agree with both.

I've been in at least two organization where it was the general
manager's semi-secret agenda for the project to fail.

It's not uncommon for middle-managers to manage by fire-fighting, and
the first prerequisite for them is to have something on fire to fight.

So, lots of projects fail because management prefers it that way.

Lots of others fail because the budget is impossible, the requirements
never having been done, or a dishonest lowest bidder having been
chosen.

I also agree with the previous posts about the rarity of people who
can deliver industrial-strength code, and the idea that ALL one needs
is good coders.

Peace, out.

J.

 

[Guest]

I've been an application developer for 25 years and a PM for 15 years. I have
spent most of my career as a consultant and contractor. I think that
qualifies me as either being in the trenches, or at least having spent enough
time there to have a reasonable perspective. The point is I've worked within
a LOT of companies, over a pretty fair period of time, and I keep seeing the
same pattern.

There is an extremely long answer to this question, because there are many
factors that can derail a project. The systemic issues don't apply to all
companies or all projects, but I think it's a major contributor to that 35%
(I've heard larger numbers quoted).

The biggest single factor, in my experience, is that everything in business
is based on trying to predict the future, and then trying to live up to that
prediction. There are few real winners.

Budgets and timeline expectations are very often set way long before a
project kicks off, when companies try to figure out future budgets, sometimes
a year or more in advance. They come up with very high level estimates,
without fully understanding the situation or the solution. There is
considerable pressure to come up with lean budgets, so the numbers are often
overly optimistic, based on not enough information.

As silly as this sounds, these numbers become an expectation, upon which
success or failure is perceived at some level.

As life happens over the period of time covered by that budget, the problem
becomes compounded. One project is late so it delays the next, resources
become stretched, individual budgets get squeezed, priorities change,
unexpected expenses pop up, until the last projects to kickoff in that budget
period are pretty much setup for failure.

I could go on and on about systemic problems, so let's get on to how to run
a project.

By far and away my most successful projects are really two projects,
although you can call them phases.

Phase one receives part (say 25%) of a reasonable budget and time to fully
understand the requirements and design the best solution. The right people
are involved and dedicated to the effort. Only then can you have a reasonable
chance at planning the rest of the project and coming up with a budget and
timeline you can live with plus or minus 10%. The people who will be doing
the work, and those who will benefit from the results, must buy-in to the
solution and be fully involved in determining the tasks and estimates.

If the rest of the project is approved, you have everything you need to hit
the ground running. The team is dedicated to the effort, understands and owns
the work. No excuses, since they came up with the solution, tasks and
estimates. They must be fully dedicated with no other demands on their time.

A good PM is very busy clearing the way for the team to do the work. It's a
full-time job managing the schedule looking for efficiencies, tracking
progress to be sure there are no surprises down the road, proactively looking
for and mitigating risks before they become issues, quickly dealing with
issues before they affect the team, and setting expectations of anyone who
can negatively influence the work or progress.

That's the way you run a project if you don't want to fail. Any deviation,
such as shared resources, lack of planning, tinkering with the scope,
inadequate understanding of the requirements, insufficient by-in from
stakeholders (including the team), an inexperienced PM, a PM with no
authority, etc. can easily cause a project's downfall.

Mark