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.

Diagramming the Causes of Project Risks

Drop a stone into a pond, and ripples will spread out from the point of impact. This is a cause-and-effect relationship. The rippling effect is caused by the impact of the stone. Remove the cause, and there is no effect.

As a project manager, it is to your advantage to identify the cause of a risk. When you know the cause, you can manage the effect—or risk—appropriately.

One way to view causes and risks is through a flowchart. Flowcharts focus on the cause of the risk instead of on the risk itself. With a contingency plan, you can limit or eliminate a risk's impact on a project's outcome.

The design of a cause-and-effect diagram, which is also called a fishbone or Ishikawa flowchart, is ideal for identifying and showing the possible causes of project risks. It is a diagram that clearly shows the relationship between a risk's cause and its effect.

There is a reason behind every risk—something has to cause a risk to occur. Accurately categorizing the causes for a particular risk will help you to build an effective cause-and-effect diagram.

Risks typically fall into one of six categories:

1. Methods - These risks involve a company procedure or a way of performing a particular task. For example, a company's security policies may not be stringent enough.
2. Materials - These risks involve the supplies a company uses to complete a project. For example, the computers used in a project may not have adequate memory capacity.
3. Environment - These risks involve activities that occur in the immediate physical surroundings. For example, poor weather conditions during a construction project may delay deadlines.
4. People - These risks refer to actions taken by the employees involved in a given project. For example, inadequately trained staff may be a project risk.
5. Information - These risks involve knowledge of a specific event or situation during a project. It can also refer to a lack of documentation or incorrect data. For example, a client's request is not recorded properly in the product specification.
6. Machinery - These risks involve machinery that can be a source of risk in manufacturing. For example, an outdated barker in a paper manufacturing company can be a risk.

These are three steps for constructing a cause-and-effect diagram:

• Identify the risk.
• Identify the causes.
• Build the diagram.

In identifying the risk, you place a concise statement of the problem or effect in a box at the end of a horizontal line.

Once you have identified a risk, you can identify its causes in a brainstorming session. Discussions of this sort typically focus on risks inherent in methods, materials, people, information, machines, and environment.

To build the diagram, you organize the causes of risk into the diagram layout. Each branch represents cause types such as materials, machines, and people.

What are some of the advantages of using a cause-and-effect diagram during the risk identification process? A cause-and-effect diagram acts as a visual display so problems can be seen more clearly. The diagram also helps break large problems down into manageable parts.

Cause-and-effect diagrams are an important part of project planning. In addition to helping you identify risks, these diagrams reveal the causes behind risk so you can manage the risk more effectively.

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.

Resources to Help You Avoid Past Mistakes

Somebody once said, "Every time history repeats itself the price goes up." If companies are aware of past experiences, they can save themselves from the expense of repeating mistakes.

One way to avoid past mistakes is to pay attention to historical information when developing your risk plans. Two sources of historical information are especially helpful in meeting this objective: past project files and published information.

Past project files
There are three types of project files that you can use to examine historical data: previous project documentation; the lessons-learned report; and the risk response plan.

You can find previous project documentation in the form of outputs from other planning processes. However, you should limit your search to documentation generated from similar projects.

Another good resource for identifying risks and avoiding past mistakes is the lessons-learned report. This document includes lessons learned from past projects, a description of the problems encountered along with the solutions to these problems.

The risk response plan file contains information on the processes put in place to monitor, review, and update the project risk. An examination of these risks will show that some risks are greater at specific stages of the project.

Published information
Other valuable sources of historical information are available in the form of published information. Published information which may give insights into past mistakes includes:

• Commercial databases - Commercial databases are sources that you can access to obtain professionally compiled information. A common example of historical information that commercial databases can provide you with is statistics.
• Academic studies - Academic studies may focus on risk factors of projects similar to the one you are managing. A great deal of time and research often goes into academic studies. You can benefit greatly from exploring this information source when developing your risk plan.
• Benchmarking report - Benchmarking involves an examination of your competitors' business practices or products. A benchmark report could give you insight into how other companies carried out similar projects and handled risks.

When researching the possible risks for a project, you can use historical information, gathered internally or externally, to avoid past mistakes.

Past projects completed within your company can provide a gold mine of lessons learned. But you can also look outside the company at how other companies and organizations have dealt with similar projects and their associated risks.

Historical information can provide you with important insights into the risks for the projects you are currently managing. If you have researched pertinent historical information, you will be able to deal with project risks more effectively.

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.

Outputs of Risk Management Planning

Do you know where to begin when it's time to identify your projects' risks? You should review the outputs of other project management processes before risk identification begins. The other project management processes are the risk management plan and other planning outputs.

The risk management plan
One of the planning outputs that you should review before identifying risks is the risk management plan. You should review the risk management plan because this is the document that describes how risk management activities for the project will be performed. It describes how risk identification, qualitative and quantitative analysis, response planning, monitoring, and control will be structured and performed during the project life cycle.

Lulu, a project manager at Beacon Corporation, develops a risk management plan for the Smart-Mart department store development project. The Smart-Mart risk management plan describes how Lulu and her team will approach an examination of the risks involved with this development and how they might address these risks. Lulu makes certain that the plan is comprehensive because she knows that it will serve as a guideline for risk management throughout the project's life cycle.

In the risk management plan, Lulu doesn't focus on the responses that will be taken for specific risks on the Smart-Mart project. Instead, it is a holistic overview of the risk management approaches that Lulu and her team will use for the Smart-Mart project.

Other planning outputs
There are eight categories of other planning outputs.

• project charter - The project charter is a document issued by senior management that formally authorizes the project. It provides you with the authority to apply organizational resources toward project activities.
• work breakdown structure (WBS) - The WBS is a grouping of the project elements that organizes and defines the total work scope of the project, based on deliverables.
• product description - The product description is a list of the features and functions of the product.
• schedule and cost estimates - Schedule and cost estimates are estimates of likely dates and costs involved with your project.
• resource plan - The resource plan is a description of the people, equipment, and materials needed to perform project activities.
• procurement plan - The procurement plan is the information about what needs to be purchased and when it needs to be purchased in order to carry out your project successfully.
• assumptions lists - An assumptions list contains the factors that are considered givens for your project.
• constraint lists - A constraint list contains the restrictions that will affect when your project activities can be scheduled.

After Lulu reviews the risk management plan, she examines the other planning outputs she should review as inputs to risk identification for the Smart-Mart project. First, she reads the Smart-Mart project charter. She thoroughly examines the human resources and the budget that have been allocated for this project because these two variables will have a significant impact on the way she manages the project. She also examines the WBS to see who should be doing what and the dates when each step should be completed.

Lulu notes the description of the Smart-Mart development. She wants to present the client with the exact building and layout requested. The schedule and cost estimates are clearly outlined on a graph that Lulu posts on a wall in her office and on a wall of the management trailer on the construction site.

Lulu examines the resource plan to see which Beacon employees should be placed in management positions for this project and to place accurate requests for building materials and supplies.

Lulu also reviews the procurement plan for Smart-Mart. This plan outlines what building and software materials will need to be purchased by specific dates. This will help Lulu place the orders on time and keep development moving at an acceptable rate.

The constraints list shows Lulu that lumber and concrete availability will affect when building activities can occur.

The fact that unionized construction workers receive a certain salary rate is a component of the assumptions list that Lulu examines.

The following list shows the name of each of the other planning outputs followed by the form they took in Lulu's project.

• Project charter - human resources and budget
• WBS - roles, responsibilities, and completion dates
• Product description - building and layout
• Schedule and cost estimates - available graph
• Resource plan - management positions and building materials
• Procurement plan - purchase materials
• Assumptions list - employee salaries
• Constraint lists - material availability

When Lulu reviews the project's other planning outputs, she familiarizes herself with all aspects of the project—such as scope, schedule, costs, and requirements—so that she can identify any areas that could be potential risks. Like Lulu, you will want to review the risk management plan and other planning outputs before you begin to identify risks. This process will make you more competent at risk identification.

Developing a Risk Management Plan

What do you think would happen if someone tried to carry out a complex commercial development project without using blueprints? The project would probably not run very smoothly. If you have a good blueprint, you will increase the chances of success for your project.

To ensure that all the people involved in your project meet their objectives, some type of blueprint for development is essential. A planning meeting is where a good blueprint will be developed to handle any risks that might occur during your project.

During the planning meeting, specific decisions have to be made to ensure you develop an optimum risk management plan for your project. It is the role of the PM to facilitate the meeting to ensure that an effective plan is developed.

The risk management plan that you develop at your meeting will describe how risk identification, qualitative and quantitative analyses, response planning, and monitoring and control will be structured and performed during your project's life cycle.

Methodology defines the approaches, tools, and data sources that might be used to perform risk management on your project.

Roles and responsibilities define the lead, support, and risk management team membership for each type of action in the risk management plan.

Budgeting establishes a budget for risk management for the project.

Timing defines how often the risk management process will be performed throughout the project life cycle.

Scoring and interpretation outlines the scoring systems you are going to use to rate risks. It includes thresholds that refer to the criteria for risks that will be acted upon.

Reporting formats describe the content and the presentation style of the risk response plan. Tracking documents how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned.

Once you have assembled your risk management planning team, you will have to distribute the appropriate project inputs to each team member. It is your responsibility to guide the team toward making the necessary decisions to create an effective risk management plan. It is your job to ask them the questions that will help them make these decisions. Some questions you should ask are:

• What methods will be used to assess risks?
• What are the risk management roles and responsibilities?
• How much will managing this risk cost?
• How often will risk management processes be performed?
• What thresholds will be set to determine further risk analysis and response?
• What reporting methods and tools will be used to report and document risk status and processes?

You not only need to ask questions, you also need to understand what type of answers you are looking for to create a risk management plan. Identifying the methodology to use to perform risk management depends on the project stage, the amount of information available, and the flexibility of the risk management plan. The method you choose should suit your company's usual approach to risk management.

Risks can be analyzed qualitatively or quantitatively. Qualitative methods classify risks into categories such as high, medium, or low. Quantitative methods assign numeric values based on the probability and consequence of risks. You should use the same method to analyze each risk because you have to be able to compare the results and prioritize the risks.

Based on the structure of your project and how your organization usually handles risk, your team members will assign risk management roles and responsibilities to qualified team members.

The team will decide who is needed to lead and support the risk management processes. For example, someone will be assigned to track changes as a result of risk.

The risk management team will determine the duties for each role. For example, the risk tracker will have to document how risk processes will be audited.

The team must also look at budget information when creating a risk management plan. Based on the decisions that you make, you will have to assess how much the management of the risk will cost for the project. If the cost is too high, you may have to revisit your decisions and reduce expenditures in certain risk management areas. For example, you may opt to reduce the frequency of audits in order to lower costs.

The team will decide how often to perform risk management processes. Timing will be based on the stakeholder risk tolerances and the critical elements in the project's WBS that require more stringent risk management. Stakeholder risk tolerances should be adhered to provided stakeholders understand the cost involved in risk management. If stakeholders want more frequent audits, the team should comply with their requests. Similarly, projects with more critical elements will require more frequent risk analyses.

A schedule describing how often risk management will be performed should be developed early enough to affect decisions and should be revisited throughout the project. For example, during a critical phase, it is likely that there will be more risk analyses.

The fifth question your team needs to answer when creating a risk management plan is what thresholds will be set to determine further risk analysis and response? Thresholds are defined limits for cost, schedule, and scope variance. To determine thresholds, the team should decide the degree of change that the project can sustain in order to address risks and then set limits based on that degree. If the team is unable to do this, this risk will require a response.

The final question involved in creating your risk management plan deals with the reports and tools used to report risk status and track risk management processes for the project. The reporting format outlines how the results of risk management will be documented, analyzed, and communicated. The tracking method documents how the risk processes will be audited. You must determine these methods before you can act on your risk management plan. This documentation serves as a record of the project's risk activities.

It is important to make the right decisions when developing your risk management plan. This will ensure that your plan is effective and will serve as a good blueprint for your project's risk management.

What Are the Inputs to Risk Management Planning?

In his famous book, "Poor Richard's Almanac," Benjamin Franklin wrote, "An ounce of prevention is worth a pound of cure." What might this mean in the context of risk management planning?

Prevention seems like a common sense idea, but achieving it does require some thought. Remember that projects are often long and complex and that they involve large amounts of money and other resources. Therefore, it's important to plan your risk management approach so that an "ounce" of risk prevention is in place.

You will use several different types of information and documents as inputs when planning for the management of your project's risks. The inputs used in risk management planning are the:

• project charter and work breakdown structure (WBS)
• organization's risk management policies
• defined roles and responsibilities
• template for the organization's risk management plan
• stakeholder risk tolerances.

The project charter and the WBS are key documents you use when planning risk management activities. Some of these activities are budgeting, scoring and interpretation, and tracking.
The project charter is a document that formally authorizes a project. It includes the business need that the project is undertaken to address.

The WBS is a deliverable-oriented grouping of project components that organizes and defines the total scope of the project.

When it comes to an organization's risk management policies, every organization is different. Some organizations have predefined approaches to risk analysis and response that need to be tailored to match individual projects that are carried out by the organization. It is your responsibility to know whether or not your organization has these predefined approaches. If it does, you need to make sure that you tailor and apply the predefined approaches to risk analysis and response to the project you are managing.

Another input to effective risk management planning is the defined roles and responsibilities. These include the predefined roles, responsibilities, and authority levels of the people that will influence project planning.

Templates for the organization's risk management plan are used as a format for creating the risk management plan. Many organizations have developed templates that are also known as pro-forma standards. Project team members adapt the template to their current project. Companies continuously improve the template based on its application and usefulness to the project.

The final input to risk management planning is stakeholder risk tolerances. Different organizations and different individuals have varying tolerances for risk. These tolerances may be expressed in policy statements or in actions.

The starting point of any risk management planning process must include inputs. Without them, the effect of your risk management planning would be like trying to take medicine from an empty bottle: no inputs, no positive benefits. Understanding the inputs used in planning risk management activities is basic to a sound project management approach at any level of expertise.