Updating Risk Identification Checklists and Response Plans

Have you ever tried to follow a plan only to find that the plan wasn't up-to-date and contained inaccuracies? For a plan to be effective, it must be kept current. New information, changes, and corrections have to be made in a timely manner to prevent inappropriate actions being taken on inaccurate or outdated information.

When monitoring and controlling risks, documentation is especially important because project managers and teams use risk documentation to:

• track risks
• to identify new risks
• to plan additional risk responses
• to record any actions taken to control risks

If the information being acted on is not current, a new risk is introduced—the risk of acting on inaccurate or outdated information. To avoid this confusion, you must strive to keep all documents up to date.

Two of the most important documents to keep current are the risk identification checklist and risk response plan.

Risk identification checklists
Risk identification checklists describe the criteria used to identify new risks. Project team members should use the experience gained during their projects to update the checklists. This will make the checklists more effective for use in the risk management of future projects.

Risk response plans
The risk response plan is a document that describes in detail what actions should be taken in response to specific risks. Since the risk response plan acts as a guide to risk monitoring and control, the project team should update it regularly to keep everyone equally informed.

There are many elements that you can include in updates to risk response plans. Usually updates are the product of an action or event that changes the risk situation of the project. In some cases, the fact that an action was not taken leads to the need for an update. Some of the common elements included in updates to a risk response plan are:

• Implementing risk controls - The implementation of risk controls may reduce the impact or probability of identified risks. Documenting the implemented risk controls will provide the project team with the information it needs to change its future expectations for particular risks.
  
  
• Changing risk rankings - Risk rankings change throughout the project's life cycle. You should document these changes so you and your team can properly control higher ranking risks.
  
  
• Closing risks - Risks that do not occur and that are no longer considered a threat should be documented and closed in the risk response plan.

Updating documentation can help avoid confusion and keep everyone on the project equally informed. The information added to the documentation will help you prepare for similar risks that may occur in future projects.

What Are the Outputs of Risk Identification?

The risk identification process provides you with important information you need to make your projects successful. The outputs from risk identification are: risks, triggers, and inputs to other processes.

Risks
One of the outputs from risk identification is a list of potential project risks. A risk is an uncertain event or condition that could have a positive or negative effect on a project objective.

Examples of positive influencing risks are:

• proposal for graphics to be developed in-house
• proposal for quality assurance reviews to be done in-house
• cost savings of creating the training on the web and not on CD-ROM
• change in innovative advancements in technology
• industry standards improving quality for the insurance certification program

Examples of negative influencing risks are:

• conflicting software between client and developer
• scope changes requested by client
• intellectual property issues with client
• content negotiations with client
• unrealistic performance goals imposed

Whether a risk is positive or negative, it can force the project's objectives to go unfulfilled.

Triggers
Triggers are symptoms or warning signs that indicate that a risk has occurred or is about to occur. Triggers can be identified using the tools and techniques of risk identification. Consider the following examples.

Ben, a project manager at a pharmaceutical company, is developing a prototype for a new chemotherapy drug. One project trigger is a failure to meet immediate milestones for the approval stages. This will cause a delay in the schedule.

Elaine, a project manager of a multimedia company, has to create a website for a bank. A trigger develops when the client asks for many more services on the site than originally planned. These scope changes signal a poorly defined scope plan.

Kathy, a project manager of an international marketing company, is on a marketing project with a group of not-for-profit disaster relief organizations. The trigger she sees is inexperienced staff which is causing delays and poor quality.

Being aware of triggers will help you deal with risks before they cause major damage to your project.

Inputs to other processes
The third output from risk identification is inputs to other processes. In the process of identifying risks, you may also identify the need for further action in another area. The action needed and supporting documentation become inputs for another process.

Communication plan - It may be necessary to revisit the communication plan if project stakeholders request a change in the way information is given to them.

Schedule - It may be necessary to revisit the schedule and build in some contingency due to changes. There may be technical risk where some new technology is being used or where equipment is not arriving on time.

Resource plan - It may be necessary to revisit the resource plan if there's a risk that several key people may leave due to illness or to other project priorities.

Work breakdown structure (WBS) - It may have been necessary to add information to the WBS if it did not have sufficient detail to allow adequate identification of risks.

The outputs of risk identification are risks, triggers, and inputs to other processes. When you are familiar with these outputs, you increase your chances of successfully achieving your project goals.

Identifying Risk in an Interview

As a project manager, you want your project to be completed on time and within budget. For this to happen, you need to know what risks have the potential to adversely affect your project and threaten overall project success.

Among the various information-gathering techniques useful in identifying potential project risks is the interview. To learn about project risks, you can interview experienced project managers, subject matter experts, senior project team members and knowledgeable project stakeholders.

Using interviews to identify project risks is a 3-step process.

Step 1: Select the interviewee.
The first step is to select the right person to interview. There are three characteristics that you should look for when selecting an interviewee.
One characteristic that your potential interviewee should possess is a high degree of skill in, or knowledge of, a certain subject. Experts with a high level of skill or knowledge will be able to identify specific project risks, such as financial or technical risks.

Another characteristic that your potential interviewee should have is experience and training on similar projects. Experts with relevant experience can help you identify risks that are common of the type of project you are managing.

The third characteristic that your potential interviewee should possess is the ability to think objectively and critically. Experts who think critically and objectively can help identify risks that others involved in the project may overlook.

Step 2: Prepare the interviewee.
The second step in the interviewing process is to prepare the interviewee for questioning. At this stage, you should tell the interviewee what the project goals are, how long the project is expected to last, and what the constraints facing the project are.
Each selected interviewee will also need specific information that can be found in the project definition, scope documentation, and in the project's high-level WBS.

For example, a project manager informs several interviewees that the project under examination involves the development of a new kind of pain reliever. This project is expected to be delivered within one year of the start date and have less than a four-percent probability of harmful side effects. In addition, the project is faced with a limited amount of contingency reserves and may encounter budget problems if any of the critical path phases are delayed.

By briefing the interviewees on this type of project information, the project manager has adequately prepared the interviewees for the questioning process. They will now have sufficient knowledge of the project to identify potential risks that may negatively affect the project in question.

Step 3: Direct the interview.
The third step of the interviewing technique is to direct the interview. As a project manager, it is your responsibility to ensure that your interview stays on track. You must use the experience and knowledge of your expert, combined with all relevant project information, to identify as many project risks as possible.
There are three key questions that will help you focus and direct the interview. They are:

1. What could go wrong during this project?
By asking your expert what could go wrong during the project, you will be able to identify risks that may affect your project. Imagining a worst-case scenario will increase your chances of identifying risks that have the potential to negatively impact your project.

2. Where have similar projects failed?
By questioning where similar projects have failed in the past, you will be able to identify risks that may be common or typical of all projects of this nature. Your expert may be able to use previous experience to provide you with insight about project areas that are sensitive to certain risks.

3. What are the consequences making unresearched assumptions?
By asking your expert the consequences of incorrect project assumptions, you will be able to identify risks that may arise due to inadequate or poorly researched project information. Asking "what if's" is a good way to pinpoint risks that may otherwise go unnoticed.

There are three essential steps that should be followed when using the interviewing technique to identify risk. Project managers should select the right interviewee, prepare the interviewee, and direct the interview.

As a project manager, you can use the interviewing technique to gather vital information about potential project risks. This technique will also help make your project's risk identification process easier and more accurate.

Identifying Risks by Reviewing Documents

Ling, a project manager (PM) with Simple Software Solutions, feels extremely overwhelmed. She is new to the realm of project management. Her first project with this company is the Key-entry project. This project entails the development of privacy software solutions for a large Internet company.

Ling wonders how she can possibly identify all the risks for this project. A good place for Ling to start is the documentation review.

Every project plan and list of project assumptions will contain risks. Documentation reviews identify the inherent risks in the project plan and assumptions. In order to perform a documentation review, you and your team members should carry out a structured review of project plans and assumptions, files from previous projects, and other available information.

There are three steps that need to be addressed in order to perform effective documentation reviews.

Step 1: Identify the project documents needed.
When you are ready to begin the documentation review for your project, the first step is to gather the necessary documents.

The documents you gather for the review are critical to identifying project risks. You should examine documents available from the current project, plus documents from similar past projects. Some of the most helpful documents are the:

• Post-project reviews from similar, past projects - Post-project reviews from similar past projects are documents contained in project files that summarize what went as expected during a project and what didn't go according to plan.
• Lessons learned from similar past projects or any other documents from similar past projects that will be helpful - Lessons-learned documents refer to the learning gained from performing a project. They may be identified at any point in a project and are often considered as project documentation.
• Other documentation for the current project that will be helpful - Other documentation includes the inputs to the project's risk management plan, such as project charters, the company's risk management policies, defined roles and responsibilities, stakeholder risk tolerances, the company's risk management plan template, and the WBS.

Step 2: Choose how the review will be structured.
Next, you need to decide how the review will be structured. The structure of the review is contingent upon two factors: 1. the size of the project; and 2. the areas of the project being targeted.

Documentation reviews for projects of more than five phases should occur at the management level and are conducted for each phase and subphase. These reviews will be continuous throughout the project and will involve various participants in each phase. Reviews for projects with fewer phases should occur at the team member level for each phase of the project.

PMs must also decide the areas that are being targeted for risk identification. This is project specific and depends on the types of project and risks that may occur.

If a project involves developing new technology, the PM may target the design and marketing risks.

If a project uses a lot of external suppliers, the PM may target the supplier management risks.

If the project involves construction, the PM may target industrial safety risks.

If the project involves construction, the PM may target industrial safety risks.

Step 3: Identify the reviewers for each part of the review.
When selecting the team members for the documentation review, you should ask yourself "Who are the people who have the necessary experience and knowledge for this area of the project and who will bring the most value to a discussion about potential risks?" Generally, the reviewers will be the project team members, subject matter experts (SMEs), team members from similar projects, and other stakeholders, like sponsors. The documentation type, for example, project level, also plays a role in deciding who should be part of the review team.

Ling is ready to begin the documentation review for the Key-entry project. First, Ling gathers files from two similar privacy software development projects that Simple Solutions has recently completed. Then she decides how the documentation review will be structured. She examines the project plan and assumptions for the Key-entry project. She decides this project is rather large.

Finally, Ling identifies the reviewers for each part of the review. She selected Jake because of his extensive experience, Tanya because of her expertise in the field, and Rachel because she is the lead project team member. They have a discussion and successfully identify risks for this project.

Knowing how to perform effective documentation reviews is an important skill. Performing an effective documentation review is a good way to begin the risk identification process.

Categorizing Project Risks

It sometimes seems that the opportunities for something to go wrong are endless! One way for you to make sense of these endless possibilities is to organize them into easy-to-understand categories.

One of the inputs to risk identification is risk categories. Risk categories should be well defined. They should also reflect common sources of risk for the industry or application area. The industry could be anything from construction to software development. The application area is the customer. There are numerous types of customers depending on who the company is selling the project to. The customers could range from government agencies to an independent real estate developer.

Project risks fall into one of four categories:

• technical, quality, and performance risks
• project management risks
• organizational risks
• external risks

The first category consists of three factors: technical, quality, and performance risks. Throughout the project, project managers should think about whether or not any part of the project relies on new, unproven or complex technology, unrealistic performance goals, or changes to the industry standards or the technology used.

• Technical - Tabitha is in charge of a grocery store development project in Montana. She identifies the new software being developed for the cash registers and security systems as a definite risk. This software has never been used, and a few malfunctions have already had to be addressed.
• Quality - Tabitha reviews the initial blueprints and examines the three-tiered parking garage that will make parking easier for customers. She quickly realizes, however, that the costs of building such a parking garage are not practical and that they will be too costly for this project.
• Performance - Tabitha realizes that it is important to estimate the store completion date as accurately as possible to please the client. A risk that could seriously affect this date is unrealistic performance goals of the construction workers hired for the project. Tabitha takes note of this risk.

The next risk category is project management risks. Some examples of project management risks are:

• poor allocation of time and resources
• inadequate quality of the project plan
• poor use of project management disciplines.

Meril is a project manager in charge of a grain hybrid research project for Flax Technologies. He has a staff of 23 people that assist him with the various tasks involved with this project. Meril struggled a bit with the last project assigned to him. This was, in large part, because many of the project's identified risks became reality. This time, he is very careful to avoid losing valuable time and resources because of a lack of a comprehensive project plan. He also develops a clear and well-organized schedule outlining duties and deadlines.

Meril monitors the costs of this project very closely and catches discrepancies early. He takes a proactive approach and it pays off. The grain hybrid research project is completed under budget and ahead of schedule.

Another type of risk category is organizational risks. Examples of organizational risks are: cost, time, and scope objectives that are inconsistent, projects that are improperly prioritized, funding that is inadequate or interrupted, or resources that are inadequate or unavailable. Organizational risks are most often controllable. Dealing with organizational risks effectively can increase your organization's overall success exponentially.

In 2001, Quarry Properties had to complete a large redevelopment project in Asia. A project manager saw that the money allocated for this project and the completion date looked unrealistic in the project plan. The plan was modified and the risks were minimized.

Lavender Pharmaceuticals had three important projects underway last year. The project managers in charge of each project were aware of which project was most important to complete first. Resources were reallocated when prudent.

Dahl Insurance developed a new flood insurance program last year. When Pete, the project manager, examined the budget for this project, he noticed that funds were cut off half-way through completion. Funding allocation was reevaluated.

Travel Temptations wanted to develop a European cruise travel package exclusive to Temptations' customers. It was quickly discovered that the company couldn't find a cruise ship company for a partner. Therefore, the project was put on hold.

Another risk category is external risks. External risks are changes that are outside the control of the company and are therefore unpredictable. Some examples of external risks are:

• a changing legal or regulatory environment
• labor issues
• weather risks
• changing customer priorities.

Jeff, a PM at Flax Technologies, is in charge of the urban grain storage project taking place in Hong Kong. The project entails the development and maintenance of grain storage facilities in Hong Kong that will allow local customers easier access to the grain. Jeff makes careful note of the potential external risks.

Jeff realizes he must comply with Hong Kong's labor regulations. He also needs to work with Hong Kong construction bylaws and update procedures when needed.

Jeff knows that there is a monsoon season in Hong Kong that could pose great risks to construction. He organizes building dates to avoid this external risk.

There are some risks that are considered force majeure. A force majeure is an unexpected or uncontrollable external force. Earthquakes, floods, and severe civil unrest are examples of force majeure. These risks generally require disaster recovery rather than risk management.

Why categorize risks? A project may be subjected to many risks, both big and small. Understanding the different types of risks can help you stay organized. There are some risks that are more controllable than others. If you can stay ahead of the controllable risks, you will have the time and energy to deal with uncontrollable risks.

Categorizing risks can help you make sense of the vast array of risks that are part of any project. If you know the risk categories, you will be better equipped to manage your projects' risks.