Identifying the Project Risks

---

Armed with the inputs to risk identification, the project manager and the project team are prepared to begin identifying risks. Risk identification should be a methodical, planned approach. Should risk identification move in several different directions at once then some risks may be overlooked. A systematic, scientific approach is best.

Reviewing Project Documents

One of the first steps the project team should take is to review the project documentation. The project plan, scope, and other project files should be reviewed. Constraints and assumptions should be reviewed, considered, and analyzed for risks. This structure review takes a very broad look at the project plan, the scope, and the activities defined within the project.

Brainstorming the Project

Brainstorming is likely the most common approach to risk identification. It’s usually completed together as a project team to identify the risks within the project. The risks are identified in broad terms and posted, and then the risks’ characteristics are detailed. The identified risks are categorized and will pass through qualitative and quantitative risk analysis later.

A multidisciplinary team, hosted by a project facilitator, can also complete brainstorming. This approach can include subject matter experts, project team members, customers, and other stakeholders to contribute to the risk identification process.

Using the Delphi Technique

The Delphi Technique is an anonymous method to query experts about foreseeable risks within a project, phase, or component of a project. The results of the survey are analyzed by a third party, organized, and then circulated to the experts. There can be several rounds of anonymous discussion with the Delphi Technique—without fear of backlash or offending other participants in the process.

The Delphi Technique is completely anonymous and the goal is to gain consensus on project risks within the project. The anonymous nature of the process ensures that no one expert’s advice overtly influences the opinion of another participant.

Identifying Risks Through Interviews

Interviewing subject-matter experts and project stakeholders is an excellent approach to identifying risks on the current project based on the interviewees’ experience. The people responsible for risk identifications share the overall purpose of the project, the project’s WBS, and likely the same assumptions as the interviewee.

The interviewee, through questions and discussion, shares his insight on what risks he perceives within the project. The goal of the process is to learn from the expert what risks may be hidden within the project, what risks this person has encountered on similar work, and what insight the person has into the project work.

Analyzing SWOT

SWOT means strengths, weaknesses, opportunities, and threats. SWOT analysis is the process of examining the project from each of the characteristic’s point of view. For example, a technology project may identify SWOT as

• Strengths The technology to be installed in the project has been installed by other large companies in our industry.

• Weaknesses We have never installed this technology before.

• Opportunities The new technology will allow us to reduce our cycle time for time-to-market on new products. Opportunities are things, conditions, or events that allow an organization to differentiate itself from competitors and improve its standing in the marketplace.

• Threats The time to complete the training and simulation may overlap with product updates, new versions, and external changes to our technology portfolio.

Using Checklists

If the current project is similar to projects completed in the past, using a checklist of risks is a good approach. The advantage of a checklist to identify risks is that it’s a simple and direct approach to identify risks. The disadvantage of using a checklist for risk identification is that the participants may limit their risk identification to only the risk categories on the checklists. It’s virtually impossible to create a complete and usable checklist of risks for most projects.

Checklists, if they are used, should be used as a guide—not as a complete and final list of risk identification. Risks that are not included on the checklists should be explored, documented, and planned for. Although checklists are an excellent tool, they often limit the project team in identifying all of the risks relevant to the current project.

If checklists are used, then at project closure the checklist must be revisited to ensure the list is accurate and complete for future projects that may use the same checklists.

Exam Watch

Checklists are great for risk and quality management. At project closure, however, be certain to update the checklists for future projects. The current project will act as future historical information.

Examining the Assumptions

All projects have assumptions. Assumption analysis is the process of examining the assumptions to see what risks may stem from false assumptions. Examining assumptions is about finding the validity of the assumptions. For example, consider a project to install a new piece of software on every computer within an organization. The project team has made the assumption that all of the computers within the organization meet the minimum requirements to install the software. If this assumption were wrong, then cost increases and schedule delays would occur.

Examining the assumptions also requires a review of assumptions across the whole project for consistency. For example, consider a project with an assumption that a senior employee will be needed throughout the entire project work; the cost estimate, however, has been billed at the rate of a junior employee.

Utilizing Diagramming Techniques

There are several diagramming techniques that can be utilized by the project team to identify risks:

• Ishikawa These cause-and-effect diagrams are also called fishbone diagrams. These are great for root cause analysis of what factors are causing the risks within the project. The goal is to identify and treat the root of the problem, not the symptom.

  

• Flow charts System or process flow charts show the relation between components and how the overall process works. These are useful for identifying risks between system components.

• Influence diagrams An influence diagram charts out a decision problem. It identifies all of the elements, variables, decisions, and objectives—and how each factor may influence another.

  

---