ie8 fix
madison

The IT failure curve of death

By | June 23, 2010, 10:35am PDT

Summary: The importance of proper planning in preventing failed IT projects cannot be overstated. Steps taken early in the project can have a profound impact on downstream success or failure.

The importance of proper planning in preventing failed IT projects cannot be overstated. Steps taken early in the project can have a profound impact on downstream success or failure.

Unfortunately, most folks running projects are too busy during the startup phases to address potential vulnerabilities that can cause dramatic harm later.

Think I’m wrong? Then please explain why so many projects are late, budget, or don’t meet planned goals.

An SAP website describing Safeguarding, the company’s sales-oriented review service, includes a diagram that portrays the impact of early-stage planning on downstream success:

Although the diagram shows SAP’s particular methodology, it’s applicable to projects from every software vendor.

Related: 7 tips to safely kill zombie projects

My take. There’s rarely enough time or money to do things right, but the budget for fixing problems often seems endless. For most organizations, solving this problem requires broad rethinking of priorities early in the life of a project.

Project improvement requires a “lifestyle shift” for most organizations. To begin the process, start by defining the problem and then enlist senior management support. Results won’t happen overnight, but over time your projects will run more smoothly, waste less money, and let your entire team rest more easily.

[Diagram (c) 2010 SAP AG. All rights reserved. Photo of the Grim Reaper, who watches over death spiral projects... waiting for his opportunity, from iStockphoto.]

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

Topics

Michael Krigsman is a recognized authority on the causes and prevention of IT failures.

Disclosure

Michael Krigsman

Michael Krigsman writes and speaks about technology in a manner that most observers consider to be fair and balanced. Michael believes that writing about IT failures, which often have complex causes, creates a unique obligation to be reasonable and accurate in both reporting and analysis.

Michael maintains active personal and professional relationships with enterprise technology buyers, vendors, analyst firms (or individual analysts), consultants, and system integrators. As CEO of Asuret, Michael sells and delivers paid services to members of these same groups.

Vendors regularly reimburse Michael's out-of-pocket travel expenses to attend industry conferences and events. Conference organizers frequently waive entry fees when Michael attends industry events. Michael often speaks at industry conferences and events.

He is a member of the Enterprise Irregulars, a loose association of consultants, investors, industry representatives, analysts, and users of enterprise software.

For daily updates on Michael's activities, follow him on Twitter.

Biography

Michael Krigsman

Michael Krigsman is CEO of Asuret, Inc., a consulting company dedicated to reducing technology implementation failures. Asuret's suite of software tools improve the success rate of enterprise software deployments by quantifying and measuring governance issues that cause most project failures. Michael led the research effort underlying Asuret's model of collective intelligence and its practical application to reducing IT failures in consulting environments. He is a recognized authority on the causes and prevention of IT failures and is frequently quoted in the press on IT project and related CIO issues. He is considered an enterprise software industry "influencer" and provides advice to technology buyers, vendors, and services firms.

Previously, Michael served as CEO of Cambridge Publications, which develops tools and processes for software implementations and related business practice automation projects. Michael has been involved with hundreds of software development projects, for companies ranging from small startups to Fortune 500 organizations. Michael graduated with an M.B.A. from Boston University and a B.A. from Bard College. He is a Board member of the America's Cup Hall of Fame and the Herreshoff Marine Museum in Bristol, RI.

12
Comments

Join the conversation!

Just In

RE: The IT failure curve of death
ksamaddar@... 9th Nov 2010
@guihombre
You are a programmer and hence you look at things from your narrow angle. An IT Project is much bigger than your stew... in your own analogy, it's a big restaurant, where one bad stew can spoil a bit but your other dinner menus, services, ambiance, music has much more scope to compensate for that. When a restaurant fails?... when many of these fails together or the owner decides to close the shop... not an incompetent cook!!
0 Votes
+ -
IT Staffing Mix Makes a Difference
jshepley 23rd Jun 2010
Michael,

Great post! I love the SAP diagram...it says it all.

I've found that often the staffing mix in play has an impact on how well an IT organization plans its projects. In shops that are developer-heavy (i.e., with less BA, PM, QA, EA, and/or SA resources), you typically find sub-optimal planning. Developers tend to like to "get to it" and build stuff rather than engage in what can feel like endless cycles of "planning the plan". And if the department doesn't have a strong body of these other roles, chances are no one has ever seen just how powerfully effective and efficient the proper planning can be for a development project.

Not sure if you allow it here (don't want to be a spammer), but I've got a recent post on this very topic: http://bit.ly/9lIuXv if folks are interested.

Anyway, thanks again for the great post!

Cheers,

Joe
http://flavors.me/jshepley
0 Votes
+ -
Yes. But careful.
Peter Kretzman 23rd Jun 2010
I'm all for careful up-front project planning, and agree that there are often huge impacts down the line if this is foregone or shortcut.

But the SAP quote pressed a button for me. "One degree off, and you'll miss by 18 miles"?? This is hardly the way that I'd formulate the goal of planning. It evokes an ultra-waterfall notion of "figure everything out in advance." If there's anything we all have learned in IT, it's the vital importance of reacting quickly to the unexpected and adjusting one's careful plans in midstream. I'm hardly an Agile zealot (there can be miscues in that approach too), but Agile has it right. Rather than arrogantly believing that you can figure out everything ahead of time, organize and operate your project to be appropriately nimble when things don't go exactly as planned.

I'm fond of quoting Eisenhowever, in fact: "Plans are useless, but planning is indispensable."
0 Votes
+ -
From my perspective
guihombre 23rd Jun 2010
I am a programmer, I work on very successful projects (>$1 billion in revenue from my work), I work for very large companies, I also have huge failures.

Do you know what the different is between a success and failure?

Usually it's one or two odious incompetent employee. Nothing more nothing less.

Especially with software, one weak employee in a team is all it takes to break a product.

Look at it this way, you make a stew, it's the finest stew with the tenderest beef, cooked to perfection, round perfect dumplings, a rich rich sauce, and a dollop of ****.
You made a **** stew! It makes no difference the quality of the beef, the roundness of the dumplings, it's a **** stew and nobody will eat it.
One ingredient from one incompetent chef and the whole thing is worthless.

And that is why most projects fail. A failure of management to identify and remove the incompetent contributors to the project.
0 Votes
+ -
Vanity etc...
zkiwi 23rd Jun 2010
One day you will find you are the steaming pile of whatever on a project. Everyone has their happy moments, everyone has their moments they would rather didn't happen. Note that most of the amazing things done in life have been done by people who on the surface look like "odious, incompetent employees."

Also note, it is often arrogant jerks (perhaps you are one, I don't know) that generate bad performance in others.
0 Votes
+ -
RE: The IT failure curve of death
royalef 25th Jun 2010
I agree. When something is bad, it is MANAGEMENT that must identify and fix it. It isn't the bad employee, they are the result of poor management. I've seen disasters, which were obvious at the out-start because mgmnt just wouldn't accept the realities and do their job Instead everyone plays "fairy tale" and ignores the naked emperor. I've seen management actually trashing the business, regardless of what the good employees say. I've seen it in large corporations (you would recognize their names) and in mom and pop shops. It is human behavior and has nothing to do with IT or technology. The best references to this sort of thing is emotional intelligence. Emotions are irrational and that behavior is irrational--that's the cue that it is linked to emotional issues within individuals.
0 Votes
+ -
RE: The IT failure curve of death
ksamaddar@... 9th Nov 2010
@guihombre
You are a programmer and hence you look at things from your narrow angle. An IT Project is much bigger than your stew... in your own analogy, it's a big restaurant, where one bad stew can spoil a bit but your other dinner menus, services, ambiance, music has much more scope to compensate for that. When a restaurant fails?... when many of these fails together or the owner decides to close the shop... not an incompetent cook!!
0 Votes
+ -
Michael, Good post, good diagram.
I do have one comment on your take, "Theres rarely enough time or money to do things right, but the budget for fixing problems often seems endless."

Unfortunately, other than the problems that keep us from working entirely, there are many problems that we never get around to fixing, either because we don't have the budget, or the time (or because fixing problems can't be capitalized whereas new project work can be).

These ongoing quality issues degrade the value of our systems and make it harder for work to be performed. Folks get used to applying a work-around, or ignoring data and functionality that they've found to be suspect.

These may seem like small matters taken one at a time, but they accumulate over time.

Bill Monroe
Project Portfolio Excellence
Stop wasting time, money, and energy on projects that have no chance for success!
0 Votes
+ -
A diagram will save us;-)
Richard Flude 23rd Jun 2010
"Think I?m wrong? Then please explain why so many projects are late, budget, or don?t meet planned goals."

Because developing software to match user's expectations is extremely difficult!

Sorry SAP, if you believe you can go through the stages of the project lifecycle with the original blueprint developed at the beginning you're guaranteed to fail, no matter how much preparation you do.

Break the project into tasks, put times against them. Continuously re-evaluate progress and the tasks themselves. Be flexible, hire good people.
0 Votes
+ -
RE: The IT failure curve of death
rdebened 23rd Jun 2010
This is has lots of truth, however, most fundamental cause for lack of project planning is lack of true Project Managers. To often great developers, analysts or managers don't have the PM knowledge. As far as SAP, they love to do 1,000 mile (read 15 months) to do a project so of course they are way off. The big bang is gone, Quick Wins is the way to go, and that is why you have the new mantra of Agile Project Mgmt.
0 Votes
+ -
RE: The IT failure curve of death
afeke 24th Jun 2010
@rdebened I completely agree that using the PMBOK framework can keep projects on schedule and on budget. More IT staff certified as PMPs will definitely help. There are best practices out there, but people need to know where to look.
There are multiple factors that govern the success / failure of a project. For e.g., What is the success criteria, is it defined and do your people buy-into it? Are roles and responsibilities clearly defined and do your people understand them? Do you have a strong governance in place defined comprehensively in term of effective communication, clear escalation paths, various stake-holder involvement etc?

I many times wonder whether Project Management is a science or art or both?
0 Votes
+ -
RE: The IT failure curve of death
spdblp 25th Jun 2010
Sometimes, it is the project managers fault. I have seen too many PM's gloss over the details they don't understand, every such task is expected to be completed in one day, until they determine otherwise. One time that I got sucked in at the last moment, the project required mail software designed to work with MS Exchange to work the same way with Lotus Notes. There was a kludgy workaround, which was only supported on a 'best effort' basis by Microsoft and IBM. It took an extra month to get to that point.

Also, some people only use terminology they are used to. What does 'the SQL database' mean? In a shop that used DB2, UDB, Oracle, and SQL Server, how should anybody looking at the project plan figure out which DBA to call? Or how does a DBA realize that something is his/her job?

And then there is the habit of describing everything in PM or ITIL lingo that the rest of the population, including the people doing the actual work, does not understand.

This is not aimed at all project managers, but I have seen far to many projects featuring one or more of the above.

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix
Click Here
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

White Papers, Webcasts, & Resources
ie8 fix
ie8 fix