STEP FOUR
Identify, Rate, and Manage Risks
OVERVIEW
Risk and Risk Management Defined
Risk Assessments and Scenarios
Risk Mitigation and Contingency Planning
Project Constraints
We like to think that we're clairvoyant when it comes to project management. Any truly talented professional (and we all are, of course) should be able to plan and estimate a project accurately. It's our responsibility as project managers to anticipate every possible problem that might come up. After all, we've been managing projects for years, and we've been fairly successful.
Well, the truth is that every project will surprise you and on every project unexpected things will happen. It's irrational to think you can know everything before you know anything (that is, at the beginning). Glitches happen. Think of the last project you were on. What things occurred that you never expected? What impact did they have on your project throughput?
Although you can't anticipate the myriad challenges that will pummel your projects, you can look at the environment the project will start in and make some educated guesses. Doing so helps you begin to identify those “perfect storm” surprises that may occur and enables you to do some contingency planning. In this step you'll learn what risk is. We'll cover techniques for analyzing a project's risk before the project starts and for building plans to counteract problems that pop up. We'll also ask the stakeholders to define the constraints of the project—in other words, rank the importance of timeline, budget, quality, and scope. These constraints give us clues to what might be the most detrimental risks. For example, if a project has a limited budget, running out of money will be a very serious risk.
While Speedy
collected the perfect sticks to outfit his new band, he felt worry creeping up on him. Maybe he had underestimated the wolf, as his brother had said. Maybe the stick strategy wouldn't work.
“Phooey,” he said, pushing out the worries. “It's a good bet that BB Wolf has moved on to other towns by now, and that this whole building project is a complete waste of time.” And he turned again to his musical stick search.
Goldy, too, was taking another look at his building plan. He'd used the bits of paper, the tin can, the dead branch and its crispy leaves, but when he'd wiggled the cardboard into position, the whole house had collapsed! Goldy was getting very irritated with the whole project, and he let loose a great sigh. Then he started again—building the same structure with the same materials. Tired and dispirited, he lost track of time and almost completely forgot why he was doing this work.
In town, the library lights were on. Demmy realized that it would be dark in less than an hour and he still needed to buy some bricks and get to building before night fell. Lost in his research, he really hadn't left himself enough time. He ran to the store and made a fast purchase. But, standing beside the stacks of baked clay, he had no idea how he was going to get all those bricks back to the site. He had a little money left and he bought a wagon, knowing it would take a long time to drag that loaded wagon back to the clearing. Slowly moving up the road away from town, Demmy thought about his troubles—his fear that the wolf might show up at any moment, his fear that the bricks wouldn't be strong enough to stop the wolf, and his fear for the safety of his two brothers.
There is a psychological advantage to thinking about risks and constraints before the project starts. Remember, it's much easier to react to a project glitch when you've already thought out how to handle it. Surprises, especially bad ones, get our attention too late because we really don't want to see them.
What Are Risk and Risk Management?
A project risk is an uncertain event that can affect the timing and completion of project objectives. A risk can occur at any time in the project; and when it occurs, it can alter the business objectives, the project objectives, the scope, and development work that's already completed.
Consider our blog project. There's a risk that creating the Frequently Asked Questions area might require help from subject-matter experts who aren't available when the developer needs them. If that happens, the project will be delivered later than expected. By identifying this risk up front, the project manager can clarify with sponsors and other stakeholders that making those experts available when the project schedule demands their help will be critical to on time completion. That's risk management.
Risk management is not about controlling or eliminating risk. It's about anticipating it and planning ways to manage it without destroying the project. The process of risk management comprises the five steps shown in figure 4.1.
FIGURE 4.1
Five-Step Process for Managing Risk
Notice that the first four steps—identify, analyze, prioritize, and plan—happen during the Define phase of project management, which is at the very beginning of a project (refer to figure 1.2). But it's likely that some risks will not be discovered at the start, so a successful project manager stays on the lookout for new risk factors—which is the last step, monitoring. Here's what happens in the five steps:
1. Risk identification happens during the initial project brainstorming and question-asking sessions. It involves defining potential problems in general terms.
2. Risk analysis involves uncovering enough of the details regarding a risk to be able to determine its impact on the project and the likelihood that the risk will occur.
3. Risk prioritization is a process to rank potential problems according to their potential impact and the probability of their occurring.
4. Risk planning defines both proactive and reactive project activities either to avoid (best case) or to mitigate (worst case) possible problems.
5. Risk monitoring reinforces the importance of always looking for additional risks that have not been identified, no matter what phase of the project you're in. Actually, this is psychologically pretty tough—no one wants to see a risk; and the closer the project comes to the end, the less a project manager wants to find out about a new risk.
Good risk management brings with it the following benefits:
It minimizes “management by crisis.”
It anticipates risk as early as possible in the project.
It helps a project manager determine how much time to spend planning, organizing, and controlling the project. The higher the risk, the more time is spent on project management, and the more formal the communication with the stakeholders becomes.
It contributes to a shared project vision.
It keeps the project focused on the business objectives.
In this step, you first identify the overall risk of the project as a whole. This quick-and-dirty risk assessment will help you weigh how important risk management is for your project. Obviously, a project that presents a lower level of risk doesn't need as much contingency planning as does a high-risk project.
After identifying the overall risk, you'll identify, analyze, prioritize, and plan what to do about individual risks. As you get consensus from the stakeholders about the project constraints (time, cost, quality, and scope), you'll begin to see which risks are the most important. Finally, you'll plan to monitor risk throughout the project.
Time to Complete This Step
Documenting risk is not time consuming (an hour should be fine), but brainstorming effectively does require some time away from constant interruptions. Ask the needed questions of the stakeholders, and then dedicate at least a couple of hours with your team to think creatively about what could go wrong and how you might address those things.
POINTER
Risk management is a continuous activity. Although the process begins at the earliest point of project planning, risk itself can occur at any time. A good project manager knows how to watch for risk and act swiftly to mitigate it to keep it from undoing all the good project work that has been done.
Stakeholders
In the ideal situation, all stakeholders are involved in the discussion of risk and constraints facilitated by and including you as the project manager. More likely, you'll do the analysis yourself and share it with the stakeholders for their feedback. Be warned that risk is not something people like to think about. It's natural to want to start a new project with total optimism. The last thing the stakeholders want to talk about is what might happen to damage their project and their reputation. Continue to persuade them by stressing the proactive importance of risk identification.
It's highly unlikely that the stakeholders will identify the risks clearly for you. Instead, you'll take what you've learned from them and identify the risks by using
your brain, creativity, and intuition/inner voice
business objectives
project objectives
project scope
budget
known and unknown business requirements
schedule and deadlines
lessons learned in past projects.
Questions to Ask
The best asset you have in managing risk on a project is your intuition. Given enough focus, a project manager can learn to trust that inner voice that tries desperately to get attention. I've grown aware of how my intuition wakes up quickly while I'm talking to a project stakeholder. I don't always take the time to listen right then, but at least I've started to notice. After many projects, I'm convinced it's not the knowns but the unknowns that cause projects to fail.
TOOL 4.1
Questions Concerning Project Risk
| 1. | What have I heard people say that my intuition tells me implies future problems? |
| 2. | What has surprised me in the past on projects similar to this one? |
| 3. | What are some of the challenges I've had in the past working with these stakeholders? |
| 4. | Is there organizational friction between the functional areas that will make it difficult to reach consensus among the stakeholders? |
| 5. | Considering the following factors, what can I imagine might happen to stall the project? People—stakeholders, vendors, project team, me Process, standards Technology Incentive, measurements Politics, organizational changes Training Shared resources Funding, budget Scope The economy—local, national, global |
At this point in your project, whether it's business or personal, ask yourself, what are some of the things that might happen to mess this up? These are the project risks. Tool 4.1 offers some questions you can ask yourself and your stakeholders.
In addition to identifying the possible risks, it's important to get consensus around the priorities of the project. As project manager, your job is to deliver the preestablished project objectives (as you read in Step 3) regarding
the time the project will take
the budget
the quality of the project deliverables
the scope.
These four factors are called the constraints of the project, and you will learn how to document them in a matrix toward the end of this step.
Project Manager's Toolkit: Handling Risk and Constraints
After you've collected the answers to your questions, you're ready to
quantify the risk inherent in the project—the likelihood of failure—by identifying the areas of weakness
create proactive and reactive contingency plans for high-impact glitches
prepare a graphic to show the prioritization of constraints at the start of the project so you can communicate effectively when these priorities change during the project.
Here are some of the advantages of the tools and activities discussed below:
The quick-and-dirty risk assessment takes only five minutes to discover how risky your pending project really is; how well the stakeholders understand the risks; and how much time you'll need to commit specifically to organizing, managing, and controlling the project.
The risk management process, including the risk scenario you'll draft, helps stakeholders and project team members adopt realistic expectations about a project before it starts. It takes off the blinders and makes the inevitable glitches and occasional serious problems more psychologically acceptable. This keeps the project from spinning out of control from surprise and denial.
The constraints matrix you'll construct helps you identify what options you have when the project doesn't go as planned. It keeps you from trying to negotiate project factors on which the sponsor is unwilling to budge. It also helps the stakeholders get some clarity around how they'll measure the success of their project, given the constraints it faces. Worksheet 4.1 uses three project factors as risk criteria to assess the principal areas of risk in a project—size, structure, and technology. Stakeholders, project team members, and the project manager rate each criterion relative to other projects he or she has been associated with in the past. For example, if I'm part of the blog project team and I have no idea what a blog is, I'm going to see the technology question as an area of greater risk than is someone who's worked with blogs a great deal.
WORKSHEET 4.1
Quick-and-Dirty Risk Assessment
Instructions: Use these three ratings to think about this unique project. Rate each risk relative to the project team's experience, not the company's experience. For example, if the project will use an older technology, such as PowerPoint software, but the project team members have never used PowerPoint, the applicable technology would be rated as a higher risk. When each of the three ratings is complete, average them by adding the three criteria scores and dividing by 3. That average is your project's risk assessment score.
Risk Criterion 1:
Project Size: How “big” is this project or how long will it take?
Risk Criterion 2:
Project Structure: Considering the following reasons why project requirements are or may become less stable, how stable are your project's requirements?
There are no available subject-matter experts.
Project requirements are tied to a government regulation that is changing or hasn't been defined fully.
The project involves stakeholders and subject-matter experts with completely different opinions about the requirements. The more stakeholders there are or the more they argue, the more difficult it will be to define the requirements.
Risk Criterion 3:
Applicable Technology: How well does the project team understand the technology?
The first criterion, size, specifies how extensive the project is in terms of the quantity and size of its deliverables and the length of time it will take. Remember, responses should be relative to earlier projects. Think about the amount of work involved when you rate this. Large, lengthy projects create risk factors that smaller projects do not—for example, staff turnover, communication difficulties arising from the great number of stakeholders, and budget amounts that are difficult to manage.
The second criterion, structure, focuses on the number of stakeholders and the delineation of specifications. The greater the number of stakeholders and/or the less certain and stable the specifications, the higher the risk of unclear requirements. For example, during the implementation of an enterprise-wide software system, the project manager will get requirements from executives responsible for every functional area. It's very normal for the different functional leaders to disagree on project priorities. In smaller projects completed within one business area, it's less likely that the requirements will be so confused by disagreement.
The third risk criterion, technology, is evaluated by rating the project team's familiarity with and ability to use the pertinent technology. We've all been victims of new technology. It's hard to estimate how long it will take to become proficient in the technology, and it's possible that the features of the technology may differ from what was advertised or contracted.
The most effective way to use this worksheet is to have all the responders individually rate the three risk factors and average their three scores. If the worksheet is used at a group meeting, ask each participant to share her or his score with the group. Interesting conversations come from the stakeholders interpreting the three questions differently. Facilitate this discussion until the group is able to agree on a rank for each criterion. It is important that all people involved start the project with the same perception of risk for the project.
Here are some things to talk about with the stakeholders as you discuss their quick-and-dirty worksheet scores:
If the project comes out with an overall score of 3 or less, it's probably OK to wing it. Some projects just don't need a lot of attention.
If the project comes out greater than 5, you as project manager will need to hold time periodically to think about your project. When the risk is lower, it probably isn't necessary to schedule “thinking,” but for higher-risk projects you tend to get too busy to step back from the details and look at the big picture.
If the risk consensus is 9 or 10, the project is in big trouble. It's highly unlikely that the project will be successful. Look for ways to break the large project into smaller ones that will isolate risks and be easier to manage.
As a project manager, you learn a great deal from this overall risk score. This number will help you define the amount of time you'll need to dedicate to managing the project, especially if you're both the project manager and the entire team. The higher this number, the more time you'll spend on managing activities because higher-risk projects will require more communication, negotiation, conflict resolution, and politicking to work around and through the glitches. Tool 4.2 will help you anticipate and allocate the needed management time that the quick-and-dirty assessment suggests.
POINTER
A quick-and-dirty risk assessment is a deceptively simple but quite powerful activity. Here's what you'll gain from doing this assessment with your stakeholders:
a shared understanding of the risk factors to watch for
a shared appreciation for the complexity of all the project work, not just the portion to which each stakeholder attends
an opening of minds to the possibility of surprises.
TOOL 4.2
Amount of Time Needed for Project Management, Based on Anticipated Risks
| Quick-and-Dirty Overall Risk Score | Management Time |
| 1-4 | 10 percent of the time you spend on the project each week (for example, 4 hours if you spend 40 hours a week on the activities of this project) |
| 5-7 | 15 percent of the time you spend on the project each week |
| 8-9 | 2 hours a day |
| 10 | 25 percent of the time you spend on the project each day (for example, 2 hours in an 8-hour day spent on the project) |
If the assessed risk of your project is 5 or greater, continue to the next item in this toolkit—the risk scenarios. (There are some people who recommend building risk scenarios regardless of the score, but you can decide when further analysis is merited. Trust your intuition.)
Remember that this number represents a point in time. If any of these three factors change as the project progresses, reintroduce the worksheet to stimulate another stakeholder discussion about why the numbers are no longer accurate and what you can do about it.
Don't be tempted to compare the quick-and-dirty risk numbers to those of other projects, especially with different teams and stakeholders. Risk scores on your project reflect the assessments of the people involved with your project. The assessment pertains to your stakeholders as the situation exists at the moment, and it's useful only for prioritizing the work of the project for which it was done.
Risk Scenarios
One way to facilitate thinking about risk is to gather a group of people to tell stories. These stories are brief descriptions of situations that could occur in the future and would hinder the project. By sharing these stories, called risk scenarios, you essentially complete the first two steps of the risk management process: identify and analyze.
Identifying Risks
Using answers to the questions at the beginning of this step, you're ready to tell a story to identify and thoroughly describe each risk by documenting
1. how the risk will affect the success of the project
2. how the risk will affect the business.
Here's an example of a risk scenario from the blog project:
What would happen if the chief information officer (CIO), who is the sponsor of this project, was replaced in the middle of the project with a new CIO? We think that the project would come suddenly to a halt. Our current CIO sees this project as a strategic imperative to improving the effectiveness of the information technology area, but a new CIO might want to move in a completely different direction.
The risk identified through this scenario is the risk that the CIO will leave in the middle of the project. The story adds the details to make the experience real to the people discussing it.
Analyzing Risks
Risk analysis is the process of dissecting potential risks, analyzing their probability in a given set of circumstances, and envisioning their impact. In this step, you'll take each scenario, drill down into the specifics of the problem, and then determine the impact on the project and the probability that this risk will occur. “Impact” here means how detrimental to the success of the project the risk would be if it were to occur. For example, the risk of the CIO leaving could stop the project in its tracks, so it would be rated as high impact. The risk of a project team member missing a lot of work might have less of an impact and so be rated low or medium, especially if the project manager plans for cross-training.
In general terms, a low-impact risk will negatively affect cost, schedule, and quality by 5-10 percent; a medium-impact risk will negatively affect those factors by 10-15 percent; and a high-impact risk will produce upward of a 20 percent negative change in those factors.
Next, ask the stakeholders to help you judge the probability that a risk will occur. A low probability means that stakeholders believe the risk has less than a 25 percent chance of occurring. Medium probability means that the risk has a 25-60 percent chance of happening. High-probability risks are likely to occur in at least 60 percent of cases. Again, using our scenario example, the question would be, How likely do you think it is that the CIO will be replaced? If it's 60 percent or more likely, it's a high-probability risk.
Prioritizing Risks
Tool 4.3 shows you how to use a risk's assessed impact and probability levels (determined in the last section) to prioritize the risks of your project, which will help you communicate to your stakeholders the additional time and resources you'll need to handle these potential risks. Obviously, prioritizing is a more time-consuming process than simply listing the possible risks, but prioritization is the key to effective risk management. In larger projects, there is only enough time to deal with the most serious risks. Even in smaller projects, project managers have to balance the time it takes to avoid risks with the cost of adding this overhead to the project.
Please notice that although the impact and probability analyses use numbers, the project manager and stakeholders really are making educated guesses, not statistical choices. These numbers can't be compared with the numbers for another project—it would make no sense. The ratings of high, medium, and low for impact and probability help rank risks within a project but do not apply when prioritizing risks across different projects.
Planning for Risks
Not only does tool 4.3 show the priorities of the risks by ranking their impact and probability, but it also recommends three appropriate? actions for different urgency/probability combinations—monitoring the risk, making contingency plans, and mitigating the risk.
TOOL 4.3
Prioritizing Risks
Monitor: Keep an eye on the risk, but don't build any plans for contingency
Contingency: Build high-level contingency plans to implement if the risk occurs
Mitigate: Build plans to avoid and react to the risk
When you make contingency plans, you monitor more frequently and add tasks to your project schedule to take proactive action to avoid the risk. In mitigating a risk, you build detailed plans to avoid the risk or soften its impact.
In the tool, notice that the low-impact risks demand the least attention, and high-impact risks require the most. The middle ground is interesting: a high-probability/low-impact risk has a slightly higher priority than other low-impact risks, primarily because it's more likely to occur.
At this point it's time to build a risk mitigation plan for the risks that fall into the contingency planning and mitigation planning areas of tool 4.3. For contingency planning, document obvious steps you can take to avoid the risk (these are tasks you will add to your project plan in Step 6) and high-level actions to take if the risk occurs. For risks that must be mitigated, document detailed steps to avoid the risk, if possible, and detailed plans for addressing the risk if it occurs. Both will add tasks to your project plan in Step 6
POINTER
The Mystery of probability
Academically, risk assessment treats impact and probability as relative equals when prioritizing risks and planning mitigation. With my experience, I weigh impact higher than probability. In fact, I've been burned on projects when I convinced myself that the probability was low and stopped monitoring.
Example 4.1 presents sample plans for mitigating risks associated with our blog project. Here are some additional issues to watch out for as you apply risk management to your project:
People don't like to sit around at the beginning of a project and imagine all the things that might go wrong. Most prefer to stay in project nirvana, at least until the project starts. Facilitate the difficult conversations and don't let the stakeholders avoid them.
Each contingency plan adds tasks (costs, time) to your project. Spending project time on risks that don't need detailed mitigation planning is bad for your project. It's possible to overdo risk management and take away valuable time from the project's implementation.
This is not an academic exercise. Whatever mitigation tasks you document also will appear in your project plan for high-impact/high-probability risks.
Monitoring Risks
Once the project moves into the Manage phase, a project manger uses the risk prioritization matrix and risk tasks in the project schedule to monitor the project risk. If new project risks occur, the project manager revisits the risk analysis, definition, prioritization, and management steps above.
EXAMPLE 4.1
Blog Project Risk Mitigation Plans
| Risk Factor | Avoid Risk | React to Risk |
| Project sponsor leaves the company | Communicate with other executives who might become the project sponsor | Meet with the new project sponsor and review the work done in Steps 2 and 3 |
| Project is cancelled | Keep the project focused on the return-on-investment/business case, and communicate it to all stakeholders | Carefully document the ending, put all pertinent materials in a box, and move on |
| The technology doesn't work as planned | Investigate alternative technologies; choose technology that is more familiar to us | Be prepared to use less-risky technology if necessary; reduce the complexity of the software features needed |
Constraints
Tool 4.4 presents questions to ask the stakeholders to discover their priorities relative to possible future problems. The questions will help you identify, at a macro level, the project's current constraints. This will help you communicate more effectively when project priorities change. The risks are things that you do not want to have happen. The project constraints are the factors that you do want the project to deliver to be successful. For example, one of the constraints of a project could be its completion date—it has to be finished by the end of the year because of a pending government regulation. Time is an important project constraint in that case. One of the highest-impact risks on such a project naturally would be something that put the project behind schedule.
Identifying the project constraints after the risk mitigation plans have been constructed provides an audit to make sure that nothing has been missed. It's a fairly difficult conversation for stakeholders to agree to the constraints of the project, and after getting through the risks there should be enough trust to get to consensus.
TOOL 4.4
Questions Concerning the Project Constraints
| 1. | If the project was struggling, how much more time could we get? |
| 2. | If the project was struggling, how much more money would be available? |
| 3. | If the project was struggling, what project objectives could be delayed until a future release? |
| 4. | What would be the impact if we delivered the project with less-than-perfect quality? |
Worksheet 4.2 shows a blank matrix you can use to communicate the constraints of a project. Ask each stakeholder to indicate the most important constraint of the project by drawing an “X” in the column marked #1. The questions in tool 4.4 help you gain insight to the real constraints of the project. Using our example of the project time constrained by pending government regulations, one way to test that time is really the #1 priority is to request an extension on the deadline. If the deadline can be moved, then time is not the #1 priority.
Here's the rule: There can only be one “X” in each column and row—in other words, no two factors can have the same priority. It's possible, however, for #1 and #2 to be extremely close together and practically not negotiable.
Consider the U.S. project to put a man on the moon by the end of the 1960s. What was the #1 constraint of that project? Many people would say time because there was extreme social and political pressure to beat the Soviets to the moon. By putting time as #1, quality must move down to either #2 or #3. Clearly, the goals of the project wouldn't be met if the astronauts didn't survive because quality was sacrificed in the service of time. Here's how the moon project was prioritized:
#1 quality (bring the astronauts back alive)
#2 time (beat the Soviets)
#3 cost (whatever it takes).
Let's return to the government regulation project. Imagine that two different areas of the company are involved in financing this project. One of the areas needs the project done in time to meet the government regulation, but the other needs the project done to roll out an important new product on the market. One project-customer rates time #1, but the other rates quality #1. It's unlikely that the project will successfully satisfy either stakeholder if this core difference cannot be resolved early on.
Example 4.2 shows the constraints of our blog project. Time is #1, followed in order by cost and quality. At first glance this seems inappropriate. The marketing vice president is anxious to get help for the customers, so time is most important. There is a limited budget for this, and that's why the company wants to leverage free software services (Google Blog). Because the blog faces the customer, quality has to be important, so why would a business knowingly invest in a project with the plan to neglect quality as a way of finishing inexpensively and on time? This is where scope comes in.
If a project has limited funds and needs to be done fairly quickly to get market share, as the blog project does, there are only two choices of mitigating action to take when a risk threatens to drive up the cost or slow down the project: (1) no changes are made to the project size (that is, its scope) and the project is implemented poorly (with bad quality) or (2) the scope is reduced so that a smaller version of the project can be delivered at an acceptable level of quality. That's why scope and quality are combined as the third category in the constraints matrix.
WORKSHEET 4.2
Constraint Priorities
EXAMPLE 4.2
Blog Project Constraints
The important point is that the matrix shows that scope is an important negotiation element for a project manager. When time and cost are threatened, as often happens, a project manager must negotiate scope or the quality will suffer through neglect. You documented scope and secured stakeholder consensus in Step 3 because you can't negotiate scope as a risk management strategy if the stakeholders haven't agreed already to your depiction of scope.
Try filling out worksheet 4.2 for one of your projects. Remember—only one #1, one #2, and one #3 priority. Keep these options in mind when you raise the following questions with your stakeholders:
If I'm running out of time, would I be able to get more time? If not, would I be more likely to get more resources or to have to narrow the scope?
If I've run out of money, would I be able to get more? If not, would I be more likely to get additional time or to have to cut the scope?
If I realize that the scope of the project is too large to finish on time and within budget, can I get more resources or time? Will I be able to reduce the scope and deliver a smaller amount of the project on time and within budget?
As the project progresses, here are two situations to watch for:
Constraint #3 often becomes #1 because it's been neglected and has gotten out of control. Suddenly, it becomes the conflict point. For example, if scope is #3 in our blog project, somewhere down the road the marketing VP will start screaming about the lack of functionality being provided for the money. The original matrix can be used to remind the VP of why the compromises were made. If the priorities do need to change, create a changed matrix to go forward.
Priorities change. Because the constraints matrix is a living document, it's important that you update the priorities when they change and make sure that all stakeholders agree to the new order.
Given your project challenges, as project manager you have three things to negotiate with the project sponsor as risks occur: time, cost, and scope. You'll negotiate these elements throughout the life of the project. The priorities will change over time, especially as deadlines approach and budgets are tapped. Scope is often the only factor that you reasonably can negotiate and still have the project be successful.
Communication
Again, the sole purpose for doing the quick-and-dirty risk assessment, developing a risk scenario, making plans to monitor or manage risks, and prioritizing constraints is to communicate. Risks and constraints change as projects proceed, so use those tools to build ongoing communication with the stakeholders. The risk plans will help you react quickly to problems and will enable you to tell the stakeholders what has occurred and what you intend to do about it The constraint matrix will help you communicate with the sponsors when the priorities of the project seem to have changed.
When a change does occur, everybody will know that it has, and the owners of the project (the sponsors) can reach agreement about the best course of action. In Step 7, you'll learn how to manage and negotiate project change.
What If I Skip This Step?
Don't. The activities in this step take very little time and will have a huge effect on how you prepare your project plan estimates and tasks. If you don't do your risk analysis and management planning now, you will spend more time dealing with problems when the project is in progress.
Take the time to anticipate and prepare for risk and to communicate with everyone connected to the project exactly how profound the risks may be and specifically what plans you've made to manage problems that may arise. At the end it is the stakeholders who will judge the success of the project. The more information you communicate in the run-up to the project, the more likely they are to be happy when the project is complete.
Lurking Landmines
Different stakeholders prioritize constraints differently. It's highly unlikely that all stakeholders will be happy at the end. They come from different areas inside and outside the organization, and each wants something that fully satisfies his or her own priorities. The key to producing outcomes that everyone finds successful is in building consensus and trust among stakeholders and sponsors. Making space and opportunity for everyone to discuss risks together creates a shared choice of the appropriate actions to take and acceptable trade-offs to make if/when specific problems arise. Moving the discussion up the line to a project sponsor may be necessary when stakeholder agreement is out of reach. Don't delay that movement.
The sponsor may want it all—every aspect of the project scope, on time, within budget, and at top quality. Don't agree to fantasy, and don't take no for an answer when you ask a sponsor to agree to some reasonable concessions to save a project. Instead of asking the sponsor to pick an aspect to sacrifice—time, budget, or scope/quality—ask questions that prompt the sponsor to describe what he or she really would do if the project began to struggle for one reason or another. Help the sponsor hear his or her own priorities revealed in those answers.
Step 4 Checklist
Identify the overall risk of the project.
Describe the likely high-impact risk scenarios and build proactive and reactive mitigation strategies.
Identify the order in which your stakeholders and sponsors prioritize the project's constraints.
Create a habit of consensus and communication with the stakeholders.
The Next Step
In the next step we'll discuss how to influence the most unpredictable factor in any project—the people involved. You'll learn how to identify and adapt to people's unique communication styles and their diverse motivations. Essentially, you'll learn how to lead a project and how to manage its politics.
