Structure and risk

Examine a standard project management policy around risk management and you are likely to find reference to a risk management process which looks a lot like this:

1. Invite stakeholders to a risk management kick-off meeting
2. Brainstorm risks and record in a risk register
3. Categorise the risks using attributes such as Likelihood, Impact, and Owner
4. Perform simple analysis which (usually) plots impact and likelihood to get a risk exposure
5. Aggregate all of the risks into a single 'bubble chart' which gives a the projects risk profile

Now there is nothing inherently wrong with any of those activities (with the possible exception that the last 2 steps are more about analysis than management). Project management needs to be both generic and actionable regardless of the context. The above activities are certainly that. There value, like most of the project management process, lies in the fact that they allow the project manager to act - even when faced with uncertainty. This is the most powerful part of the project management discipline which consistently delivers value. Many of the other benefits of project management derive value more from other skills of the individual project manager rather than the project management process itself. However, even the value of enabling action is limited. This is action at the personal level and does not necessarily equate to effectiveness at the organisational (read ‘project’ in this context) level.

.

Back to our generic risk management process, the problem with this approach is the lack of a reference architecture. The entire process relies on risks being identified by somebody. This brainstorming part of the process, which the rest of the process is based on, is actually completely subjective. Risks exist as inherent attributes of the endeavor which is the project. The risk management process must be able to find these risks - not simply focus on the activities and analysis which occurs after they are identified.

.

Structure, both organisational and the methodological structure, is actually the first step towards effective risk management. A collaboration architecture, or rather the generative process which ensures the true 'delineated shared understanding' which defines an architecture, ensures that risks embedded in all components are examined. More importantly, the collaboration architecture acts as a reference architecture to show where stakeholders haven't been identified or analysis hasn’t been performed. What this amounts to is a better understanding of the areas of uncertainty - an important component of an effective risk management process.

.

You might suggest that other parts of the project management process provide the structural components which support the risk management process. For example, before you hold your risk management kick-off meeting you have ‘defined scope’ and ‘documented roles and responsibilities’. The only problem with this is that, in the absence of a reference architecture, the project management discipline by itself doesn’t help you identify the right scope, or the right roles and responsibilities. The correctness of the components becomes a quality issue – not process quality in this case, but product quality. The product being the ‘scope’ or the ‘roles and responsibilities’. But unfortunately, within current management thinking, once an activity becomes a management activity it quickly become immune to the organisational checks and balances which naturally improve the quality of that activity (see ‘Management with an uncontested value proposition’ in the MWT Book).

.

Of course, it's also not all bad news that risk identification in the original process is subjective. You, if you wish, can look at risk management as providing a complete risk profile of the project. Alternatively, you can see the risk management process focusing on actionable risks. If nobody is identifying the hidden risks then they probably don't have an effective strategy for dealing with them (I say dealing with them and not 'mitigating' as this is only one approach to dealing with risk. Others might include 'ignore' which is definitely not mitigation). If you don't have an effective way of dealing with the risk then why manage it?

.

The problem only comes when you aggregate the data. If you presume that this is a complete picture of the risks you are wrong - unless you present with a reference architecture. Aggregation of incomplete data must be performed carefully. Without a reference architecture the areas of uncertainty (unknown data) will be lost in the aggregation. Where aggregation is striving to produce a complete ‘big picture’ of the data it often closes up the areas of uncertainty in the name of maintaining a cohesive structure in the presentation. To avoid this the presentation must be cohesively structured before the data is overlaid onto it. This often doesn’t mean pre-structuring the representation – rather evaluating the structural goodness separate to the data.

.

All methodologies embody some world-view of where the risks exist. A customised, comprehensive, and task-specific methodology - and by this I don't mean a cumbersome and monolithic methodology - can actually reduce the need to go back to fundamentals for all risks. After all, task-specific methodologies are developed in response to known risk indicators inherent in the task. Unfortunately, by the time most methodologies are 'rolled out' all sense of the drivers behind the components of the methodology are lost. In effect, the process of pre-preparing methodologies disconnects the methodology from the risk mitigation drivers which formed it. This in turn causes another cross-discipline disconnect - this time between the domain specialists promoting the methodology and the project management perspective.