It's Not Where You Start, It's Where You End Up!

Monthly Risk Data Reporting Issues

Some people are trained, others are coached, and the majority are simply thrown in the deep end of learning how to be a project risk manager. No two people's journey into project risk is ever the same. Unfortunately, there are no quick routes to learning how to be a project risk manager, but there are a few key elements that every risk manager should be aware of. 

Over the last fifteen years of being involved in project risk management, I have learned a few things about the process, the people and the politics of managing project risk. In this post, I shall explore my personal top 5 principles for becoming a highly sought-after project risk professional. 

First Principle: 

Manage the project risk process and not the risks 

The most important thing to remember when you are a project risk manager is that you should first and foremost manage the risk management process and not be responsible for any of the project risks themselves. The only specific risk the risk manager should be concerned about is the failure to implement the risk management process. 

To achieve this, every risk should have a designated owner from within the project team. Identifying the owners of risks is sometimes easy, as certain risks tend to have a natural home with a subject matter expert within the team. However, other risks may well be multi-disciplined and have a number of potential owners. It should be the project leadership team's responsibility to formally allocate ownership of such risks to the individual who is best placed to oversee the risk. 

With every risk allocated to someone else, what does that leave for the project risk manager to do?  Simple! It’s your responsibility to monitor, report on, and oversee the quality of the management of each of those risks and ensure they are up to the standards required to achieve the project's objectives successfully. 

Second Principle: 

Contextualisation of the project 

All the world's risk management standards start from the same point: Know Thy Project Context. 

Why is this? Without being able to articulate clearly the context of your project, how do you know what is at risk? Furthermore, without understanding the environment within which your project lives, how do you know what could affect it? 

Contextualising the project is a complex multi-dimensional task and getting this right can mean the difference between success and failure. 

There are many layers to contextualisation. Some are obvious, whilst others are more subtle.  You might start with simple things like: what are we trying to achieve, and when does it need to be completed by?  Then we start looking at relationships.  Who are we working with, both internally and externally to the project team? How can that relationship shape the way in which the project progresses? What are the customer's expectations, both explicit and tacit?  How much confidence do we have in the supply chain? What are the organisational politics around this project? Who else is depending on this project to succeed, and in turn which projects are we dependent on? Finally we come to the money. Whose budgets are we relying on, and whose are we impacting? Do we have sufficient contingency, and what are the expectations for using or losing it? 

All these elements involve a degree of uncertainty. These are the assumptions, dependencies, exclusions and constraints that abound during the initiation phase of the project. Once underway, change from internal and external sources introduces further uncertainty. The unanticipated consequence of the project's own actions can introduce significant change on its own. 

As the project risk manager, it is your responsibility to know and understand as much of this context as possible, and to keep the project leadership team appraised of every development and departure from the expected.  This is achieved with metrics. 

Third Principle: 

Establish the correct project metrics 

"You can't manage what you can't measure" may well be an over-quoted and often trite phrase, but it is quite prescient when used in the context of project risk management. 

There are two forms of measurement that the risk professional should be aware of: “lagging indicators” and “leading indicators”. What Is A Leading And A Lagging Indicator? 

Most people focus on the lagging indicators because they are often the quickest and easiest to establish. How many risks have been identified? How many actions are underway or have been completed in a period of time? Who holds the most risk on the project? It’s easy to establish such lagging indicators from the data held in a risk register and derive pretty and colourful charts with which to dazzle management. 

However, it is the ability to define leading indicators for risk, often termed Key Risk Indicators (KRI’s),  that differentiates the common risk-tool jockey from the true risk practitioner. 

Establishing KRI’s that can indicate that the environment and the context are changing, in which direction they are changing, and how fast they are changing can provide the necessary data to prevent risks from occurring. 

The problem with KRI’s  is that they are much harder to establish. They also have a much shorter lifecycle, being only relevant while that particular context condition exists. 

Examples of good KRI’s include measuring the quality and quantity of delivery of parts or materials for the project. Should these metrics falter, then the risk may be increasing. Another is the yield of a product. Changes in yield are often associated with the early stages of failure of a process or machinery component. Less easy to quantify are relationship metrics. Measurements of customer satisfaction or geopolitical tension are rarely seen on risk dashboards, but can constitute considerable sources of risk that the project team should track accurately. 

Fourth Principle: 

Present project insight, not project data 

Presenting a spreadsheet printout for a full-blown cost and schedule risk analysis with multiple permutations to a senior manager is possibly the worst thing a risk practitioner can do. 

The problem with presenting "data" is that the person receiving it will often not have the time or the training to understand it. When this happens, they will easily dismiss it and focus on something that they can understand. Being dismissed is bad. It negates the value that you can bring to the project, and it diminishes your reputation in the eyes of the team. Or, if the audience focuses on a particular data point or nuance in an assumption, they may start to dig deeper and ask awkward questions. This will inevitably result in a challenge to the data source or the methodology, and undermine the risk management process itself. This is by far the worse outcome, as it means that they are less inclined to engage with the concepts of risk management in the future.   

To avoid this pain, present useful information that is valid within the context of the immediate and long-term objectives of the project. This is achieved through the combination of clearly articulated context, along with the measurement of the appropriate metrics presented in a story format.  Stories engage audiences in a way that invites them to become more involved with the discussion.

Be very careful to spell out what the information is saying.  Ensure that it reflects either the forward-looking anticipation of the effect of uncertainty on the project, or the backwards-looking effect of events on the project. Confusing "What is" with "What could be" is perilous for decision-makers.  Whilst the good ones should challenge any assumptions that have been made concerning potential future events, not everyone will be so enquiring and so may mistake forecast for fact. 

Fifth Principle: 

Become a conduit of project knowledge 

There have been times when I have added significant value to a project simply by possessing certain knowledge about one risk or one activity, and then passing that information on to another team member or project so that this information can be used for further benefit. 

By knowing the people and the risks associated with achieving the project objectives, the risk professional sits at the centre of an incredible web of knowledge that transcends traditional functional and project barriers. Such knowledge confers with it a degree of power. Using that power for the benefit of the project teams should be an aspiration for every project risk manager. 

In my experience, the best way to manifest the power of knowledge is to share it openly. Where others cling to knowledge in defence of their indispensable position, risk professionals should openly embrace sharing knowledge across the organisation and beyond. In so doing, they become an in-demand resource. During my career, I pivoted the perception of the risk management profession from being another bureaucratic box-ticker to being a highly sought-after and valued member of the team simply through being regarded as a helpful source of knowledge. 

In Closing: 

Right processes and tools to enable these principles 

All five of my personal principles are supported to some degree by quality risk processes and software tools. If the risk management processes are not yet in place, then it is highly recommended that you assist in defining and implementing them. Similarly, good quality tools should be found that support each of the elements. 

Safran Risk Manager is one such tool that will enhance your project risk management capability.  Its secure, easy-to-use, feature-rich functionality will enable each team member to access and maintain risk data across all of the company projects, and manage the treatment actions for which they are responsible. 

The unique CADEC (Change, Assumptions, Dependencies, Exclusions and Constraints) feature in Safran Risk Manager enables registers of these sources of uncertainty to be maintained alongside other risk data such as project phases and project objectives to aid in the contextualisation of the projects. 

Predefined metrics are built into the powerful real-time dashboard, enabling instantaneous results to be derived from the risk register. Within the dashboard, remarks and recommendation features enable the risk professional to capture their own interpretation of the results for onward communication to senior managers, without the need for them to interpret the charts themselves. 

Finally, features such as the global risk library can enable risk professionals to gather and curate common risk information from across the organisation to support their knowledge dissemination role. 

• Supports the project team in achieving their project objectives 
• Provides powerful features to keep projects across the organisation on track 
• Empowers risk professionals to contribute significant value to their organisation.