Three risk categories that explain IT failure

Three risk categories that explain IT failure

Summary: A new white paper from Alpha Software describes three broad categories of risk that explain why software projects fail:Process failures arise when a project is "bumped off track," relative to the expected plan.If the goal of a process is to produce a specific outcome, then anything that either delays or prevents the achievement of that specific outcome is a form of process failure.


A new white paper from Alpha Software describes three broad categories of risk that explain why software projects fail:

Process failures arise when a project is "bumped off track," relative to the expected plan.

If the goal of a process is to produce a specific outcome, then anything that either delays or prevents the achievement of that specific outcome is a form of process failure. Consider an obvious example of process failure, requirements that are never really (or accurately) determined.

This form of failure usually leads to finger pointing between development groups and users, with each claiming the other did not understand.

[Other examples of process failure involve:]

  • Communications (including communications latency)
  • Implementing out of date requirements
  • Feature creep (or additional features) and its cousin, poorly defined scope
  • Bugs (defects)
  • Waiting for someone or something
  • Partial work
  • Context switching
  • Unnecessary processes
  • Paper shuffling
  • Unrealistic schedule
  • Unrealistic budget
  • Careless, sloppy, or missing software development processes

[T]he presence of one or more of these process failures contribute to business failure if the organization is not able to respond to changing business or market conditions. They also make it difficult to respond to customer-perceived incidents that disrupt service delivery.

Platform failures reflect specific problems with the technology used to develop or deliver software solutions.

The generic term platform applies both to hardware and software individually, and in combination. Some platform failures are also obvious, such as hard disk crashes or network component failure with a corresponding interruption of network traffic. Other examples of platform failure are less obvious, such as when the application does not scale or meet expected levels of performance.Of all the different types of failures, some hardware failures are both the easiest to spot and probably the easiest to anticipate, typically by having spare parts either on-hand or available for just-in-time delivery.

Failures in software platforms (software tools) are more problematic, though they occur frequently enough that they have a name: bugs. It is usually impossible to substitute one software tool for another without a great deal of effort. This becomes particularly onerous if the bug is in a critical tool, and the vendor (or in-house developer) cannot quickly provide either a fix or work-around.

There are also platform failures that can be less obvious to spot, specifically getting close to boundary conditions of the hardware or software including network capacity, balance between physical RAM and swap file, getting close to hard disk space limits, etc.

Business failures refer to issues and problems driven by the internal organization itself.

One of the most obvious forms of business failure also turns out to be the primary reason that development organizations cannot readily adapt to changing conditions: specifically, lack of management commitment. No project can succeed without management commitment (and on occasion, management drive).

[E]xperience [also] suggests an expansion of the concept of business failure to include the notion of tool vendor concerns for the customer value chain. The customer of my customer should be treated like they are my customer. Does the tool vendor do that?


The white paper places the risk sources underlying IT failure into three reasonable categories. Nonetheless, for simplicity's sake, I recommend readers combine business and process failures into a single category encompassing both. Importantly, the paper does a good job making the distinction between business and technical causes of failure, and it provides examples of each.

Although the white paper covers no new ground in categorizing project risk, it includes a useful chart showing "the relationship between complexity, calendar duration, and risk:"

Three risk categories that explain IT failure

Take a project task, such as developing a particular feature, and map it onto the chart. The grid provides a quick litmus test for evaluating estimates against a consistent framework of risk, complexity, and time. It's a simple, nice, and useful method to perform intuitive risk testing.

Overall, the white paper is worth a read. It won't send off skyrockets in your mind but it's solid, covers good territory, and provides lots of concrete examples.

Topics: Software, CXO, IT Employment

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


Log in or register to join the discussion
  • Wow...

    I'll bet they spent millions studying this problem to conclude that the biggest risk categories for IT projects are all the things that go into IT projects. Simply amazing. These people must all have MBAs.
  • Why do some folks thing IT is somehow different?

    I am constantly amazed that anyone spends time writing something like this. Talk about wasting time to re-invent the wheel. Engineering managers have known this for centuries and built effective tools to deal with it. (Real project management.) Why so many think IT is in some way differnt and doesn't follow the same path is more than I can fathom. Great project management is great project management, the type of project doesn't matter at all. It's why engineering students devote so much time to studying project management.
    • Give me a break

      So, you've learned a particular lesson, and that means it shouldn't be shared with anyone else? Sorry the rest of us don't measure up to your standards.

      Thanks for your opinion, but I suggest you re-examine it.
      • You missed the point completely. (or didn't like hearing it)

        No one said not to share anything, what I did say is that when it comes to computing in general (IT) there seems to be some mind set that it is in someway different than other types of project management or that there is a need to reinvent the wheel when it comes to project management.

        Be honest, how many IT managers have spent time in a formal setting (school, classes, etc.) to learn to be great project managers? From what I have seen, it is very, very few and far between. For reasons I don't quite understand, IT folks refuse to accept that great project management is a skill set all of its own, regardless of what type of project it is. What I DO see in day to day is that "Joe" is a good coder so obviously he's the one to tap on the shoulder to run a new coding project. Sorry but that simply is not true.

        Sort of like, a great surgeon isn't really the best guy to be the hospital administrator. They are totally differnt skill sets.

        Its almost as if people in IT think there is something wrong in admitting they don't have the training or skills to run large or complex projects. Ego? I don't know...
        • Problem is deeper than project management alone

          Project management offers a valuable way to track, line up, and count ducks in rows. IT failures usually have deeper roots, often going right to the level of fundamental business case, senior management support. These are organizational issues, not project management ones.

          It's not an issue of IT alone, by the way. Look at construction,for example. How many large construction project come in on-time and within budget? Not many.
          • Actually, that is part of GOOD project management.

            "IT failures usually have deeper roots, often going right to the level of fundamental business case, senior management support."

            Yes, and GOOD project management takes this into account on the front end. Emphasis on "good".

            "How many large construction project come in on-time and within budget?"

            Actually the vast majority do, unless its a government contract and is based on cost plus, then all bets are off. <g>

            I say it again, having come from an engineering background and then managing IT projects I can tell you good project management is good project management and is something the vast majority of IT folks simply have no skill set in. The funny part (well not so funny) is that when you tell them that they feel slighted in someway and react negatively, just as you have done.

            There simply is no reason for it, its not a negative to admit that you have spent your time being a great coder or sys admin and have not developed the skill set required for good project management. You can't wear every hat...
          • No ax is totally right

            And in my opinion the reason why public works rarely make it in time and budget is because politicians think they know how to choose a good project manager...
    • Because IT projects are different to other projects

      The fundamental components of project management are similar regardless of the discipline, however I have seen attempts at putting very successful engineering project managers in charge of software projects and they have been dismal failures.

      There are people who believe that project management is fundamentally a scheduling exercise, or risk management, or communication, or expectation management. Some think it's all of the above.

      Your line of argument is to define people out of the argument by saying if person X can't manage project Y, then it isn't because the project is different but because the person isn't a "real" project manager. In formal debating that tactic will cost you the debate as it shows you aren't prepared to argue points on their merits.
      Fred Fredrickson
  • RE: Three risk categories that explain IT failure

    This Paper is really on target.

    given two choices

    A) Focusing on trying to build the perfect system that ultimately never gets built - because of feature creep and complexity


    B) Focusing on building the core features (but not everything and not perfect on the first iteration) into a system and getting it live and operational ASAP

    I would choose B everytime

    curious about other opinions
    • Better choice.

      Plan your work then work your plan. ;-)

      Feature creep is something that a good project manager controls very tightly and when it is allowed, he/she makes everyone aware of the ramifications.

      When I work with factory automation (outside consultant) ANYTHING that gets added must be done with an engineering change notice and we attach a $500 "penalty" just to submit it. That tends to weed out the silly requests and pays for all the work needed to change the projects time line, lead times, reallocation of man power, etc.

      If the client moves ahead with it we issue a new project scope and time line to them so they are aware of what their addition is going to cost in terms of delivery.

      You might be amazed at how this "penalty" makes people rethink adding everything but the kithen sink...
      • No, just one choice

        Your example of using change control to control the project shows you are in the "everything is a scheduling exercise" camp. Your first struggle is to prove to the client that what you think is a change really is a change. Until then, they think you have a defect.

        So what is your issue escalation proceedure? Oh, sorry, that's in the "everything is a risk management exercise" camp.
        Fred Fredrickson
  • People in glass houses ...

    Michael, thank you so much for blogging about our white paper.

    I've posted my comment on our blog, here:
  • RE: Three risk categories that explain IT failure

    Interesting responses to this post. In regard to your comment, "Nonetheless, for simplicity???s sake, I recommend readers combine business and process failures into a single category encompassing both.", I would go a step further. Don't do it for the sake of simplicity, do it for the sake of accuracy. Separating management commitment from the process is indicative of why that failure takes place. I would not dream of undertaking an IT effort without the appropriate management commitment. I could even make an argument as to why platform failures could also be included under the process umbrella, taking the position that all failures are process related. We'll leave that for another day.
    Steve Romero