Managing Project Risks in Four Simple Steps

What are project risks, and why do we manage them? In simple terms, a project risk is one answer to the question, “What could go wrong?” If you can anticipate potential problems that would impact your project’s quality, budget or schedule, taking steps to prevent them makes a lot of sense. Additionally, having a backup plan in place amplifies your ability to recover should one of those risks become real. Thus, risk planning greatly increases your overall potential to lead a successful project.

“No battle plan survives contact with the enemy.” – General Colin Powell

I say it a little less dramatically: “If you don’t have a Plan B, you don’t have a plan.” (Yes, you may quote me…) Let’s walk through the four easy steps to building a risk management plan. These steps are based on straightforward questions, which in my experience add a level of clarity that is sometimes missing.

1. List potential risks. To build this list, simply ask “What could go wrong?” or “What if…?” As you brainstorm the list with your team, assign a probability for each. You don’t need to get fancy or over-think it. Just give it your gut feel on the first pass. You can always adjust it later. Make it easy. Is it likely, or unlikely? Is the chance of this occurring high, medium, low? That is plenty of detail for this approach.

 

2. Establish a mitigation plan for each risk. For each item on your list, ask “How do you prevent that from happening or at least lessen its likelihood?” The answer to this question is your risk mitigation plan for that event. Reducing the likelihood of a detrimental event occurring is the ideal risk management strategy. Prevention is better than remedy every time.

 

3. Develop a Plan B. Ask yourself, “If that event does occur, what is Plan B?” For the high probability risks, you will want to have a Plan C too. Document the backup plan! Now take a quick look at the big picture. How likely is it that Plans A, B (and C) would all fail? That should be very unlikely, which means you have reduced the risk of failure!

4. Assign a risk monitor for each item. “Who would be the first to know?” That is your responsible person. That person is to monitor and report to the project manager immediately should a risk occur (or even be anticipated). If something goes awry, the risk monitor is your first line of defense. This does not mean everyone else can abdicate responsibility for monitoring risks; the whole team is responsible, especially if something happens that is (dare we say) unforeseen.

 

So how do you document steps 1 through 4? There are numerous templates and tools available, so search around and choose one that seems a good fit for you and your organization. At a minimum, the risk log should include the following categories:

Description of risk

Probability

Mitigation plan

Plan B (the backup plan)

Assigned risk monitor

Additional fields that may be beneficial:

Risk identifier (just a sequential numbering system will work. I use R-1, R-2, R-3, etc.)

Current status (active or inactive)

I’d like to express one more thought concerning risks versus issues. In practice, risks and issues can get muddled in the minds of team members. This is especially true in organizations with less savvy project team members. For this reason, I include a simple distinction within the narrative portion of my project plans. Simply defined, a risk has not yet occurred, but an issue is happening right now. Then I elaborate a bit further just to confuse them a little (I’m kidding): So, if a risk comes to pass, it can be considered an issue, but an issue does not have to start as a risk–it might be unforeseen.

 

So there you have it, four simple steps and the elements of a log to document your risks. Use these steps as outlined to reap the benefits of this oft-neglected area of project management. Here is what you get for investing the time to develop a predetermined set of risk management actions:

 

increased likelihood of successful project completion

saved time that would otherwise be used figuring out what to do when something goes wrong

documented plans and strategies for future reference

increased confidence in the overall project plan

increased control of the project

And as if all these benefits were not enough, you will surely look like a hero if something does go wrong and you have the backup plan all lined up and ready to deploy.

When Estimates Go Wrong!!!!!

“What’s that ticking sound coming from the engine of the car? Must be a loose valve. I’ll take the car to the mechanic for a valve adjustment…”

At the garage, they look up the flat-rate time estimate for a valve adjustment. It’s easier to estimate when you’ve measured the actual time from lots of competent people doing very similar work. They multiply that time estimate by their labor rates, add in some extra for gaskets, shop supplies and such, and give me a cost estimate. “It should be ready by 5:00.”

I go on my way, knowing I can pick up my car in the evening and how much it’s going to cost me. All is right with the world. But in the late morning, I get a call from the mechanic. “Your car doesn’t need a simple adjustment. The pushrod is bent. The reason it got bent is that the threads holding the rocker arm assembly are stripped out of the cylinder head. We’re going to need to keep your car another day, and the cost will be about triple the original estimate.”

What do I do with this information? I could berate the mechanic for giving me a bad estimate. I could insist that he only charge the originally estimated amount. I could tell him to work through the night so that I can pick up my car first thing in the morning.

I suspect that you don’t do any of those things. I don’t, partly because I don’t think it will get me what I want. Instead, it’s likely to damage my relationship with the mechanic, and get me less of what I want.

Custom software development is notoriously difficult to estimate. We start with vague ideas of what we want, expecting to fill in the details later. We’re usually doing something a little different than what we’ve done before, or completely different. If it weren’t different, we wouldn’t be doing it at all. Software development is orders of magnitude more complex than fixing a mechanical system. It’s fractal, whereby whenever we go into more detail, we also discover more complexities. It’s a very creative endeavour, requiring intelligent imagination.

We compound the difficulties by not keeping records that allow us to compare this work with previous work. We change the makeup of teams, so that even when we can compare the work, we can’t compare the workers. We add bureaucracy and technical constraints that may not be obvious when making the estimates. We change the circumstances after the estimates are made. We often expect other work to be done in the same time as the estimated work, without accounting for the loss of time and efficiency due to multi-tasking.

In spite of all these difficulties, I’ve observed managers berate developers for bad estimates, insist that they finish the work on the previously estimated date, and demand they work overtime to do so at their own cost. This article is not, however, about all the costly damage done by such reactions. Instead, let’s look at how we can act more productively.

When estimates and actuals don’t match, trust the actuals. Should you adjust the estimates to match? If you do this, then you can adjust the plan accordingly. How early can you test the correlation between the estimates in your plan and the actual rate of progress? When work is performed in large blocks and integrated at the end, it’s far too late for effective re-planning when the difference is noticed. How can you validate your plan earlier?

Working in small increments and continuously integrating can help, but you also need to know that those small increments are actually done. Using estimates of “the database layer is 90% done” won’t help, as you’re back to depending on unverifiable estimates. Rather than creating small increments based on the building blocks of your project, try using small increments of functionality. These functional slices will touch numerous building blocks, but can be tested unambiguously as to whether or not they work as desired.

After re-planning based on the reality you observe, you can attend to fitting that plan into your constraints. If progress is too slow to fit everything you want into your budgeted time or cost, consider trimming the scope of the work. This can be done by eliminating features, or by slimming features down into easier–though less capable–versions. You may have to make some difficult decisions about priority.

Observe where your delays and bottlenecks are. What makes the actual speed as slow as it is? If it seems that things “should be faster”, then it’s possible they would be–except for an accumulation of difficulties that impede progress. Perhaps there are some quick wins in out-dated procedures that can be eliminated and speed up progress. Perhaps the internal quality of the code has been ignored to the point that everything is hard to change. It will take time to improve that quality, but it will eventually pay off in faster development speeds.

Make adjusting estimates easy. Estimate in artificial units, and roughly correlate the artificial units to the ones you need to examine. People use story count, story points, t-shirt sizes, animals and other analog for estimation sizes. Try to be consistent, but be aware that estimation will vary over time. An advantage of artificial units is that you don’t have to go back and re-estimate when the apparent speed changes. If you were accomplishing 38 stories per month, and now you’re accomplishing 46, you don’t have to worry so much where that 8-story-per-month improvement originated. Merely project using the newer figure, and see what that does to your plan.

Don’t expect estimates to be precise. If you need them to be precise, you’re trying to plan too close to the edge of failure. Don’t rely on optimistic numbers. Also think about what a downturn would mean. Don’t validate your estimates with reality only once. Continue to re-check throughout your project. Work in priority order so that you can re-plan frequently to the end, but still deliver the highest priority functionality. And if you cannot prune the scope to fit and still achieve the project’s value, then you’re likely to be working on the wrong project.

As Tom DeMarco said, “Strict control is something that matters a lot on relatively useless projects and much less on useful projects.” [“Software Engineering: An Idea Whose Time Has Come and Gone?”, July/August 2009 IEEE Software, pp 96, 95] Projects with a high return on investment can survive a few inaccuracies in estimation. Projects that need precise estimates likely won’t return their investment.