Risk identification deals with identifying and creating a list of threats and opportunities that may impact the project's goal and/or objectives. Each risk and its characteristics are documented to provide a basis for the overall risk management plan.
Identifying and understanding the risks that will impact a project is not always a straightforward task. Many risks can affect a project in different ways and during different phases of the project life cycle. Therefore, the process and techniques used to identify risks must include a broad view of the project and attempt to understand a particular risk's cause and impact among the various project components. Figure 8.2 provides a framework for identifying and understanding the sources and impacts of IT project risks.
At the core of the IT project risk framework is the MOV, or measurable organizational value. The MOV is the goal of the project that defines the measurable value the organization expects from the project. It is both a measure and definition of project success.
The next layer of the framework includes the project objectives in terms of scope, quality, schedule, and budget. Although these objectives are not by themselves sufficient conditions for success, together they do play a critical role in supporting the MOV.
The third layer focuses on the sources of IT project risk. Risks can arise as a result of the various people or stakeholders associated with a project, legal considerations,
the processes (project and product), the environment, the technology, the organization, the product, and a catchall category called other.
The next layer focuses on whether the sources of risk are internal or external to the project. It is important to make this distinction because a project manager is responsible and accountable for all project risks internal to the project. For example, if a project team member is not adequately trained to use a particular technology, then the project's objectives—scope, schedule, budget, and quality—may be impacted. In turn, this lack of training may inhibit the project from achieving its goal or MOV. Once this project risk has been identified along with its impact, the project manager can avoid or mitigate the risk by sending this particular project team member to training or by assigning certain critical tasks to a more experienced or skillful team member. On the other hand, a project manager may not be responsible for external risks. For example, a project manager would not be responsible or accountable if the project was cancelled because the organization sponsoring the project went bankrupt.
The distinction between internal and external risks is not always clear. For example, even though a particular hardware or software vendor may be external to the project, the project manager may still be responsible if that vendor is unable to deliver required technology resources. If the project manager chose that particular vendor, he or she would then be responsible or accountable for that risk. In short, a project manager will (or should) have control over internal risks, but not external risks. That distinction does not mean the project manager can ignore external risks. These risks can have a significant impact on the project, as well as the project manager's employment!
The fifth layer of the IT project risk management framework includes three different types of risks: known risks, known-unknown risks, and unknown-unknown risks. Wideman (1992) defines known risks as events that are going to occur. In short, these events are like death and taxes—they will happen and there is no uncertainty about it. On the other hand, known-unknowns are identifiable uncertainty. For example, if you own a home or rent an apartment, you know that you will receive a bill next month for the utilities you use. The precise amount you will owe the utility company will be unknown until you receive the actual bill. Unknown-unknown risks are residual risks or events that we cannot even imagine happening. For example, it was not too long ago that people had never even heard about the Internet. How could they comprehend the impact it would have on many of us? Unknown-unknown risks are really just a way to remind us that there may be a few risks remaining even after we may think we identified them all. In general, these are the risks that we identify after they have occurred.
The outer layer provides a time element in terms of the project life cycle. It may help us determine or identify when risks may occur, but also remind us that they may change over the life of the project. Although risk management is an important concern at the beginning of a project, the IT project risk management framework reminds us that we must be vigilant for opportunities and problems throughout the project life cycle.
The GTS vignette at the beginning of the chapter can be analyzed using the process represented in Figure 8.1. For example, the risk faced by the GTS team could be defined as:
• A threat that occurred in the develop project charter and project plan phase.
• It was an unknown-unknown risk because it was identified after it occurred and, therefore, caught the GTS project team off guard.
• It was an external risk, and the project manager and project team should not be held responsible for the economic downturn experienced by Husky Air.
• The sources of risk to the GTS project include environment (economic), organizational (the client Husky Air) and people (if you would like to argue that Husky Air's management was lax in anticipating this problematic event).
• The impact on the GTS project was significant because it would affect the project's scope, schedule, and budget. Since Tim Williams was able to rene gotiate the contract based on a trimmed scope, we can assume that quality would not be an issue. But if Husky Air's management insisted on main taining the original scope, schedule, and budget, chances are good that quality would become an issue, especially if, for example, the scheduled testing time had to be shortened in order to meet the scheduled deadline.
• It is likely that the project's MOV would change as well because the project team would not complete the scope as originally planned. This, in turn, would determine the revised scope, schedule, and budget for the project.
This example shows how a risk can be understood after it occurs. The framework can also be used to proactively identify IT project risks. For example, a project team could begin with the project phases defined in the outer core of the framework. Using the project's work breakdown structure (WBS) and the individual work packages, the team could identify the risks for each of the work packages under the various project phases. Again, it is important that both threats and opportunities be identified. These risks could be classified as either known risks or known-unknown risks. The category of unknown-unknown risks should serve as a reminder to keep asking the question, What other threats or opportunities have we not thought about? Hopefully, the project team will do a more thorough job of identifying risks early in the project and reduce the likelihood of being surprised later.
The risks identified by the team can then be categorized as external or internal to the project. The internal risks are the direct responsibility of the project manager or team, while external risks may be outside their control. Regardless, both external and internal risks must be monitored and responses should be formulated.
The next step involves identifying the various sources of risk. Instead of trying to neatly categorize a particular risk, it may be more important to understand how the sources of risk are interrelated with each other. In addition, it may be a situation where precise definitions get in the way of progress. Instead of arguing or worrying about the exact source of a particular risk, it is more important the stakeholders understand the complex nature of a risk. Each risk-source category may mean different things to different stakeholders. Depending on the project, the stakeholders should be free to develop their own definitions and interpretations for each risk source category. They should also feel free to add categories, as needed.
After identifying the nature and characteristics of a particular risk, the project team can assess how a particular risk will impact the project. At this point, the team should focus on the project objectives that would be impacted if a particular risk occurred and, in turn, whether the project's MOV or goal would be impacted. Later on, these risks can be assessed to determine how the objectives will be impacted.
The above example shows how, working from the outside and then inward toward the center of the model, risks can be identified using the IT project risk framework. This procedure works well as a first pass and when using the project plan or WBS as a source of input. Many threats and opportunities may, however, be overlooked when relying only on the WBS.
The project team could start with the inner core of the IT risk framework and work outward. For example, the project team could identify how the MOV may be affected in terms of threats or opportunities that affect the project's scope, schedule, budget, or quality. Working away from the center, the team could identify possible sources of risk and then categorize whether the risk is internal or external, known, known-unknown, or unknown-unknown (i.e., did we miss something?), and when during the project life cycle this particular risk might occur.
Identifying risks is not always easy. Risks tend to be interrelated and identifying each and every risk may not be possible or economically feasible. People may not want to admit that potential problems are possible for fear of appearing incompetent. As a result, stakeholders may deny or downplay a particular risk. Still, people and organizations have different tolerances for risk, and what may be considered a normal risk for one stakeholder or organization may be a real concern for another. So, the stakeholders may concentrate on a particular risk (that may or may not occur) at the expense of other risks that could have the same impact on the project.
It is, therefore, important that the project manager and team guide the risk management process. Risk identification should include the project team and other stakeholders who are familiar with the project's goal and objectives. Using one or more of the following tools, the IT project risk framework introduced earlier in this section can provide direction for identifying the threats and opportunities associated with the project:
• Learning Cycles—The concept of learning cycles was introduced in Chapter 4. The project team and stakeholders can use this technique, whereby they identify facts (what they know), assumptions (what they think they know), and research (things to find out), to identify various risks. Using these three categories, the group can create an action plan to test assumptions and conduct research about various risks. Based on the team's findings, both risks and lessons learned can then be documented.
• Brainstorming—Brainstorming is a less structured activity than learning cycles. Here the team could use the IT risk framework and the WBS to iden tify risks (i.e., threats and opportunities) starting with the phases of the project life cycle and working towards the framework's core or MOV or working from the MOV outward toward the project phases. The key to brainstorming is encouraging contributions from everyone in the group. Thus, initially ideas must be generated without being evaluated. Once ideas are generated by the group as a whole, they can be discussed and evaluated by the group.
• Nominal Group Technique (NGT)—The NOT is a structured technique for identifying risks that attempts to balance and increase participation (Delbecq and Van de Van 1971). Using the NGT:
a. Each individual silently writes her or his ideas on a piece of paper.
b. Each idea is then written on a board or flip chart one at a time in a round-robin fashion until each individual has listed all of his or her ideas.
c. The group then discusses and clarifies each of the ideas.
d. Each individual then silently ranks and prioritizes the ideas.
e. The group then discusses the rankings and priorities of the ideas.
f. Each individual ranks and prioritizes the ideas again.
g. The rankings and prioritizations are then summarized for the group.
Delphi Technique—If the time and resources are available, a group of experts can be assembled—without ever having to meet face-to-face. Using the Delphi technique, a group of experts are asked to identify potential risks or discuss the impact of a particular risk. Initially, in order to reduce the potential for bias, the experts are not known to each other. Their responses are collected and made available anonymously to each other. The experts are then asked to provide another response based upon the previous round of responses. The process continues until a consensus exists. The advantage of using the Delphi technique is the potential for getting an insightful view into a threat or opportunity; but the process takes time and may consume a good portion of the project's resources.
Interviewing—Another useful technique for identifying and understanding the nature of IT project risks is to interview various project stakeholders. This technique can prove useful for determining alternative points of view; but the quality of the information derived depends heavily on the skills of the interviewer and the interviewees, as well as the interview process itself.
Checklists—Checklists provide a structured tool for identifying risks that have occurred in the past. They allow the current project team to learn from past mistakes or to identify risks that are known to a particular organization or industry. One problem with checklists is that they can lead to a false sense of security—i.e., if we check off each of the risks on the list, then we will have covered everything. Table 8.2 provides an example of items that may be included in a project risk checklist.
Table 8.2 Example of an IT Project Check List Risk Checklist
y/ Funding for the project is sufficient. >/ Funding for the project has been approved by senior management. The project team has the requisite skills to complete the project. */ The project has adequate manpower to complete the project.
✓ The project charter and project plan have been approved by senior management or the project sponsor.
i/ The project's goal is realistic and achievable.
✓ The project's schedule is realistic and achievable.
</ The project's scope has been clearly defined.
Processes for scope changes have been clearly defined.
*SWOTAnalysis—SWOT stands for Strengths, Weaknesses, Opportunities, and Threats. Brainstorming, NOT, or the Delphi technique could be used to identify and understand the nature of IT project risks by categorizing risks using the frame work illustrated in Figure 8.3. The usefulness of using SWOT analysis is that it allows the project team to identify threats and opportunities as well as their nature in terms of project or organizational strengths and weaknesses. *Cause-and-Effect Diagrams—The most widely known and used cause-and-effect diagram is the fishbone, or Ishikawa, diagram developed by Kaoru Ishikawa to analyze the causes of poor quality in manufacturing systems. The diagram can also be used for understanding the causes or factors of a particular risk, as well as its effects. An example of an Ishikawa diagram is illustrated in Figure 8.4. The diagram shows the possible causes and effects of a key member of the team leaving the project. This technique itself can be used individually or in groups by using the following steps:
a. Identify the risk in terms of a threat or opportunity.
b. Identify the main factors that can cause the risk to occur.
c. Identify detailed factors for each of the main factors.
d. Continue refining the diagram until satis fied that the diagram is complete.
Past Projects—One of the themes in this text has been the integration of knowledge management to support the project management processes. Lessons learned from past projects can provide insight and best practices for identifying and understanding the nature of IT project risks. The usefulness of these lessons takes time and a commitment by the organization and project team to develop a base of knowledge from past projects. The value of this knowledge base will increase as the base does, allowing project teams to learn from the mistakes and successes of others.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.