Skip to main content

Sample Risk Management Plan - Part 3: Risk Identification

Published: November 15, 2011

Updated: November 16, 2011

Section 3: Risk Identification

One major requirement for the A&D High Tech Internet Store project is to complete the project and bring the store online before the Christmas season. This requirement may be the single most important factor in determining the success of the project. Identifying the risks that affect this requirement will be a major step in ensuring that the requirement is met. This section of the paper identifies those risks and defines the impact of those risks.


3.1 Determine the Risks

Brainstorming and the Delphi technique were employed to identify possible risks that could affect the A&D High Tech Internet store project. The main sources of information for these sessions were the project documentation and WBS. Some of these risks carry a very low probability of occurrence with a high possible impact. Other risks carry a high probability of occurrence with a low impact on the project. The following is a list of the types of risks that may impact the successful completion of the A&D High Tech Internet Store project and the varying impacts that those risks impose:

  • Changing business requirements

The impact of a change in the business requirements depends on the project phase during which those requirements change. Early changes would carry less impact than later changes. The actual impact of changing business requirements is hard to predict but the probability for this project is relatively low since the requirements appear to have been clearly defined.

  • Change in process flows

One of the assumptions made concerning the Internet store implementation is that the application will have no impact on existing process flows. If this assumption is incorrect then additions to existing staff may be necessary to handle the new or changed process flows or the quality of customer service will suffer.

  • Inaccurate physical infrastructure estimates

Robertson’s team estimated that twelve Windows 2000 workstations at $3000 each and five Windows 2000 servers at $12,500 each are required for the project (Jeffrey, 2007). Errors in this estimate could impose a positive or negative impact on the cost of the project depending on whether more or fewer units are needed than were estimated.

  • Incomplete prototype

The WBS and schedule appear to have been developed around a prototype that was previously developed. If the prototype lacks functionality then additional work packages will need to be added to the WBS and scheduled at the cost of additional resources.

  • Incomplete WBS

Some portions of the WBS only project three levels of activity instead of four, for instance, section 1.3.2: Create Data Requirements (Jeffrey, 2007, p11) does not specify the types of data requirements to be created. The impact of the WBS on the project is that there will likely be additional costs associated with missing elements.

  • Inaccurate effort estimates

The effort estimates for much of the project could be entirely correct, however, Geneva has not identified the specific resources for the outsourced portion of the project so the skill sets of those resources cannot be determined. If Geneva uses resources that are not the most competent for this type of project then there may be additional costs associated with schedule overruns and additional resources.

  • Lack of resources

This is a very high impact risk. If Geneva fails to assign necessary resources to the project then project failure may be eminent.

  • Scheduling conflicts

The current schedule shows that 160 days (Jeffrey, 2007, p.19) are needed for system testing. From the perspective of a project start time in May, the schedule shows that testing must begin immediately; even before the design phase is complete. The schedule also allocates 127 days for project management, which infers that the two functions run back to back as opposed to concurrently. This scheduling conflict, if not mitigated, will cause the project to miss the target requirement of opening the Internet store before Christmas.

3.2 Evaluate and Assess the Risks

The above list presents the types of possible risks that the A&D High Tech Internet Store project faces. However, there is no structure to the list.

Scroll to Continue

In order to understand which areas of the project might require special attention, and whether there are any recurring risk themes, or concentrations of risk on a project, it would be helpful if there were a simple way of describing the structure of project risk exposure. (Hillson, 2002).

The Risk Breakdown Structure (RBS) is a tool that provides such a structure. The RBS presents risks in a manner similar to that in which the WBS presents tasks. The RBS breaks risks down into levels with the first level. Level 0, being the overall project risk. As borrowed from Hillson (2002), Level 1 of the RBS for this project includes the following essential elements:

  • Product Engineering
  • Development Environment
  • Program Constraints

This level of the RBS indicates the three major elements of a software development project. Each of the Level 1 elements is broken down into sub-elements in Level 2, and then specific risks are placed in Level 3 according to the categories to which they apply. The author used this strategy to compile Table 3: Risk Breakdown Structure, located to the right.:

Table 3: Risk Breakdown Structure

Table 3: Risk Breakdown Structure

Identified risks are added to the RBS once the basic structure for the RBS is determined. Placing risks in the RBS can begin even before the WBS is complete. Using this strategy gives all project stakeholders a visual organization of the types of risks and what basic elements of the project the risks affect. Once the RBS has been developed, the risks may then be used to populate the risk matrix for further representation and analysis.

3.3 Qualitative and Quantitative Processes

Once a risk is identified and classified, further analysis is necessary to determine the impact of the risk. A qualitative analysis will satisfy the need to determine the probability of a risk occurring and the general impact. For instance, the risk of changing business requirements for this project would have a low probability of occurring.

A qualitative analysis of this risk may yield a low probability of 25% and the impact would be dependant on when in the project life cycle the requirements change. For risks such as this a qualitative analysis may be all that is necessary for the risk management plan. Likewise, a change in process flows also has a low probability of occurrence and the project impact would mainly be financial; adding personnel after the store goes online but a successful project completion could offset the risk.

The impact of some risks may not be ascertained by qualitative processes alone and quantitative processes, such as sensitivity analysis, may be needed.

Sensitivity analysis measures the impact of one risk with all other variables at a level plane. …This is a great method to ascertain the impact of a single risk; however the method does not yield a combined effect for risk analysis. (Elyse, 2007).

An incomplete WBS, for instance, will impact other variables. Scheduling and resources would be directly impacted by an incomplete WBS, which could then lead to negative impacts on morale and the time constraint for the project of opening the Internet store by Christmas.

Decision tree analysis combined with an analysis of EMV could be used to quantify the impact of inaccurate physical infrastructure estimates. EMV would place a monetary value on the project at various points in a decision tree that illustrates purchasing options for infrastructure components.

As stated earlier, the single most defining requirement for project success is to complete the project and open the Internet store before Christmas. There are many uncertainties that affect this requirement, especially resource allocation and scheduling. The schedule estimate was based on previous project averages using the experience of the analysts at A&D High tech. However, “plans based on average assumptions will be wrongon average" (Frontline Systems, Inc., 2009).

The Monte Carlo method of simulation, named for the games of chance in the famous casino, is an effective simulation tool that is useful in any situation that is full of uncertainty, according to Frontline Systems, Inc. (2009). This quantitative tool was developed by scientists in the 1940s to deal with the complex models used to develop the atomic bomb. Running Monte Carlo simulations does require that the user build some specialized models using a tool like Microsoft Excel and some specialized software is also required to perform the calculations but the expense could be well justified as an effective quantitative tool.

An evaluation copy of Frontline Systems’ Risk Solver, which includes a Monte Carlo simulation tool, is available for download free of charge for 15 days. This period should be long enough to perform Monte Carlo simulations on a number of risk models for the Internet store project. A successful project completion could then justify purchase of the product for future projects.

3.4 Compare and Contrast Techniques

The main technique used for identifying the risks associated with this project was the brainstorming technique. Brainstorming permitted the author to go over elements of the project and answer the question what are inherent risks that this element presents? The brainstorming technique is useful for individuals or small groups of stakeholders to uncover possible risks but is limited by the range of knowledge of the brainstorming participants.

A more concentrated form of brainstorming is the Delphi Technique, which drives a group of experts to apply brainstorming to a specific area. The Delphi Technique would be used to identify risks in areas that only professionals with specific knowledge could identify and would be highly effective in a real-world project similar to that portrayed by this paper.

An Ishikawa diagram, also known as cause and effect diagram, is a useful tool for tracking back the root cause of a specific effect. The cause and effect diagram is used to explore all the potential or real causes (or inputs) that result in a single effect (or output). Causes are arranged according to their level of importance or detail, resulting in a depiction of relationships and hierarchy of events. This can help search for root causes, identify areas where there may be problems, and compare the relative importance of different causes. (SkyMark Corporation, 2009).

An Ishikawa diagram would be most useful for following a specific risk back to the inputs which could lead to the risk event. Unlike brainstorming or the Delphi technique, which produce random lists of risk events, an Ishikawa diagram provides a categorization of risks and paths to follow back to specific causes.

Interviewing is an effective technique for determining the concerns of stakeholders and narrowing those concerns to specific risks. Unlike brainstorming, participants in interviews may maintain some degree of anonymity from other stakeholders. Only the interviewer needs to be present during the sessions so participants may feel more at ease to speak freely. Interviewing may be supplemented using questionnaires, which may provide a total sense of anonymity to the participants.

Dumbledore's Risk Management Series

Review Section 2: Charter, Scope, and WBS

Continue to Section 4: Risk Matrix


Elyse, PMP (2007). Quantitative Risk Management. AntiClue: Musings based upon adventures in Healthcare IT. Retrieved from

Frontline Systems, Inc. (2009). Monte Carlo simulation. Retrieved from

Hillson, D., Ph.D. (2002). Use a risk breakdown structure (RBS) to understand your risks. Retrieved from

Jeffery, M. (2007). A & D high tech (A): Managing projects for success. Project Risk Assessment and Control (pp. 1–16). New York, NY: McGraw-Hill.

SkyMark Corporation (2009). Cause and effect diagram. Retrieved from

Related Articles