Avoiding a Project's Most Threatening Risks

Have you ever deviated from your regular driving route because excessive traffic or road construction may have put you at risk of being late for an important appointment?

In everyday life, people often modify their personal plans or schedules in order to avoid the unwanted consequences of potential risks. In the same way, project managers are often forced to change or modify their project plans in order to eliminate threatening project risks.

As a project manager, you will encounter various risks throughout your project's development. Although you can never prevent every project risk, you should make every attempt to eliminate as many as possible.

One risk response strategy that you can use to help you achieve a successful project completion is avoidance. Avoidance involves changing your project plan to eliminate an identified risk or the condition that causes the risk. This risk response strategy also involves protecting your project objectives from the impact of identified risks.

As a project manager, you can often respond to some risks that arise early in the life cycle of a project by clarifying requirements, obtaining information, improving communication or acquiring expertise. However, there are other types of project risks that you will need to avoid in order to promote a successful project completion. These types of risks include those that have a high probability of negatively impacting project objectives and those that have the ability to cause complete project failure.

Avoidance is one strategy that you can use to help you deal with these types of risks. Such things as reducing scope to avoid high-risk activities, adding resources or time, adopting a familiar approach instead of an innovative one or avoiding an unfamiliar contractor are all ways in which you can eliminate threatening project risks.

The first type of risk that you should avoid during the life cycle of your projects is unacceptable risks. These types of risks have a high probability of occurrence and an extreme or very high level of potential impact.

You should also avoid uncontrollable risks. These risks cannot be absorbed by the project's available resources or existing contingency reserves. They are also risks that do not have mitigation or transference strategies available.

The last type of risk that you should avoid throughout your project's development is potentially harmful risks. These risks are especially threatening to project success because they have the potential to harm a project's personnel.

As a project manager, there are three key questions that you can ask in order to determine if an identified project risk should be avoided. If you can answer "yes" to even one of these questions, the risk that you are examining should be flagged for avoidance. The three questions include:

• Is the level of risk unacceptable?
• Are the means for controlling the risk unfeasible?
• Is there a potential for harm?

As a project manager, how do you determine whether the level of an identified risk is unacceptable to your project and its outcomes? One of the best ways to answer this question is to examine the prioritized list of quantified risks that resulted from your project's quantitative risk analysis process.

This list indicates which risks pose the greatest threat or present the greatest opportunity to your project objectives and overall outcomes. This prioritized list of quantified risks also includes a measure of potential risk impact.

You should examine your project's prioritized list of quantified risks and set aside those risks that have an extreme or very high level of potential impact. Once this is done, you should make every effort to modify your current project plan in order to avoid these types of risks. Typically, project managers classify risks with an extreme or very high level of potential impact as unacceptable because of the possible danger they pose to the success of overall project outcomes.

Another element to consider when trying to determine whether the level of an identified project risk is unacceptable is the risk thresholds for the project. Risk thresholds, which are established in a project's risk management plan, indicate the level of risk that is acceptable to individual project stakeholders. If you have identified a project risk that has the potential to greatly exceed one or more of the established risk thresholds for your project, this is a risk to avoid because it threatens the successful completion of your project.

Another question to consider when trying to determine if an identified project risk should be avoided is: are the means for controlling the risk unfeasible? All projects are subject to such things as cost and time constraints. As a result, some project risks may be too expensive to control.

In addition, most projects are allotted a limited amount of contingency reserves. These reserves are the amount of money or time needed to reduce the impact of cost and schedule overruns on critical project objectives and outcomes.

If you find that the means for controlling one of your identified risks is not feasible and cannot be absorbed by your project's available contingency reserves, this is a risk that you should avoid. A careful examination of such things as your project budget, schedule, and personnel and material resources will help you decide whether your project has the means to reduce or eliminate the risk's potential impact or whether it would be more beneficial to avoid the risk altogether.

The third and final question that project managers can ask in order to determine whether an identified project risk should be avoided is: Is there a potential for harm? In most cases, a risk is considered harmful if it involves the presence of dangerous materials or conditions at the project site.

Project managers must be able to identify any risks that have the potential to harm their project team members or stakeholders. These risks may include such things as faulty machinery or unsafe working conditions.

More examples of harmful project risks are listed below. As a project manager, you should immediately flag these types of risks for avoidance. These risks include:

• tasks that involve handling, storage or disposal of hazardous materials
• major construction work in locations vulnerable to seismic activity
• other potentially damaging natural events.

It is important to remember that unforeseen risks will continue to arise as a project progresses. As a project manager, it is your responsibility to analyze these unexpected risks, as well as all identified project risks, in order to determine if they should be avoided. Once this decision is made, you can then modify your project plan to avoid the selected risks. This will help you ensure that your project remains on a progressive track and heads toward a successful completion.

Avoidance is sometimes the best response. As a project manager, you can use avoidance to eliminate some of your project's most threatening risks and their potential impact. This risk response strategy is a key contributor to overall project success.

Common Causes of Project Risk

Marina is a project manager for Outback Retailers. Her current project involves the development of a new type of high-speed racing bike. She has learned that there are several identified risks that have the potential to negatively impact her project objectives.

As a result, Marina is trying to develop risk responses that will eliminate or reduce the impact of these identified risks. Do you think it is possible for Marina to address two or more of her project risks with the same response?

Yes! By addressing more than one project risk with the same response, Marina will be able to deal with risk threats and risk opportunities more quickly, which will maximize the likelihood of a successful project completion.

Every project will encounter numerous risks. Many of these risks will be driven by a common risk cause. A common risk cause is an event or situation that produces more than one project risk.

As a project manager, you can identify common risk causes during the risk identification and risk analysis processes. It is important to take advantage of these opportunities whenever and wherever possible.

It is important to remember that every project is unique. Therefore, you cannot expect to identify the same common risk causes in every project that you manage. However, there are some causes that may occur more frequently than others. These common risk causes include:

• unavailability of resources
• inadequate quality standards
• lack of communication
• inadequate tools or technology

One common risk cause that may threaten the successful completion of your project is unavailability of resources. These resources may be people or materials. During the life cycle of your project, many risks may arise if you do not have sufficient personnel or supplies available to complete the project as planned. Such things as excessive cost and schedule overruns are only two of the risks that you may encounter if your project is threatened by a lack of available workers or materials.

Another common risk cause is inadequate quality standards. Identifying this common risk cause early in the course of a project is especially valuable because this risk cause has the potential to create several project risks that can adversely affect the promised consumer deliverable.

As a project manager, it is important to remember that if quality standards are not properly set or are not specific enough, your project will either fall below the expected standard or aim for a standard not required by the client.

Marina, from Outback Retailers, is beginning the risk response planning process for her current project. After studying the results from her project's other risk management processes, she finds that some of the quality procedures that concern the new product are not clearly detailed. In addition, phase three may be short by two people due to a recent staff reduction. Marina hopes that the identification of these two common risk causes up front will help make her risk response planning process more efficient.

A lack of communication is another example of a common risk cause. In daily life, whether at home or at the office, people often suffer the unpleasant consequences of not giving or receiving adequate or accurate information. This is especially true in project management. If clear and open lines of communication are not firmly established, a project may be put in serious jeopardy. Such things as change requests and project plan modifications may not be properly carried out if there is a break in communication.

Inadequate tools or technology is a common risk cause that can severely impact the outcome of a project. It is difficult to develop a product efficiently or according to its established standards if you do not have the adequate tools or technology to complete the product as specified in the project plan.

It is also possible that a project may suffer a complete failure if critical tools are not readily at hand when needed. This common risk cause may also result in project deliverables not meeting widely accepted industry standards.

As a project manager, it is important to remember that some of your project risks may be driven by a common risk cause. As a result, the identification of these common risk causes is a valuable input to risk response planning because it may allow you to address more than one project risk with a single response. This will help eliminate the creation of redundant risk responses and make your risk response planning process more efficient.

Risk Owners and Risk Thresholds

Author H. Stanley Judd once said, "A good plan is like a road map; it shows the final destination and usually the best way to get there."

As a project manager, you need to have an effective risk management plan in place before beginning risk response planning. A risk management plan can act as a guide to help you identify, analyze, and respond to various project risks and their potential consequences. This plan, which is created during the risk identification and planning process, details how the risk management processes will be structured and performed. It ensures that risks are properly managed throughout a project's life cycle.

The risk management plan has two important components that will be used in risk response planning: 1. a list of risk owners; and 2. risk thresholds.

A list of risk owners
One risk management plan component that will be used as an input to risk response planning is a list of risk owners. Risk owners include those project stakeholders who are responsible for the development, implementation, and execution of one or more risk responses. This risk management plan component is essential as a risk response planning input because it helps to ensure that everyone involved in the risk response planning process has clearly defined roles and responsibilities.

Typically, project managers are responsible for assigning the various risk owners within a project. These risk owners may be chosen from within the project team or from available subject matter experts. During risk response planning, risk owners may decide to develop risk responses as a group or divide the responses among the team members, based on their expertise.

Risk thresholds
Another component of the risk management plan that can act as an important input to risk response planning is risk thresholds. Risk thresholds are the levels of risk that are acceptable to individual project stakeholders, such as the project team members, customers or sponsors.

It is important to remember that project owners, customers, and sponsors may all have different risk thresholds for a given project, depending on their individual needs and interests.

The acceptable risk threshold for each project stakeholder forms the target against which the project team will measure the effectiveness of the risk response plan execution.

Liam, from Northern Pulp & Paper, is studying his company's established risk threshold for his current project. He wants to know how the risk threshold will influence his risk response planning process. Liam finds that the company will not tolerate a total project cost overrun of more than $5,000. He realizes that such things as purchasing additional materials or increasing staff may not be viable risk response options when handling identified project risks. Liam will keep this in mind as he progresses through the risk response planning process.

Equipped with a clear and accurate understanding of these two components, you will be able to ensure that potential project risks are dealt with effectively and in a timely manner.

Creating a List of Potential Risk Responses

How do you deal with risks throughout the life cycle of your projects? How do you formulate appropriate and effective responses to identified project risks?

During the risk identification process, project managers identify any risks that have the potential to negatively impact project objectives and overall project outcomes. These risks are then subjected to a qualitative and a quantitative risk analysis in order to produce a list of prioritized risks that can be dealt with in the risk response planning process.

When project managers, stakeholders, and subject matter experts are involved in identifying project risks, they often formulate a tentative list of potential responses to address these risks. These potential responses are strategies that are designed to enhance risk opportunities and reduce risk threats to project objectives. Although any action may be classified as a response, this list of potential responses created during risk identification is always specific to the project needs and the characteristics of the identified risk.

Specific details concerning the accuracy or effectiveness of these potential responses are not necessary during risk identification since that is the focus of the risk response planning process.

As a result of a project's risk identification process, you will have a list of potential responses that you can either accept, modify, reject, or add to during risk response planning.

It is important to remember that the list of potential responses created during risk identification is not a comprehensive or exhaustive list. It is simply a list of proposed suggestions that can be used to help address those risks that can have a negative impact on the success of a project. As a project manager, you will take this list of potential responses into consideration when deciding on an appropriate and effective risk response for identified and quantified project risks.

These potential responses are only suggested methods of dealing with these types of risks. Selecting the most effective and accurate response will occur later in the risk response planning process.

The following are some examples of common project risks and corresponding potential responses.

Common Project Risks
overly optimistic schedules
lack of adherence to quality procedures
unclear or vague project goals
inappropriate vendor or technology selection
budget cuts

Potential Responses
Review and monitor schedules at regular intervals.
Implement a quality management program.
Ensure that each goal is well-researched and realistic.
Perform a decision tree analysis for each major decision.
Reallocate project resources.

As a project manager, it is important to remember that your project's list of potential responses, developed during risk identification, is a valuable input to the risk response planning process. This list will help you develop specific actions that you can use to minimize or prevent threatening risks from occurring, as well as to maximize potential opportunities.

Identifying Risks that Require an Immediate Risk Response

Bruce, a project manager for Precision Technologies, performed a qualitative and a quantitative risk analysis on his last project. He found these analyses very useful because they helped him identify project risks that had the potential to adversely affect his project's success.

As a project manager, you will find that the outputs from other risk management processes can be extremely useful when performing risk response planning. Two such processes include qualitative risk analysis and quantitative risk analysis. Both of these processes attempt to assess and analyze the probability and impact of potential project risks. As a result, qualitative and quantitative risk analysis outputs can serve as effective inputs to a project's risk response planning process.

A qualitative risk analysis attempts to assess the impact and likelihood of identified project risks. It also prioritizes risks according to their potential effect on project objectives and overall project outcomes. A quantitative risk analysis aims to numerically analyze the probability of each risk and its consequences on project objectives, as well as the extent of overall project risk.

As a result of both a qualitative and a quantitative risk analysis, you will receive a list of risks, together with a measure of their potential impact, that will need to be addressed in the risk response planning process.

The qualitative and quantitative risk analysis outputs that may be useful as inputs to risk response planning include:

• list of prioritized risks
• risk ranking of the project
• prioritized list of quantified risks
• probabilistic analysis of the project
• probability of achieving project objectives
• qualitative and quantitative risk analysis trend results

One qualitative risk analysis output that acts as a valuable input to risk response planning is a list of prioritized risks. During the qualitative risk analysis process, risks are prioritized using a number of criteria. Risks may be assigned a rank of high, medium or low, depending on their potential severity of impact. Risks may also be grouped by those that require an immediate response and those that can be handled at a later date. Prioritized risks usually include risks that affect project cost, schedule, scope, and quality.

As a project manager, you can use this list of prioritized risks during risk response planning to help you decide which risks require your immediate attention. This list will also help you formulate responses for those risks that have the potential to negatively impact critical project objectives.

Another qualitative risk analysis output that you can use as an effective input to risk response planning is a risk ranking of the project. This ranking will indicate the overall risk position of a project relative to other projects by comparing the risk scores.

A risk ranking can also be used to assign resources to projects with different risk rankings, make a benefit-cost analysis decision about the project, or support a recommendation for project initiation, continuation or cancellation.

A risk ranking will help you decide which projects have the greatest needs and which projects will produce the greatest overall benefit. This will allow you to plan effectively for those projects that require immediate risk responses.

As a project manager, you can also use quantitative risk analysis outputs when preparing for risk response planning. These outputs can help you identify sensitive risk areas and formulate potential responses to threatening project risks.

A prioritized list of quantified risks will detail which risks pose the greatest threat or present the greatest opportunity to your project, together with a measure of their impact. This will help you identify risks that require an immediate risk response.

A probabilistic analysis of the project will forecast potential project costs and completion dates. This analysis will help you determine the type of risk response that is required to address threatening cost and scheduling risks.

An estimate of the probability of achieving project objectives under the current plan will indicate whether the project is progressing as planned, or whether it requires immediate risk response action in order to be completed successfully.

The last qualitative and quantitative risk analysis output that is useful as a risk response planning input is qualitative and quantitative risk analysis trend results. Trends can be defined as patterns of results that track in a particular direction. Once you've performed multiple risk analyses on your project, a trend of results may become apparent. This trend of results will indicate the level of urgency and the importance of the risk response.

As a project manager, you can use qualitative and quantitative risk analysis trend results to help you focus on those areas that would benefit from an immediate risk response the most.

Qualitative and quantitative risk analysis outputs will help you identify risks that require an immediate risk response so that you can reduce or eliminate their impact on project objectives and increase your project's chance of success.

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.

Identifying a Project's Supporting Details

Supporting details are another important aspect of organizational planning. Supporting details vary by application area and project size but typically include items such as organizational structure, job descriptions, and training needs.

Organizational structure
One aspect of compiling supporting details is to understand the limits imposed on you by the company's organizational structure. You may, for example, need to plan more time for executive approval if it is required for all project decisions. These are elements you typically can't change. When it comes to structure-imposed limits, your best strategy is to focus on what you can do within the confines of the organizational structure.

Job descriptions
Job descriptions are another aspect of supporting details. They help your project run smoothly by telling team members what is expected of them. Effective job descriptions eliminate potential conflicts over job duties, roles, responsibilities, and reporting structures. The best job descriptions provide details about competencies, responsibilities, knowledge, authority, and the physical job environment.

Training needs
Another aspect of supporting details is recognizing the training needs of your team members. Sometimes your job descriptions outline competencies your team members don't currently have. In this case, you need a plan outlining your team's training needs. Training ensures your team has the most up-to-date skills and is constantly ready for new challenges.

Supporting details are the final ties that bring a project together. Using this output from organizational planning allows you to move ahead with your project, secure in the knowledge that you have laid your plans carefully. Now you only have to follow through with those plans.

Methods for Charting Project Relationships

An organization chart shows you, in an instant, all the relationships within a company. It allows you to clearly see the layout of people and departments for an entire organization.

An organization chart is any graphic manifestation of project reporting relationships. It gives you the big picture of how your project fits into the overall activity of the organization. It shows the relationships:

• between resources of the project management system
• of formal authority between groups and individuals.

Organization charts can be formal or informal, highly detailed or broadly framed. The place of individuals within boxes on the organization chart shows broad working relationships. The connecting lines between boxes indicate formal chains of command and lines of communication between individuals.

Organization charts vary dramatically from one organization to another. They do, however, have some basic elements in common. For example:

• All members of the project are identified, including stakeholders.
• Data can be formal, informal, detailed, or general.
• Direct relationships between people are shown with a solid line.
• A dotted line indicates an indirect relationship, or a relationship that has not been clearly defined.

Organization charts offer project managers several important benefits. For starters, they show you the overall framework of the organization and indicate where project members fit into the organization. They also reveal the basic relationships between project team members, and they explain formal lines of authority (reporting relationships).

There are also drawbacks to using a traditional organization chart. For example, a traditional organization chart:

• doesn't show the nature and limits of the activities required to attain project objectives
• doesn't show the reciprocal relationships between people, which often occur within a project
• may not accurately reflect the structure throughout the project because it is often out of date very quickly
• may confuse people, as the pyramidal structure may portray a false sense of status and prestige.

Charts vary because organizations and projects vary. There are specific organization charts that give you added information. These charts help you as you plan. One such plan is an Organizational Breakdown Structure Chart (OBS)

An OBS identifies the roles and responsibilities of the individual as well as those of the collective project unit. And OBS is a concise description of the organizational interfaces. It illustrates:

• who the project participants are, the extent of their involvement, and their authority
• when decisions should be made or activities performed
• who has authority when team members share common work
• work packages or tasks necessary for project success.

And OBS is time consuming to prepare, but gives you more valuable information than a standard organizational chart.

A standard organization chart or Organizational Breakdown Structure Chart provides you with concise information concerning responsibility relationships within an organization. Both types of charts provide a useful tool of reference for everyone involved in the project.

What Does a Staffing Management Plan Include?

Jumping into your project without a staffing management plan is like jumping from a plane without a parachute. It might be the fastest way to your destination, but it clearly is not the safest or smartest decision.

The people you select to work on your project will either contribute to its success or its demise. To ensure the success of your project, you will want to identify your staffing requirements and come up with a staffing management plan.

A staffing management plan is an output of the organizational planning process. This kind of plan includes your basic staffing requirements and provides details about how people will be brought on board and released from the project.

• staffing requirements
  Staffing requirements describe the team members you need to carry out the tasks your project requires. Objective and subjective criteria are used to match the team members to various positions that need to be filled.
  
  Objective criteria outline the technical competencies needed from a potential team member to successfully fulfill a project task. Subjective criteria deal with the needed personality traits to successfully fulfill a project task.
  

• information about how people are brought on to the project
  Planning for your team members before they even come on board will help you to take better advantage of their expertise. Bringing people onto a project can be chaotic. New team members have many questions about their project tasks, roles, and responsibilities. You can help make this transition as smooth as possible by anticipating team members' questions.
  
  Job descriptions, training, project information, and reward programs, and a closing meeting are just some of the items to include in this part of your plan.
  

• Job descriptions - When team members know the parameters of their position, they can focus on exactly what they are there to accomplish. Job descriptions eliminate confusion and provide direction.
• Training - You want your team members to work as efficiently as possible. For this to happen, your team members require proper training. Training takes time up front, but saves you time in the long run.
• Project information - Project information allows team members to see where their tasks fit into the big picture. The more fully informed team members are, the more focused their tasks will be.
• Reward programs - Reward programs work as productivity incentives for your team members. This creates good morale, as team members feel they are recognized for a job well done.
• Closing meeting - A closing meeting, reviews both the positive and negative elements of a finished project. It allows you and your team members to make better plans for the next project, as well as capitalize on the strengths demonstrated in the finished project.

• Information about how people are released from the project
  Creating a plan to move people off projects is also beneficial. This type of planning provides direction, focus, and smooth transitions.
  
  Your staffing management plan should include a plan for re-assigning your team members as soon as the project is completed. Your team members should know when and where their next assignment begins.
  
  Properly releasing staff reduces costs by reducing or eliminating the tendency to make work to fill the time between this assignment and another. It also improves morale by reducing or eliminating uncertainty about future employment opportunities.
  

Completing a staffing management plan before jumping into your project will save you time and trouble later in the project. The plan you develop will help you to see how to put to the best use the skills, expertise, and talents of each and every team member. And this will allow you to execute the project sure and steady with fewer surprises.

Assigning Roles and Responsibilities

Do you cringe at the thought of responsibility? Many people do. Having something fall on your shoulders may seem daunting. However, it is also through responsibility that a certain amount of freedom is gained.

Freedom through responsibility? It's true. Responsibility gives you the freedom to use your skills, talents, and intellect. Most people thrive on responsibility and blossom when they believe they have handled their responsibilities well.

Successful projects have clearly defined project roles (who does what) and responsibilities (who decides what). Most roles and responsibilities are assigned to stakeholders who are actively involved in the work of the project. These can include the project manager, other members of the project management team, and the individual contributors. Roles and responsibilities may vary over time.

Project managers bear the majority of the responsibility for the success of the project. It is their job to ensure that a project comes in on time and on budget. To succeed in this capacity, project managers must delegate roles and responsibilities to their team members. And the tool they use to do this is called a Responsibility Assignment Matrix (RAM).

A RAM links project roles and responsibilities to the project scope definition. A RAM can be developed at various levels. Generally, they fall into two categories: low-level RAM and high-level RAM.

A low-level RAM delegates roles and responsibilities for specific activities to particular individuals within your team.

The more phases you have for your project, the more complex your matrix is going to be. A high-level RAM is very complex and shows many phases of a project. It may define which group or unit is responsible for each element of the work breakdown structure.

Responsibility is an essential component of project success. A Responsibility Assignment Matrix (RAM) shows where you and your team members' responsibilities lie.

Assigning responsibilities reaps huge benefits. Your team feels it has control and authority for specific tasks. Progress happens when team members focus on their own responsibilities.

Analyzing Stakeholder Interests

Stakeholder analysis is the process of discovering who has a stake in your project and identifying their interests. To perform stakeholder analysis, you must identify the stakeholders, their roles and primary interests in the project. Then you must analyze the relationships between stakeholders, looking to capitalize on similarities and resolving differences.

• Step 1: Identify the stakeholders.
  Stakeholders can be internal or external. Internal stakeholders are the people directly involved in the functioning of your project. They include project managers, performing organizations, and project team members. External stakeholders are outside your organization. External stakeholders for your project may include sponsors, customers, suppliers, financial backers, special interest groups, the media and the public.
  

• Step 2: Identify their roles.
  You can enhance the usefulness of your list of stakeholders by determining the role each stakeholder plays in your project. Stakeholders may manage the project, provide financial or human resources, or provide supplies. Viewing stakeholders within the context of their roles is necessary to accomplish the rest of your stakeholder analysis.
  

• Step 3: Identify their primary interests.
  Once you know the roles of stakeholders, you can discover the interests they have. The interests of your stakeholders are the outcome of the roles they play in your project. The logical conclusion of what stakeholders do for your project is what they want from your project. It is important for you to know what they want from your project.
  

• Step 4: Analyze the relationships between stakeholders.
  Evaluating conflicting project desires is part of the fourth step of a stakeholder analysis. Once you have listed the stakeholders, their roles and interests, you can analyze the relationship between all the diverse interests in your project.
  

To properly analyze your stakeholders, you need to ask yourself:

1. How will each group respond to project decisions?
2. What effect will their reactions have?
3. How will their interaction with each other affect the project?

LUXX Corporation, an appliance manufacturer, is creating a new toaster for the market. Jodi is in charge of the project. She must determine how to prioritize the four departments' wishes, while demonstrating that she has taken everyone's requests into consideration. Jodi has identified the stakeholders and their competing interests in this project.

The research and development department wants more time to come up with the best toaster possible. It also wants to use its capabilities to the fullest by providing as many features as possible.

The marketing department wants to make this toaster attractive to the general public. This means promoting as many features as possible and having an early market release date, while keeping the price to a minimum.

The accounting department wants to keep costs low while charging the public as much as possible. It also wants this toaster to be on the market as soon as possible. Driving these desires is the interest in the margin of profit.

The quality assurance department wants a trouble-free toaster. The quality assurance department wants well-designed features, that work well, and plenty of time to complete proper testing procedures.

As you can see, many of these wishes conflict with one another.

The steps involved in stakeholder analysis are designed to reveal the conflicting interests among stakeholders so that these differences may be managed. Ultimately, stakeholder analysis helps you to gain the support of all your stakeholders and ensures that everyone involved in a project is directed toward the same project goals.

Structuring Organizations for Better Project Management

If you change the molecular structure of an organism, you change the way that organism functions. Every element of change brings about a subsequent change of function. Like an organism, your organization can and should be structured to enable you to better respond to project requirements.

Changing the structure of an organization is a relatively new phenomenon. Historically, an organization was structured along a pyramid model. This traditional form of organizational structure, called a "functional" structure, leaves the authority and decision-making in the hands of a select few. However, as the pyramid widens and the number of people increases, the effectiveness of those in authority decreases.

Most businesses now tend to focus on individual projects. If your company focuses on projects but uses a functional structure, your projects will be forced to wait in line for decisions that need to be made.

• Functional structures reduce project efficiencies because:
• decisions take too much time to go through the hierarchy
• decisions are made by people not familiar with the project

those involved in the project become frustrated by those assuming all of the responsibility.
Fortunately, organizational structures have changed to meet the new challenges of business. Two different structures that have evolved are the matrix and projectized structures.

• Matrix structures - Matrix structures are divided into two categories: weak and strong. The weak matrix structure provides relatively little authority for the project manager, while the strong matrix provides almost complete authority for the project manager.
  
  A weak matrix structure allows a project to exist apart from the main organization. It retains its own structure but still relies on the organization for some of the decision making.
  
  A strong matrix has its own structure apart from the main organization. The decision-making ability is quite strong within this structure, but it is still answerable to the larger organization.
  

• Projectized structures - The projectized structure is similar to the strong matrix structure. While the strong matrix allows very strong decision-making abilities for the project manager, the projectized structure allows for complete decision making on the part of those involved in the project. For both of these structures, the organization plays an auxiliary role to the project. This change in project authority and responsibility allows for projects to run more smoothly. This in turn, brings a faster turnaround time.

How do you decide which structure is right for your project? Complexity, duration, and outside influence on your project are the three factors which determine the type of structure your project should have.

You need a strong matrix or projectized structure if your project:

• is extremely complex
• is long in duration
• involves many different organizations.

The effectiveness of these structures is dependent on senior management. Matrix and projectized structures can only succeed if the larger organization lets go of control. Authority and independence are needed for these new structures to have validity. The benefits of these structures must be clear to the larger organization for them to relinquish power over individual projects.

Changing from functional structures to new structures calls for a change in both the main organization and the project team. Senior management must learn to give up control, just as the project team needs to learn to take it on. All of this change requires new competencies within the project team. Each team must be able to handle all of the functions usually accomplished by the larger company.

A project team must learn to equip itself before it gains independence. To function, the team must ensure that it is able to:

• communicate
• sell ideas
• negotiate
• problem solve
• resolve conflicts across functional boundaries.

Requiring these competencies of a project team is a huge departure from the past. More is expected from individual members of a team, and more responsibility is placed upon them. This creates dynamic and skilled people. It also creates some new challenges for the project team.
Human beings are incredibly adept at adjusting to new situations and new demands. This adjustment does, however, take time. The same is true of new organizational structures and the new processes they create. The new challenges faced by project teams require an adjustment period and a clear understanding of how the roles have changed.

The four areas that provide the most challenge within the project team are ownership, commitment, authority, and process orientation. Some of these challenges for the project team are due to the limitations of the larger organization, while others rest within the project team itself.

Responsibility for a project calls for ownership of that project. When companies move toward a new structure, they must make the transition of assigning a process owner. They need a manager with responsibility over the process from beginning to end.

The challenge of commitment is found within the project team itself. This is particularly an issue if the project involves contract workers. The project manager must ensure that employees realize their unique role in the success of a project.

Formal statements from the project champion or customer are necessary. These state who has the authority and responsibility for the project and should be distributed to stakeholders, resource managers, and especially the contracted team members.

New structures require new processes. Turning from functional to process-oriented structures requires new work habits, skill sets, meeting formats, reporting structures, problem resolution methods, and other tools to make a project truly effective.

The changing face of business has required dramatic changes in how organizations structure themselves. These changes have brought about a greater sense of responsibility within project teams and the acquisition of competencies formerly only found within the larger organization. Acquiring new competency requirements also presents new challenges for organizations. Meeting these challenges, however, enables a company to be more efficient, to save time, and to gain expertise.

Incorporating Policies, Procedures, and Regulations

Safety nets ensure that the work environment is secure. Human resource practices work as a safety net to ensure that the employment practices you use in forming a project team are above board.

You can ensure that the integrity of your project is beyond reproach by following the policies and guidelines set by your company, your industry, and the government.

Organizations have a variety of policies, procedures, and regulations that help the project management team with various aspects of organizational planning. These human resource practices give guidance on planning team benefits, incorporating company initiatives, and following government stipulations.

The sources of influence which govern employment practices can be divided into internal sources and external sources. Internal sources are policies set forth by the organization. External sources are decisions made outside of the company which affect company policy. Together, these internal and external sources make up the policies, procedures, and regulations governing your project.

• Company policies - include information addressing issues like vacation time, maternity leave, sick leave, and medical benefits.
• Regulations - deal with safety standards, minimum wage laws, and hiring discrimination.
• Procedures - vary from company to company. Your company chooses procedures based on what works best in its industry and what has proven to provide a sense of continuity and balance.

Corporate policies and procedures are at the discretion of individual companies. These are based on what each company deems fair and what it finds produces the most productive and loyal employees. On the other hand, the laws set forth by government are unwavering standards which must be met by each and every company. While project managers should abide by the human resource practices of the organizations in which they work, the laws set by government are binding and aren't optional.

The government has placed regulations upon different industries for the benefit of the public, as well as for those who work in these industries. The regulations differ for each industry, and you should become aware of how they affect your project.

Complying with company policies, regulations, and procedures will help to ensure project success. As you build and develop your project team, remember to:

• follow organizational procedures when assigning new jobs
• ensure the same level of project information gets to all team members
• provide similar training for all team members
• ensure senior management approves any guarantee made to an employee about future roles or positions
• inform team members why they were selected.

Company policies, regulations, and procedures are the safety nets that guide you to make sound decisions when it comes to planning the human resource aspect of your project. When you follow your company's human resource practices you stand a better chance of keeping your team members happy, the government satisfied, and your organization running smoothly.

Using Templates from Past Projects

Who was your role model when you were a child? Do you remember someone you used to emulate? Did you want to be like them? Did you try to copy that person's behavior to get the same results?

Templates for organizational planning work the same way. You can model your project according to similar successful projects from the past.

Using the successful elements of a former project will save you both time and money.

Although the details of each project are unique, the basic components are often similar. This helps you in your planning. For example, you can use the role and responsibility definitions, or reporting relationships, of a similar project to expedite the organizational planning process.

Peter, the project manager for a large insurance company, is preparing a responsibility chart for his team members. How does he decide how to do this? One effective method is to see how responsibility has been distributed in the past. Peter can do this by using the responsibility charts of other successful departments in his organization, or he can copy those of another successful company. Either way he chooses, he is using a past template to ensure the success of his project.

You can disassemble past templates and reassemble the plans you need for your own project. Possible plans you can use for your own project include:

• organizational structure
• Work Breakdown Structure
• company policies and practices

IRT is a successful IT consulting company. One of the services it offers is a Software Development Life Cycle Methodology. Within that methodology are predefined roles and responsibilities and organization charts. Before starting a project, the team members at IRT use their company's model as a starting point. By doing this, they are using templates of organizational structure and work breakdown structure. The team modifies its own template to suit its clients' needs, while building upon past success.

As a project manager, you will want to use templates to guide your organizational planning. Building on the success of others is a sure way of steering you toward your desired goal.

Identifying Project Constraints

Everyone has constraints on decision-making and action. During project organizational planning, there are many constraints to consider. Some of the most common constraints on decision-making are the organizational structure, collective bargaining agreements, the preferences of the project management team, and expected staff assignments.

Organizational structure
Organizational structure can be a constraint. The level of authority given to a project manager is largely dependent on the organizational structure, which may be functional, matrix, or fully projectized.

• Functional structure - In a functional structure, personnel are grouped hierarchically by speciality.
• Matrix structure - In a matrix structure, project managers share responsibility with functional managers.
• Fully projectized structure - In a fully projectized structure, project managers have total authority.

Collective bargaining agreements
Collective bargaining agreements are another potential constraint. Written agreements with unions or other employee groups ensure that you don't ask anything of your team that goes beyond what the union has agreed is appropriate. For example, a union may require that certain employees be hired, or it may set boundaries concerning work done by members of the union. Union contracts may also limit work hours and travel and time away from an employee's designated job.

The preferences of the project management team
Team preferences may also be a constraint. A team may be used to functioning independently, and individual team members may resist the changes brought about by interdepartmental interaction.

Expected staff assignments
Expected staff assignments are constraints placed on you and your team from the larger organization. When someone above you expects you to use certain people on your team, you then have the constraint of a pre-selected team. A pre-selected team limits a project manager in a variety of ways. Expected staff assignments can hinder a project when tasks are assigned based on criteria other than competency, the required competencies of the project team are changed, and the chemistry of the project team is altered.

It may seem logical that competency should be the overriding factor in team selection. Unfortunately, organizations themselves are under the constraint of staff availability. There may be redundant employees who have not yet been reassigned to a new full-time position. Projects end at different times. If one ends just as yours is beginning, your project is a convenient new placement for these employees.

Overcoming project constraints resulting from organizational structure, collective bargaining agreements, team preferences, and expected staff assignments is possible when you learn to view constraints as a challenge. When you understand the constraints placed on you, you can plan your strategy to take advantage of the human and material resources at your disposal.

Identifying Your Project Staffing Needs

People make or break a project. That's why, as a project manager, it is important to carefully plan your project staffing needs. You need to choose people with the right competencies and personalities if you want your project team to work well together and to be capable of getting the job done.

Selecting the right people for your project begins with a staffing requirement plan. Staffing requirements are created using the project's Work Breakdown Structure (WBS) and Skills Inventory Matrix.

Work Breakdown Structure (WBS)
The first step in determining your staffing requirements is to choose people with the right competencies. The WBS details the competencies you need to complete your project. A WBS is the organization of a project into a group of deliverables that defines the project scope.

Project managers complete all phases of the WBS. These phases are:

• identifying the major work assignments for the project
• breaking down each work assignment into tasks
• matching competencies to tasks.

When it comes to matching competencies to tasks, you need to consider both objective and subjective criteria. Objective criteria may include: technical ability, level of proficiency, project management skills, and previous experience as a leader.
Subjective criteria may include: social skills, opinions of fellow project managers, and opinions of co-workers.

Skills Inventory Matrix
After using the WBS, objective and subjective criteria to select the members of your team, you need to assign tasks based on team member competencies. A Skills Inventory Matrix is ideal for this purpose.

A Skills Inventory Matrix allows you to see all the competencies within the project team. The matrix can be created using a simple table. In the first column on the left, list each team member. In the columns to the right, list the competencies required to complete the project. If an employee has a particular competency, place a checkmark in the table cell corresponding to their name and the competency.

A WBS and a Skills Inventory Matrix help you to determine your staffing needs. These inputs ensure that you know which competencies and people you need, as well as what the time frames are for your project.

To ensure the timely completion of your project, you need to match people to competencies and competencies to tasks. A project manager is more likely to have success when all of these staffing requirements are in place.