31 August 2012

The Only Good Risk Register Is An Empty Risk Register

By Mark Powell

Have you ever seen a risk register with 500 or more risks on it? It seems that these days a lot of projects have huge risk registers. How does this happen?

Most people believe that this is natural for a large and complex project.

A good friend recently described a proposal for the California High Speed Train that would go from San Diego to San Francisco and Sacramento. His pre-project draft risk register covered everything from track, signals, routes, station interchanges, software, train sets, health and safety, Environment, etc., and it was huge. Well, that, of course, is no surprise; it is one big, complex, project!

However, I told my friend that when he started that project, his risk register should be empty. I also told him that during the life of that project, he should never have more than about a dozen active risks on his risk register. He scoffed – of course.

Now why would I say such outlandish things for such a large complex project? Two reasons: good Project Management and good Project Planning.

Good project management handles (identifies, assesses, sets up monitoring and, possibly, mitigations) all those pre-start risks in their multitude of management plans and management systems that are complete at project start. In fact, if you think about it, all of our management plans and management processes are nothing more than plans to execute monitoring and mitigation of all those risks we identified before project start.

For instance, we know there’s a risk that all project requirements may not be satisfied in the implemented system. But we don’t put a risk for every requirement in a risk register; we develop a verification plan to mitigate all those risks, and work it through a verification processes. We know there is always a risk that the subsystems and components of the system as-built may not interface correctly. We don’t put those risks in the risk register, we develop an integration plan to monitor and track interface development and manage system builds to mitigate those risks.

For a big infrastructure project like the California High Speed Train, there will be a slew of environmental risks. Various EPA regulations will be prescriptive with respect to monitoring and mitigation of these risks. Every project has a multitude of budget and schedule risks, but we have Earned Value Management Systems to address those.

Good project management may generate upward of 50 management plans. Each of these plans will describe how the risks identified before project start (most of which we know that all projects will have) will be monitored and mitigated through existing processes. Only those risks that were not identified before project start should ever populate the risk register, and any well-managed project should never have more than dozen active risks at any one time.

Bad project management dumps all of these risks into a risk register instead of developing all of those plans. It is nothing short of an abdication of project management responsibility. That’s how you will see 500 or more risks in a risk register. It is not poor risk management; it is poor project management, and no real project planning.


Mark Powell is a consultant specializing in Project Management, Systems Engineering, Risk Assessment, and New Business Acquisition. He is regularly sought as a plenary speaker for conferences and symposia, and to provide tutorials and workshops to improve corporate performance.

He is active on a number of discussion groups on LinkedIn that are particularly relevant to this blog post. Invite him to link, or contact him directly at mark.powell@attwaterconsulting.com for more information.

6 comments:

  1. I would split the difference. Our standard project life cycle and accompanying plans mitigate "standard" risks--those that are fairly common to the kinds of projects we do. Those needn't be in a risk register.

    However, risks that are unique to the project itself and not otherwise covered by plans deserve the visibility and tracking they get from being in a risk register and the accompanying process for managing them, even on day 1 of the project. Keeping in mind that not every risk gets an active mitigation plan, but still may deserve tracking.

    I do agree that unwieldy risk registers become useless, so the art of project management is to find the right level to manage explicitly while allowing some to be handled by the plans and processes.

    Good point.

    ReplyDelete
  2. This reminds me of a place I used to work. The manager kept adding to the top priority list. At one time there were over twenty top priorities. The inability to decide the real top priority proven itself as the inability to attack the most significant problem(s). Similiarly, listing too many risk issues may cause lost focus. As I see a risk list as "priority issues" that need to be resolved or the program is going to fail to meet its objectives. I'm not familiar with the risk register management style being discussed. I'm assuming the magnitude of the risk are documented to help establish management priority. I have found EPA, Safety, Human Factors, etc. organizations that you have to coordinate through can be loose cannons and cause milestone slippage because it is impossible to know exactly what you need to do to comply with those groups.

    ReplyDelete
  3. I blame the Cost Analysis community for using the term risk for cost and schedule uncertainty. This should not be included in the risk register, which should only capture threats to the cost and schedule plans.
    However, real threats cannot be managed away. Even after mitigation activities there is usually some residual threat that cannot be mitigated and should remain in the risk register.
    If you have an empty risk register you are fooling yourself.

    ReplyDelete
  4. Anon. Real threats can in fact be managed away -- they can be blocked by appropriate means (where the topic is security, the means are called safeguards).

    'Residual threat' is a nonsense phrase. The threat doesn't change -- your vulnerability to the threat might.

    What's left over is 'residual risk' -- the probability distribution of losses due to less than perfect safeguards or blocks.

    ReplyDelete
  5. In any case, the point is that once you've decided what to do about a threat and it's attendant risk, it's just a plan item with some uncertainty. It doesn't need to be tracked in two places.

    ReplyDelete
  6. The issue on projects I've been involved with is how to strike the balance. One extreme is the PM who has "no" risks. The other is to record "everything" and what you are doing to mitigate it. The first PM is deluding him/herself. The second takes credit for normal work. Most projects do have risks that need to be prioritized, even at the start of the project. I ended up designing a database on a project because we couldn't get support form that team. It ended up working but I had no background in it when I started. Now THAT was a risk.

    ReplyDelete