written by: Ada Stoy
• edited by: Ginny Edwards
• updated: 10/15/2010
IT projects are notorious for their high failure rates. Does this mean that IT projects are more risky, less predictable, more difficult to manage, or that IT project managers are less capable than their counterparts from other areas?
slide 1 of 3
Maybe the answer to the question why such a high percentage of IT projects fail lies in their specifics. IT projects are different from other projects and their risks are very specific, as we'll see next.
It is not a secret that even the simplest IT project can get very complicated due to external factors but this is hardly a comfort. A typical IT project has many inter-dependent components and modifications and delays in one component can easily affect everything else.
In many tech areas it is the same, so no matter how good a project manager is, there are factors nobody can predict or expect. Still, when one is experienced and is aware of the common IT project risks, it is easy to spot early the project risk symptoms and react adequately before everything collapses. The list of common IT project risks and risk symptoms is pretty long and the next section is by no means a complete source of what can go wrong in an IT project but it is a good point to start from.
slide 3 of 3
Common IT Project Risk Examples
Every IT project is different but the risk scenarios are strikingly similar. Here are some very common IT project risk examples:
1. Mid-project change in scope. Changes in scope are frequent in IT projects and to some extent they are quite logical – no matter how detailed your specification is, there are always suggestions that come after you have started the implementation. The problem starts, when these suggestions demand radical changes. This is especially unpleasant when you are in the middle of the project and actually the choices you have are either to reject the changes, or to trash most of what you have done up to here and go back to implement the new requests. Such change requests can turn any schedule upside down.
2. Going behind schedule due to unforeseen complications. Even if there are no mid-project changes in scope, unforeseen technical complications can also turn the project upside down. You might know the technologies you are using in the project very well but still surprises are possible – this component has always been working fine but now when you integrate it with another component, the mess is complete. Unfortunately, very often you can't do much to avoid this common IT project risk but pray that it doesn't happen to you.
3. Technical inability for a given feature to be implemented. Technical complications lead not only to delays but they can also affect the scope. If a given functionality can't be implemented because it is technically impossible, the easiest solution is to skip this functionality but when other components depend on it, this isn't wise to do. Generally, the more experienced your technical people are, the lower the risk of unforeseen technical limitations is but still this risk is always present.
4. No problems are reported. When everything is blissfully calm and no problems are reported, this should really worry you. If everything looks too good this spells trouble. The fact that no problems are reported could mean that there are no problems to report, which is extremely rare, or that problems exist but they are not reported because nobody dares to. Everybody knows the “shoot the messenger” approach and sometimes even brave guys and gals are cautious to be the messenger, who will report a severe problem.
5. A key employee leaves. One of the things that can really shatter a project is when a key employee quits. Employees quit due to a variety of reasons and generally they have a notice. When you are warned that a key employee is leaving soon, you need to rearrange the team but if there is no suitable person to take over the tasks of the person, who is leaving, this can cause serious disruptions.
These common IT project risk examples happen frequently. In some cases you an prevent them if you spot them early and this can save the project from failure.