Identifying and Assessing Risks - The Second Step

Identifying and Assessing Risks—The Second Step

Identifying risks is not a task that many project teams or organizations have done well in the past. Even today, risk identification and assessment, or the lack of it, is one of the key reasons that projects fail. In general, risk identification and risk management are not done well because of the difficulty in identifying risks. Given that risk is an uncertain and sometimes an unknown event, risk management tends to be viewed as more esoteric compared to the hard engineering components of the project. Therefore, many project teams and organizations are not as comfortable with it. Once a procedure for identifying risks is in place, however, managing them becomes less scary and much easier.

Risk identification is best accomplished with a team simply because the collective knowledge and experience of a group of people is far greater than an individual's can be. There are several methods useful in the process, but the best methods all are some variation of brainstorming. The brainstorming technique itself is generally the one method that yields the greatest number of identified risks because it is designed to produce a large amount of data in a relatively short period of time. Another technique especially useful for identifying sources of risk is the Ishikawa, or cause-and-effect, diagram. This diagram is also called the fishbone diagram because of its resemblance to the skeleton of a fish when it is completed. This technique is most often associated with quality analysis but can be used any time the objective is to identify the root causes of a problem. It has the added advantage of being a brainstorming technique as well and lends itself nicely to team development. Exhibit 7-4 is an example of how a cause-and-effect diagram can be used to identify software problem risks.

Exhibit 7-4: Cause-and-effect diagram for analyzing risk.

Checklists and Assumption Analysis

Historical data from the lessons-learned archives provides a rich source of information from which checklists can be developed. The organization's guidelines should include such a checklist. However, a word of caution: If they are used exclusively, checklists can create a false sense of security. The problem with checklists is that it is easy to assume every potentiality has been considered, if all the blocks are checked on the list. A checklist is simply a guide that contains the most common risks. Hence, it is only as good as the data used to develop it. The checklist is helpful and will reveal a number of potential risks, but the prudent project manager will use the checklist as one of several techniques for identifying her project risks.

All projects and project solutions are based on assumptions. Even the customer's scope statement is based on some assumptions. A major part of the risk identification process is an assumption analysis to determine assumption validity and whether any potential risks are present because of inaccurate, inconsistent, or incomplete assumptions.

An assumption analysis is best accomplished by listing all assumptions from scope statements, contract documents, and any other project descriptions in a matrix that describes each assumption and its rationale. Each of the assumptions can be checked against its reason and revised or discarded, depending on the validity of the rationale.

At this stage of risk planning, it is important that no filtering or prioritizing is attempted. The objective is to identify all potential risks. Filtering and prioritizing are techniques employed in the next step—qualifying the risks.