Risk / issue management

Introduction

According to a famous bar-room “philosopher”, there are three types of people: those who make things happen, those who things happen to, and those who say, 'What happened?' This homespun, tongue-in-cheek psychology can be accurately extended to project managers. There are those who make sure risks and issues are managed, those who react to events as they happen, and those who say, 'What's happened to my project?' In some cases, project managers who've failed to manage risks and issues will be blissfully unaware of their role in the disaster. Very much like a bad driver whose thoughtlessness causes a motorway pileup and who exhibits innocent amazement at the carnage unfolding in the rear view mirror.

Even the best managed projects rarely run exactly to plan.

Inevitably events will occur that have the potential to derail your project unless they are dealt with effectively. Risk and issue management is a key tool in anticipating and dealing with these events.

It should not happen to a PM -- but it did! System problems at a large financial institution caused a major outage and loss of revenue, and the proverbial really hit the fan. During the ensuing witch hunt the project manager who recruited the culprit bragged, 'I had my doubts about him at the interview. I asked him about his weak points and he admitted that he was prone to being careless at times.'

Some people revel in letting everyone know they saw it coming, while conveniently overlooking the consequences of their own inaction.

Managing risks and issues

It's surprising how many people in a project team struggle to define the meaning of 'risk' and 'issue'. In the context of a project:

+ a risk is an event that may occur and if it does will threaten the successful delivery of the project;

+ an issue is a situation that if left unresolved will have the same effect.

==

A risk is something bad that might happen; an issue is something bad that has happened.

==

Risk and issue management is an approach to anticipating and dealing with events that can cause significant deviations from the project plan. On another level, risk and issue management helps you to pin point your plan's weaknesses and gives a useful insight into your project's overall health.

It's more than admin

Considering the importance of risk and issue management, it's disappointing that many project managers see it as a tiresome administrative exercise; a list of extremely unlikely events with dire consequences created at the start of a project. The list - or log as it is often called - is immediately filed away in the hope that when things go awry the log can be pulled out with a triumphant shout of, 'I told you so!' This totally misses the point of the exercise. A super project manager makes risk and issue management something that's revisited repeatedly throughout the project lifecycle.

==

You know your risks and issues are just there to pad out your project file when …

+ The project name is incorrect because the list has just been lifted from a previous project.

+ They were last updated on the second day of the project.

+ Everything is at risk, even whether day will follow night.

+ They're kept a closely guarded secret from the rest of the project team.

==

Process overview

There's a well-established process for handling risk and issues. This is straightforward and involves only three steps:

1 Identification. Pinning down the key risks and issues that threaten the success of your project.

2 Action planning. Assessing what can be done to deal with them.

3 Monitoring and control. Keeping risks and issues under review and adjusting your approach when needed.

It's essential for you to drive this process on behalf of your team.

However, any project team member should be encouraged to flag potential issues and risks for assessment. The whole team also has a role to play in seeing through the actions that are agreed.

The risk management process is an iterative one. After the initial identification and assessment of risks and issues have been made, mechanisms should be put in place to keep them under regular review.

This will include looking out for new risks and issues, and reassessing those that have already been captured.

In the remainder of this chapter, we'll explore each step in the process in more depth.

Step 1: identifying key risks and issues

You'll often see risks and issues described in vague and generic terms.

A fair number of project managers also treat the identification of risks as a test of their imagination. What unlikely , totally uncontrollable event can they dream up?

==

TIP:

Don't spend time worrying about things that are outside of your control.

Focus your attention on risks and issues you can influence directly.

==

A good number of important risks and issues will be immediately apparent - especially to a seasoned project manager. Particularly valuable will be your prior experience of managing similar projects, since many risks and issues are likely to reoccur. As you work with your team to draw up a list of potential risks and issues, it's good to keep three basic questions bubbling away at the back of your mind:

1 What threats are there to a fit-for-purpose delivery? This includes concerns about over-engineering as well as falling short of what's required.

2 What threats are there to keeping to agreed project costs? Here we're really thinking about overruns since underspend is not that common.

3 What threats are there to planned delivery timescales? Again, overrun is the typical concern, since projects don't have a habit of finishing ahead of schedule.

You'll also benefit from some systematic techniques for teasing out those risks and issues that aren't staring you in the face. Once an initial pass of the more obvious risks and issues has been undertaken, we recommend validating and expanding this list using the following three techniques.

==

How to identify risks and issues:

1 Assumptions review. Consider how safe each important assumption underpinning your plan is.

2 Lessons learned. Look at what's gone wrong with other (similar) projects in your neighborhood.

3 Checklists. Work through lists of things to think about and other handy mnemonics.

==

Assumptions review

Wouldn't it be great to have 20-20 hindsight? Invariably something comes along and temporarily derails your project that seems fairly obvious in retrospect. Unfortunately many things that seem obvious after the event aren't that obvious at the time. One excellent way of anticipating problems is by reviewing project assumptions. This is a simple and sensible way of identifying project risks, and perhaps some issues too.

In preparing a project plan, you'll always need to make some assumptions. More often than not, major risks and issues arise when these are misplaced. They also lurk in what are thought to be facts, but turn out to be assumptions in disguise.

==

A project assumption is more or less anything that has not already happened.

==

So, first have a careful review of your project facts to check they're sound. Then, ask yourself how safe each assumption is. If the answer is something like 'not very', add it to the pile.

Lessons learned Nearly all risks and issues have hit other projects before. It's one of the few times that you can reap benefit from the suffering of others. If nothing else you'll surely have your own lessons to draw upon.

Not many project managers are keen to own up to or document their mistakes. So you'll be lucky if you find any 'lessons learned' reports. In any event, there's no substitute for simply talking to other project managers and comparing notes. Also people tend to be more candid if the meeting is informal.

For each lesson that you come across, ask yourself whether it applies to your project. If so, add it to your list.

Checklists When you think you've got a pretty good starting list together, you can use checklists as a prompt to identify additional risks and issues.

Checklists provide a series of categories to consider and here's one example:

==

Schedule Technology Organization Resources Methods

Compatibility Lifecycle Over-engineering Users Dependencies Suppliers

==

You may be able to find checklists designed with your particular type of project in mind. If you can't lay your hands on any tailored checklists, there's nothing to stop you and your colleagues con Constructing your own. It's a good way to share your experience.

Risks and issues logs

Once you've got your risks and issues identified, you'll need a place to record them. Logs are used to document specific information about each element. Here's the minimum set of information that we believe you should hold about your risks and issues.

[[Log item name ID Raised by Date raised Description Probability Impact Score Action(s) Owner Escalate Risk/issue x-reference Open/closed

]]

[[ Description A unique identifier (simply used as a reliable cross-reference) The person who identified the risk or issue The date on which the risk or issue was logged A clear description of the risk or issue and its impact Probability score; the likelihood of a risk occurring Impact score; impact on the project of the issue or risk (if the risk occurs) Risk score; measure of the size of the risk (taking into consideration its likelihood and impact) The actions agreed to deal with the risk or issue The person assigned overall management responsibility and ownership for the risk or issue Whether or not escalation within the organization is required (yes/no) Cross-reference where an issue has arisen from a previously identified risk Whether or not the risk or issue is current

]]

There is other information that could be recorded for each risk and issue, but in our experience these are rarely used in a meaningful way.

Additional items simply create 'noise' and an unnecessary overhead in maintaining the logs.

A final word of caution: neither too much nor too little! Experience shows that project teams are reluctant to trawl through logs crammed with every risk and issue imaginable. Rather than looking for the gems buried within, they'll simply ignore the logs entirely. So don't allow anything onto your logs unless it really merits attention.

Step 2: action planning Once you've identified your risks and issues you'll need to plan some positive action, or the whole exercise will have been an interesting but ultimately pointless undertaking. Having picked up a fair number of sick projects in our time, we can't emphasize enough the importance of the old medical adage: prevention is better than cure.

With risks, your first objective is to identify ways of preventing them from happening. These actions are known as preventative actions.

The key to avoiding risks is simply to ask yourself what could be done to prevent each risk from happening.

For an issue, it's too late to do anything preventative - for that's the very thing that differentiates it from a risk. So instead you have the job of planning actions that can deal with the consequences. These actions are known as contingent actions and they should resolve - or at least contain - the issue.

As a further refinement, it's also possible to plan contingent actions for risks. These are the actions that you would take if your preventative measures fail to stop the risk occurring. You could always take the 'I'll cross that bridge when I come to it' approach, but this is not always wise. Fire safety illustrates this nicely. Most offices now employ sensible preventative measures to guard against fire; for example making furniture from materials that are not readily combustible. However, contingent measures are also usually in place; for example sprinkler systems and rehearsed file drills. Clearly it would be somewhat late in the day to start installing a sprinkler system at the first whiff of smoke.

Prioritizing risks and issues Since risks and issues do not all have the same level of importance, you need to find a way of identifying those that deserve the most attention.

There are many ways of doing this, and we've seen many impressively sophisticated means of weighting various factors and calculating scores. However, for most projects, the following simple scoring mechanism provides you with a good way of prioritizing risks and issues.

==

Risk and issue scoring Risk score: + Probability of occurrence + Impact if risk occurs Issue score + Impact of issue

==

--

Scoring system Probability of occurrence 1 - Very unlikely 2 - Fairly unlikely 3 - 50/50 chance 4 - Fairly likely 5 - Almost certain

Project impact 1 - Negligible 2 - Minor 3 - Moderate 4 - Serious 5 - Disastrous

For example, a risk that was fairly unlikely and would have a serious impact on the project if it occurred would get a risk score of 8 (2 + 4), while an almost certain risk that carried a moderate impact would get a score of 15 (5 + 3), and so on.

--

Having scored your risks and issues using this technique, you can then simply sort them by score. Those with the highest scores deserve your immediate attention.

Step 3: monitoring and control

As we've said, risk and issue management is not something that you just do at the beginning of the project. Quite the contrary: it's some thing that is part and parcel of day-to-day project management.

It's good practice to incorporate a review of risks and issues as part of tracking project progress. For example, you could make this a standing agenda item at your check-point meetings. You should review both risks and issues already logged, and assess anything new identified by you or your team.

Even a super project manager can't deal single-handedly with each threat to project success. Furthermore, you're unlikely to be best placed to deal with them all directly. However, it's essential that there's always a single point of ownership that can't be passed on. The owner must be actively involved in assessing the relevant risk or issue and agreeing the course of action required.

==

Key project management tools - such as the risks and issues log - can lose their freshness as quickly as a baguette. If they're not regularly updated they soon become stale.

==

In some circumstances, resolution of a risk or issue may prove impossible, or it may not be directly within your sphere of influence. If this is the case you must consider escalating resolution to someone more senior. A super project manager is judicious in choosing when to escalate - you don't want to be seen as someone who can't resolve problems. However, there's no point banging your head against a brick wall over resolving matters you simply can't influence.

Most organizations expect appropriate escalation and generally you won't be thanked for holding onto risks and issues that need more senior attention. One important point to note, though, is that use of escalation does not abdicate your responsibility from tracking the risk or issue. A big cheese might have her name against a risk or issue in your log, but that doesn't mean that anything meaningful is being done about it! Are your logs trying to tell you something? From time to time, it's a good idea to take a step back to consider your risks and issues logs in their entirety. They provide a useful pointer to the overall health of your project. A large number of significant risks and issues is a sign of a project in trouble. It suggests that more radical action is required than simply trying to address each risk or issue in isolation.

A final tip is to take a look at how the risk and issue logs have evolved over time. As a healthy project progresses, you'd expect that risks would be reduced - or at least contained. You should also see evidence of a good track record in closing down issues. So increasing risk scores, and issues hanging around on the logs indefinitely, should be a cause for concern and further investigation.

Summary

A super project manager won't end up looking around in amazement wondering, 'What happened?' If you manage your risks and issues you'll be giving yourself the best possible chance of side-step ping the avoidable things that threaten your project. Remember: if you don't attack risks and issues they'll attack you! We know that risk and issue management will never have a glamorous image, but it's often unfairly tagged as a one-off administrative exercise. It's a process that should be applied throughout the project to keep threats firmly in your sights. To do this effectively you need to use a simple, systematic approach so that you don't overlook anything important.

Don't finish your project wishing you'd done a better job of anticipating events and taking early corrective action. Too many project managers end up kicking themselves and wishing 'If only' because a problem was so obvious with hindsight. With a little extra thought and attention, these risks and issues could have been nipped in the bud.

A super project manager avoids being a victim of chance and circumstance. No doubt you'll have a reputation as someone who makes things happen. But in this context, you'll also be known as someone who makes sure that certain things don't happen!

==

Quick Notes:

+ It's not an add-on - it's an intrinsic part of super project management.

+ Your risks and issues should be clear, succinct and above all else specific to your project. Make sure you can see the wood for the trees.

+ A progress review isn't complete without a trawl through your logs.

+ Concentrate your efforts on the biggest risks and issues, not the ones that are easiest to deal with.

+ Use your log to give your project a regular health check.