Managing Risk to Project Success With Risk Monitoring & Control
Risk Monitoring and Control All the Way Through
Very few project managers create a thorough risk plan. Even those who do often don't use it well enough. Making a risk plan, alone, does not increase the chances of project success. To plot a course through all the risks and guide the project to success requires more. It requires using the risk plan, on at least a weekly basis, to identify risk events that are occurring or are likely to occur. And when we see a risk event coming, we take action to prevent it or mitigate the consequences.
It's just like a sailing ship using weather radar. Having the radar does nothing. Monitoring the radar so we can adjust our course to avoid a storm or trim the sails to ride out the storm ensures success.
Are You Ready To Sail Through the Storm?
Why Ongoing Risk Management is Essential
If we compare our project to a journey in a sailing ship, then delivering our cargo to port is the project scope. We arrive on time by sailing according to schedule, and manage project cost by arriving before we run out of supplies. Managing project risk is like having weather reports and a weather radar, and keeping an eye on coming storms. As we work on the project, that is, during project execution, risk mitigation is like steering around a storm, and risk mitigation is like trimming the sails and riding out the storm.
A ship may run into many storms on a single trip. Just so, a project may run into many risk events. For each event, the sooner we see it coming, the more we can do to either avoid it, or reduce the consequences of the event. The more we do that, the more likely we are to steer clear of, or steer through, the problems. Then we deliver project results on time and within budget, that is, we bring our ship safely home to port.
Preparation, Routine Action, and Contingency Management
The actions in our Risk Response Plan can be divided into three categories:
- Preparation is action we can take early - possibly even in the planning stage - to mitigate risk. This can serve to reduce both the likelihood and the significance of the risk event. In our family vacation example, getting the car tuned up before the trip is preparation that reduces the likelihood of the car breaking down. Making sure our AAA membership is up to date and that we've packed our roadside emergency kit in the trunk are preparations that reduce the significance of the car breaking down, if that risk event does occur. Training everyone in first aid is preparation that reduces the consequences of a hiking injury.
- Routine Action is action taken during the project that mitigates risks. On our vacation, each time we go on a hiking trip, one of the twin boys tells the park ranger which trail we are on, and when we expect to be back.
- Contingency Management is action that might be taken, or might not be taken at all. It will only be done if the risk event occurs. But, if the risk event does occur, then we will use our contingency plan, and take action to manage the event and our project. So, when we are hiking, our little girl falls, twisting her ankle and getting a scrape. No one panics. Mom cleans and bandages the scrape. Dad binds the ankle. The twins make a stretcher and have fun carrying their kid sister back to the ranger's station. The next morning, she's just fine!
Good risk management during the project is a matter of keeping an eye out for risk events, and making sure all three types of action in the risk plan are done right.
Risk Status on the Titanic
Captain Smith of the RMS Titanic had such confidence in his vessel that he said that he could not "imagine any condition which would cause a ship to founder. Modern shipbuilding has gone beyond that" (Wikipedia). He followed the standard practice of going full speed ahead even when icebergs were known to be nearby.
That wasn't really his fault; it was more the arrogance of the day. But what would a more circumspect captain do?
- Mitigation of both likelihood and consequences by slowing down the ship when icebergs were reported. Entering the area where icebergs had been sighted was the trigger event for taking this action.
- Risk monitoring by having the crew keep an eye out for icebergs. (This was done.)
- Change of risk event status when the iceberg was cited. An iceberg on the ship's path is no longer a possibility, it is now a certainty.
- Full reverse, or a change of course to avoid the collision or reduce it's severity is Contingency Management. (This was done, but, given the ship was at full steam, it wasn't enough. If the ship had been traveling a bit slower, it probably would have been enough, if not to prevent the collision, then to prevent the sinking. The Titanic could have stayed afloat with four of its sixteen watertight compartments breached. Only five were breached. It was a close call.)
- If the Titanic had avoided a collision, then, once it was out of the region of the ocean that contained icebergs, the risk event "collision with iceberg" could have had it's status changed to risk avoided.
Risk Evaluation in the Status Meeting
In our weekly project status meeting, we make sure that the preparatory activities and routine actions in the risk management plan are done on schedule. We also watch for trigger events. For example, the trigger event for a car breakdown that would ruin the trip is when we all get in the car to head out to the campground. At that point, to implement our risk plan, we double-check that: the car was tuned up and checked out; we've got the emergency roadside kit in the car; we have a valid AAA card with us. Five extra minutes, and we know we're good to go, and safely on our way.
We also get to check risk events off the list once they can no longer happen. We're all healthy when we get in the car, which means that the two biggest risks: Dad gets sick, and one of the kids get sick didn't happen. It's off the list. Similarly, after our last hike, we can check off that we don't need to worry about anyone getting hurt on a hike any more.
This is simple, obvious stuff if you think about it. It's really common sense. But, often, we're so focused on just getting the work done, or keeping on schedule, or saving money, that we forget that an ounce of prevention is worth a pound of cure. Or, worse, we cut corners, taking risks and just hoping to save time or money, even when we know better.
In project management language, watching out for triggers and changing the status of a risk event when a trigger happens, or when a risk event occurs, or when we are safely through a risk event is called Risk Monitoring. Actually taking the action to manage both the risk event and the project is called Risk Control. When risks are monitored and kept under control, we can keep the project on course, delivering project results as close to on schedule and within budget as we can, given that the risk event did happen.
Risk Management During Crucial Periods of the Project
Some parts of a project are riskier than others. On our vacation, there is greater risk of injury on a hike or at a campfire than at a restaurant or sitting in our cabin. Just the same, some parts of a project are more likely to run into problems, or are on a more critical time schedule, so that, if a problem occurs, it has a larger impact. Here are some examples:
- If one part of the project is doing something innovative that the team has never done before, that is higher risk.
- If we are using new tools, such as an upgrading programming language or a new software operating system or platform, the risk of glitches is greater.
- As we come closer to delivering the final product to the customer, delays are more critical.
- Testing and fixing problems, delivery, and installation are all risky periods.
One of my clients, a Fortune 500 energy utility company, calls the last phase of a project, which includes testing, fixing problems, installation, and training the storm period, because so many problems are likely to come up.
During storm periods, we should manage our risk register and risk plan daily, not weekly. Whether we have daily meetings, or we do it by phone, we should get each team member's full attention, and make sure that everything is being double-checked.
Managing Positive Risk Events
A positive risk event is an unexpected happening (a risk event) that actually reduces project cost or accelerates the schedule. Some of them don't require much management. For example, if we discover an item that we were going to buy has gone down in price, then we buy it, and save the money.
But what if that item is still the same price from the vendor we planned to use, but considerably cheaper from another vendor? Then we have to evaluate the item, to make sure it is identical or at least satisfactory, and also evaluate the vendor, to ensure they are reliable. We may need to check with the procurement department to make sure that we are not locked into a contract with the first vendor, or to add the new vendor. If we manage all of this, we can save the money.
When it comes to accelerating the project schedule, that good news almost always requires some management. For example, one time, I was working on a project installing specialized software for a company about five hours away. I worked mostly from home, and traveled there when they needed me. I had already taken one trip to introduce them to the software solutions. We had a second trip planned for meetings to choose among three different solutions. But, a week before that, their team got together and quickly made the obvious choice for the best package to buy. That put the whole project almost two weeks ahead.
But what to do. I could cancel the trip, but it made more sense to accelerate the schedule. I looked ahead on the plan, and found that I had a trip planned for designing configuration options. I did a bunch of quick research and agenda building, and came at the time for meeting #2, but with the agenda and materials for meeting #3, putting the whole project a full two weeks ahead of schedule.
Without this kind of management, we can't gain the benefits of a positive risk event.
When the Risk Event Occurs
When the risk event occurs, action must be taken to deal with it. At the same time, the project must go on. The best way to understand this is to think of the risk event as a mini-project within the project.
For example, if a passenger on a commercial jetliner has a heart attack, a member of the flight crew will use a defibrillator and take care of the patient. Other crew members take care of the other passengers. And the pilot keeps flying the plane. It would make very little sense for the pilot to leave his cabin to take care of the passenger!
What if you're the project manager, and only you have the expertise to handle the risk event. Then you take charge of the risk event - and turn the routine management of the whole project over to one of your team leaders for a short period of time.
Manage the project and the risk event to ensure successful project completion.
Project Completion: Arriving in Safe Harbor
Most projects do hit some bumps along the way. That is, risk events do occur. If we manage them, and keep the project moving, then we deliver as promised. In informal projects, the customer will usually understand if a big risk event creates some delay or cost overruns. In more formal projects, we include this possibility in the project plan. A contingency fund is extra money to be used only in case of a risk event, and we can also have a contingency schedule with extra time built in. There's even an advanced project management technique where each risk event is rated as due to client action, due to an act of God, or due to the project team's error. Bonuses are given for early delivery, and penalties for late delivery. But the delivery date is adjusted if the client makes a mistake, or if there is an act of God, and the company performing the project is only penalized for its own mistakes.
In any case, on any project, formal or informal, large or small, if you do a good job with Risk Management, odds are that you will deliver success, no matter how many unfortunate events get in the way.
Safe Through the Storm
More by this Author
Most projects fail, and the most common reason is that the goal is not clearly defined. When the goal, or scope of the project, is clearly defined, success becomes possible. Learn how to define project scope and goals...
Many project managers don't know the difference between a Work Breakdown Structure (WBS) and an Activity List. On small projects, it doesn't matter much. But on larger ones, it's crucial to understand the difference,...
"Think win-win" is a simple idea. Many people claim to do it. Few make the real changes in their hearts and truly live win-win. Let's look deeper.
No comments yet.