Internal Controls Design website by Matthew Leitch (tutor, researcher, author, & consultant)
New website, new perspective: - Related articles - All articles - The author - Services

Project Graphic

Natural project risk management

by Matthew Leitch, 15 October 2003

Time to make project risk management work
6 principles for doing it faster
Generic schemes as a head start
Reasoning rapidly
Areas of uncertainty
Rigour by iterations
How does this compare with standard theory and practice?
Further reading

Time to make project risk management work

Think of famous failed projects. If you live in the UK like me the first that come to mind are probably government projects because they get a lot of publicity. Did they have project risk management in operation? Of course. Did it work? Obviously not.

The Unexpected is a powerful force but formal risk management tends to end up as a feeble, muddled attempt to secure a project that is being done in a highly risky way. The bureaucracy of risk registers and workshops can be costly yet ineffective.

Solving these problems involves two things: (1) using more powerful risk mitigation actions, of which Evolutionary delivery and its like are the leading examples, and (2) using more rapid and effective methods for devising and revising the total risk management scheme for a project, pulling in the powerful risk mitigation actions where they are needed.

This paper concentrates on the second part of the solution: a rapid design process for devising the full risk management scheme for a project, though it includes a list of potential actions.

The techniques proposed are based on my work in designing internal control systems for large scale business processes and systems. The techniques that work well and save much time in that work could be applied to project risk management.

6 principles for doing it faster

Six powerful principles can be combined:

  1. Start with a generic scheme of actions in mind, not a blank sheet of paper. The idea is to decide how to adjust the emphasis and choose between alternative techniques given the specifics of a project. This makes it easier to think of actions and create a comprehensive scheme. The generic scheme may well reflect the industry or type of project, making it even easier to tailor quickly.

  2. Pack the generic scheme with powerful, varied actions. An effective scheme will include many different actions, based on many different ways of thinking about risk and uncertainty. Do not imagine that listing "risks" and then trying to think of actions to put against each one is all you need.

  3. Reason from observations about the distinctive characteristics of the project. "Distinctive" things are of course those that are most likely to require tailoring of the generic scheme. This saves the trouble of considering factors that have little or no impact.

  4. Reason directly from distinctive characteristics to actions, where you can, but otherwise to deductions about the actions.

  5. Think first about "areas of uncertainty" rather than specific risks. Avoid getting sucked into detail you don't need and keep upside risks in mind as well as downside ones.

  6. Achieve rigour by iterations. Repeating the analysis allows you to go deeper and adapt to new information.

The next sections explain these in more detail.

Generic schemes as a head start

Starting with a generic scheme and using analysis to tailor it to a particular project at a particular moment has many advantages:

There is no one generic scheme that is essential to make this approach work. Almost anything will do, but obviously some schemes are better than others. Ideal schemes have the following characteristics:

Although it is obvious that an abstract scheme is not helpful enough it is not clear how much detail is ideal. In the related field of designing internal control systems for financial processes I have seen some attempts to provide a very detailed generic scheme, usually involving a database of controls from which the designer selects. While I can see no objection in principle to this they have been disappointing in practice, with the wording of specific controls being too vague to be helpful or credible.

Suggested generic scheme of risk responses

Many different schemes could be a good basis but here's one I like that is broad and meets most of the criteria set out above. Responses are divided into 6 types and these form a system. Within each type there are various alternative techniques and another way you can tailor the scheme is by deciding where to place your emphasis, building up from no focus through broad decisions about emphasis, then adding more specific points of interest. To begin with, here's a picture of the 6 elements of the system:

Project Graphic

At the top, directing resources/attention is "allocate RM resources", which is what this paper is largely about. It takes information from learning and other activities and decides where to put the risk management effort. That risk management effort goes into learning, into structuring the plans to control risks, into changing the content of plans to control risk, and into forecasting risk and communicating it externally to stakeholders. Obviously this is to be a continuous, or at least frequent, activity that should start as soon as possible.

There is no need to wait to start thinking about how to allocate risk management resources. Don't wait for an agreed scope or any of that paperwork. As soon as you have some scraps of rumours about the project that is enough to begin making deductions about how to cope.

Within each of the six activities emphasis can be placed in various ways. By default, your approach will be fairly general with few if any specific points of focus. However, more analysis will allow tighter focus of resources on more specific areas or even particular outcomes, layered on top of a safety net of general risk management procedures. Dimensions along which you might choose to focus resources include:

Typical specific responses and techniques in each of the six groups are as follows:

A number of things in this suggested scheme need additional explanation.

The list of techniques may look long, but it is still far from complete. If possible a scheme more specifically tailored to the type of project an organisation typically does should be used instead of a totally generic scheme. For example, if your organisation does civil engineering projects then a scheme that lists the things often done on such projects will be more useful. Devising such schemes is part of embedding risk management.

The output of rapid risk management planning as described in this paper is a mixture of specific responses and decisions to do more risk management analysis. In practice it is often hard to draw a clear distinction, and not important to do so. What is important is to direct attention appropriately, and that can be done by gradually working down to more and more detail, but only where it is worthwhile.

Risks should usually be met by multiple controls, and controls should usually meet multiple risks. In other words, the control scheme should be multi-layered. For example, you may take actions to make some bad event less likely to occur, and also plan for the contingency should prevention fail.

In the suggested scheme above I have not made it clear which actions are alternatives and which should be used together. Typically you should build a multi-layered control system so the individual controls accumulate. How much depends on how much emphasis you need. However, some controls are incompatible and cannot be used together.

This breakdown uses the preventive vs contingency distinction rather than the probability vs impact distinction. (It's in the section on modifying content.) These distinctions are very similar in practice but I suggest thinking about cause and effect because it refers more directly to what you have to think to find risk responses.

A single possible event can have both positive and negative effects, even from the point of view of one person. Look for ways to make events that are, overall, unhelpful less likely, and events that are, overall, helpful more likely. This may not be obvious as it is the net impact after possible modifications of the impact that matters.

Certain activities tend to merge in practice. Learning and allocating risk management resources tend to be very close and often done in the same activity. Learning and forecasting are also very close. Communicating risk externally to stakeholders and hearing their news is often done in the same meeting.

The value of continuing with a project should be reviewed from time to time, but I have not included this under risk management activities. Some other approaches do.

Reasoning rapidly

There are many factors that might be worth looking at when designing a risk management approach for a project. In the late 1990s the accounting firm Coopers & Lybrand offered to review project risks using a "tool" called SQA 2000. This was in fact a questionnaire with thousands of questions on it. Very thorough but how often do you suppose all the questions were relevant?

Factors about a project that are most worth finding out and considering are those that (a) are often relevant to the way risk and uncertainty should be managed, and (b) are distinctive of that project (i.e. meaning that it is different from the assumptions underlying a generic scheme).

Factors commonly relevant to risk management decisions include:

  1. Control performance requirements
  2. Project features
  3. Cultural features
  4. Environmental features

Consider each factor and see what it suggests, individually and in combination with other factors. Distinctive characteristics may suggest conclusions about:

This reasoning can be summarised in a table with characteristics in the left most column, and other columns for inferences. Putting the conclusions about actions in the final column is logical as often the other inferences are intermediate steps towards a conclusion about action.

The more skill and knowledge you have the more easily you can make good deductions about your risk management actions. It's up to you what models you believe in and what deductions you make. Fortunately, most deductions are fairly simple and don't change much between projects. To show how this works here are some things you might say in a meeting. If you refer back to the generic scheme of actions and the list of factors given above you can see how these inferences link them up. I've only given one deduction in each case but the factors will usually result in several.

"Our deadline is absolutely fixed... ...therefore... ...we'd better do an analysis of risks that might occur on our critical chain and other tasks that may become critical."
"This project involves some critical innovation in the design of the interface. It's not been done this way before and we don't have a detailed solution worked out let alone tested and proven. Everything depends on this problem being cracked ... ...we had better start on it as early as possible. If this problem can't be solved we should cut our losses as soon as we know."
"Last time we did a project it turned sour suddenly, even though right up to the end people were still saying it was achievable. It looks like people were not reporting progress or their perception of risk accurately ... ...consequently... ...we need to make it a high priority to develop the honest and open culture we need for success. We must make it understood that uncertainty suppression is a bad thing and we'd like to know about uncertainties right from the start, and all the time."
"It's obvious how we can cut this project into evolutionary deliveries and we've already seen that we face some uncertainties around delivery... ...we'll devise an evolutionary delivery plan."
"The value of the whole project depends on there being sufficient demand for the facility once we've built it... ...ergo... there any research we can do to improve our knowledge of that? We need to show the uncertainty in the financial model for the business case, so Monte Carlo simulation is needed to at least some degree of detail. We should look at ways to implement the facility in stages, with decision points along the way rather than committing in one decision up front."
"This is a classic 'change' project. We have to win support from three departments and many people will find their jobs and status have changed as a result... thing we'll need to do is continuously monitor the views and actions of the parties involved and pre-emptively work on communicating with them about changes and how they can benefit from them."
"Our software suppliers are competitors to our consultants... ...therefore... ...that increases the risks around them doing things that are unhelpful, and acting dishonestly, maybe doing things to make the other side look bad. They'll be blaming each other most of the time and might even let things go badly if they think it will hit the other side more. In response we should perhaps consider insisting that they each take us through their own risk assessments and responses in more detail and more often than otherwise might be the case."

These deductions are not a commitment to action. Not yet. You need to decide what actions are worthwhile and what do not have sufficient priority. This requires looking at the priority of actions, not "risks", so try to summarise the evidence in support of decisions about actions.

When you have been through all the major factors go back through them looking for combinations that bear on the same actions. Typically there will be a number of actions that are strongly indicated by several factors and no question that they should be done. This simplifies prioritisation.

Sometimes it will not be clear whether a conclusion about an action is justified. Consider all the factors for and against.

In the case of actions based on uncertainties it may be helpful to do some thinking about the implications of each uncertainty and try to value its impact, perhaps even as a probability distribution for impact. The objective is to prioritise the action, not individual risks it addresses. It is quite possible that some risks do not justify the proposed action when considered alone but do in combination. This is hard work, so don't do it unless you really have to.

Your next summary should be a rewrite of the generic scheme, but now with more specifics, names of those assigned tasks and roles, indications of emphasis, selections from alternatives, notes on style, and so on. This can be cross referenced to the factors driving the decisions.

Your final summary will probably be a chart of actions divided into work packages that can be assigned to individuals or teams, given resource estimates, and put into the project plan.

Areas of uncertainty

In the preceding section I explained that risk is not the only consideration when designing a scheme of risk and uncertainty management actions. Other constraints are important too.

Another difference from common practice is that I use the term "area of uncertainty" instead of "risk". This subtle difference has important advantages:

Rigour by iterations

Iterations work in two ways. Firstly, you can repeat an analysis, at the same level of detail, and see what new progress you can make having had more time to think and having learned from experience, research, etc. Secondly, you can perform an analysis at a greater level of detail in an area that needs it.

Planning a project is complicated enough without trying to think through every combination of unexpected outcomes, so risk management cannot look at everything in detail. You must be selective. Several of the risk responses resulting from an initial attempt to plan risk management activities will typically be to do more analysis in specific areas or specific ways.

How does this compare with standard theory and practice?

In theory there are big differences between the approach described above and "standard" theory. By "standard" theory I mean the approach where you are supposed to identify risks, assess them, decide which are worthy of action, and then assign actions and owners to each individual risk that exceeds your tolerance.

However, in practice the difference is much less and what I have described is much closer to what people actually do than the standard theory. If you look at the risk register produced by a productive team under the banner of standard theory you will see that in the "risks" column they have written all manner of items, almost none of which are risks, and under the "actions" heading they have written a variety of actions including additional analyses they plan to perform. Quite often the actions are already planned at the time the risk register is created for the simple reason that they are part of the team's customary approach to projects i.e. they do not start with a blank list of risk responses.


Before you start listing risks and mitigation in workshops, think about the bigger picture: the full scheme of risk and uncertainty managing actions you can take. Listing specific worries is just one technique in this broader approach, and not the most powerful in many cases.

Further reading

"Designing internal control systems" describes a design method for creating schemes of internal controls for business and financial processes.

Evolutionary Project Management, as described by Tom Gilb (one of the key figures in this area) is characterised by several principles.

A case study on Evolutionary Project Management has been written by Stuart Woodhead, an IT project manager who had the experience of managing two nearly identical projects, one of which was a failure using conventional methods, the other being managed with evolutionary methods with great success. The case study is a very realistic description of these methods as used on a small scale.

Also from Tom Gilb comes this useful advice on detecting and preventing defects in a project: "Optimizing Software Inspections."

A detailed discussion of risk management using the Critical Chain method (an application of Eli Goldratt's Theory of Constraints to project management) is given by Frank Patrick in "Critical Chain and Risk Management."

If you have any ideas, questions, or concerns please feel free to contact me at I normally reply within a couple of days.

© 2003 Matthew Leitch
New website, new perspective: - Related articles - All articles - The author - Services

If you found any of these points relevant to you or your organisation please feel free to contact me to talk about them, pass links or extracts on to colleagues, or just let me know what you think. I can sometimes respond immediately, but usually respond within a few days. Contact details

Matthew Leitch - Author

About the author: Matthew Leitch is a tutor, researcher, author, and independent consultant who helps people to a better understanding and use of integral management of risk within core management activities, such as planning and design. He is also the author of the new website,, and has written two breakthrough books. Intelligent internal control and risk management is a powerful and original approach including 60 controls that most organizations should use more. A pocket guide to risk mathematics: Key concepts every auditor should know is the first to provide a strong conceptual understanding of mathematics to auditors who are not mathematicians, without the need to wade through mathematical symbols. Matthew is a Chartered Accountant with a degree in psychology whose past career includes software development, marketing, auditing, accounting, and consulting. He spent 7 years as a controls specialist with PricewaterhouseCoopers, where he pioneered new methods for designing internal control systems for large scale business and financial processes, through projects for internationally known clients. Today he is well known as an expert in uncertainty and how to deal with it, and an increasingly sought after tutor (i.e. one-to-one teacher). more

Please share:            Share on Tumblr