IT projects carry with them many risks. Because technology constantly evolves, companies must keep up in order to remain competitive, so the risks are often necessary to face. When initiating, planning, executing, and monitoring IT projects, two questions must be considered: first, how and why do IT projects fail? Second, what can your company do to prevent this failure?

If you are looking for more resources to help with risk management, or project management in general, consider RefineM’s toolkit, Essential Gear for Project Managers.

Examples of high-profile failed IT projects are easily found. Bent Flyvbjerg and Alexander Budzier, writing in the Harvard Business Review, cite several examples, such as a $5 million SAP project Levi-Strauss undertook that led to a quarterly loss of nearly $200 million[1] and Kmart’s failed IT modernization projects that added to the company’s debt burden[2]. Alton Chua, who examined high-profile failed IT projects from the 1970s to the 1990s, includes many more examples, such as the failed Denver airport baggage handling system that delayed the airport’s opening.[3] Based on his investigations, Chua determined four categories of risk that threaten projects[4]:

1. People-related risk factors.

People-related risk factors are not just limited to the project team; they can also include any internal or external stakeholder involved with the project. Inexperienced clients or vendors, lack of stakeholder involvement, overly ambitious top management, and user unfamiliarity with the final product are all examples of people-related risk factors.

2. Process-related risk factors.

Process-related risk factors arise from difficulties in conceiving and implementing project management processes. Examples include unclear scope and requirements, unrealistic schedule, poor cost control, and poor change control. Process improvement projects can help your organization build a strong project management foundation to offset these risk factors; in addition, many of these can be performed in an Agile environment. [View our Agile for Process Improvement Projects presentation on our Presentations and Slides page.

3. Technical risk factors.

Technical risk factors include high levels of technical complexity, an inappropriate approach to project development, and incomplete software testing. Failing to complete automation testing for example can be highly risky when launching new software. It is important here to say that undertaking a project involving new technology is not always a negative risk; in fact, it can help your organization grow, as long as you have the capability to complete the project. Inappropriate approaches to project development might include attempting an Agile approach on a project or in a company that is not suited to it. [Refer to our blog post, Is Agile a Silver Bullet? for more about where Agile is a good fit.] Finally, companies should review their testing processes to ensure that the final product meets users’ needs.

4. Extra-project risk factors.

Chua defines the category of “extra-project” risk factors to include external risk factors that greatly impacted the projects he studied. Among these, he includes external environmental changes and tight coupling with other high-stakes projects as examples. Because these are outside of direct project control, they are more difficult to guard against, but still should be taken into account.

Chua’s recommendations for addressing these categories of risk include[5]:

1. Securing the support of top management and keeping stakeholders involved throughout the project life cycle.
2. Developing strong project management practices, especially in the areas of scope, time, cost, and risk management.
3. Acquiring or developing strong technical expertise.
4. Constantly appraising technical complexity of the project at each phase.

Gaining and keeping the support of top management, as well as other relevant stakeholders, is an important ongoing project task that leverages the project manager’s negotiation skills. It is no coincidence that PMI has recognized the importance of stakeholder management by elevating it to its own knowledge area in the Fifth Edition of the Guide to the Project Management Body of Knowledge (PMBOK^® Guide). [Visit our Presentations and Slides page to learn more about other changes in the Fifth edition.]

Strong project management includes techniques and processes for managing the triple constraint, but risk management is especially important. Risk management for IT projects may be more difficult to perform due to the ever-changing technological environment, but it is still worth performing. PMI’s risk management processes are a good starting point for any organization, but it is likely that your organization will have unique needs and so you will want to augment their processes with what works best for you.

IT projects can get out of hand quickly, as shifting technical environments and external factors can lead to cost overruns and scope creep. Having knowledgeable personnel can greatly aid a project’s chances of success. In addition, reassessing the project’s technical complexity at each phase is an effective means of making sure that the project is under control.

Flyvbjerg and Budzier recommend in their article that organizations conduct stress tests when taking on IT projects, and that the tests encompass more than just the scenario of total project failure[6]. For example, can your company absorb the consequences of several medium-sized projects incurring cost overruns? Can it survive if its highest-priority project falls short of delivering planned benefits? These questions and more are important to examine before going forward with the project. You can outsource these tests to software testing and quality assurance companies such as iBeta and others, ensuring IT projects are suitable for desired processes.

One way to address these questions is by tracking Expected Monetary Value (EMV) throughout the life of the project. EMV is the product of the probability of a risk event occurring and its monetary impact. For example, if the probability of a risk event occurring is 50 percent and its occurrence will result in a cost of $50,000, the EMV for this event is half of $50,000, or $25,000.

The main advantage of EMV is being able to create a contingency reserve to account for possible risk events and cost overruns. Following from the previous example, your company might decide to set aside $100,000 as a contingency reserve against four high-probability risk events, each of which has an EMV of $25,000, occurring. Tracking EMV requires a constant reappraisal of risks and updates to the risk management plan; it is not enough for your company to create a risk management plan at the beginning of the project and then fail to reassess it. In constantly examining risk management at each phase, your company will have achieved another advantage that should help against project risks. [Visit our Virtual Lunch and Learn Presentations page to learn more about a model to develop and use risk contingency reserve.]

With any project, especially one involving new technology or a high level of complexity, risk will be highest at the beginning due to the level of uncertainty. As time goes on, the level of risk subsides due to unknowns becoming known; however, any new risks that surface in the project’s middle or end phases will be more difficult to account for due to less flexibility. For this reason, it is important to constantly reappraise risks.

Because IT projects can provide tangible benefits to any organization, they should not be ignored. However, the risks they carry also should not be ignored. While risk will be present in some form in any project, a smart and thorough approach to project management should help your organization mitigate these risks and execute successful IT projects.