If a risk is going to be adequately managed, it needs to be defined. Failing to describe the actual risk (or risks) will almost inevitably lead to project failure and will frequently exacerbate the damage.
In recent times, there seems to be an explosion of documents in the public domain, including academic papers (where one would have hoped the reviewers and editors knew better) listing as ‘risks’ factors that cannot ever be risks. The ‘fact’ hides the real or consequential risks that may be manageable.
Risk 101 – a risk is an uncertainty that may affect a project objective if it occurs. For something to be a risk, there has to be an uncertainty and the uncertainty may have a positive or negative impact on one or more objectives (see more on risk management). Risk management involves balancing the uncertainty, its potential impact and the cost and effort needed to change these for the better. But to do this you need to focus on the uncertainties that can be managed.
One of more frequently miss-described risks is ‘technical complexity’. The degree of technical difficulty involved in a project is a FACT that can be measured and described! Some projects such as launching a space rocket are technically complex, other less so; but NASA has a far higher success rate in its rocket launches than most IT departments have in developing successful software applications that achieve their objectives. The technical difficulty may give rise to consequential risks that need addressing but these risks have to be identified and catalogued if they are going to be managed. Some of the risks potentially arising out of technical complexity include:
- Inadequate supply of skilled resources in the marketplace / organisation;
- Management failing to allow adequate time for design and testing;
- Allowing technicians to ‘design in’ unnecessary complexity;
- Management failing to provide appropriately skilled resources;
- Management lacking the skills needed to properly estimate and manage the work;
- Etc.
Another common risk in many of these pseudo risk lists is ‘lack of senior management support’. This is a greyer area, the project team’s perception of management support and the actual level of support from senior management may differ. Developing an understanding of the actual attitude of key senior managers requires a methodical approach using tools such as the Stakeholder Circle. However, even after defining the actual attitude of important senior managers the lack of precision in the risk description will often hide the real risks and their potential solutions or consequences:
- If there is a real lack of senior management support the project should be cancelled, its probability of failure is greater than 80%. Continuing is simply wasting money.
- If the problem is senior management failing to understand the importance of the project, this is an issue (it exists) and the solution is directed communication (see more on directed communication). The risk is that the directed communication effort will fail, leading to project failure, this risk needs careful monitoring.
- If the problem is a project sponsor (or steering committee) who is not committed to project success and/or a sponsor (or steering committee) lacking understanding of his/her role (see more on the role of a sponsor) this is another issue with a solution based in education or replacement. Depending on the approach to resolving the issue (and its guaranteed impact on project success if the issue remains unresolved) the risk is either the necessary education process may not work and/or poor governance and senior management oversight will allow the issue to continue unresolved – these specific risks need to be explicitly described and acknowledged if they are to be managed.
The first step to managing risks effectively is developing a precise description of the actual risk that requires managing. If there are several associated risks, log each one separately and then group them under a general classification. The description of each risk is best done using a common meta language such as:
- ‘[Short name]: If a [description of risk] caused by [cause of risk] occurs, it may cause [consequence of occurrence]’. For example:
- ‘Storms: If a heavy thunderstorm caused by summer heat occurs, it may cause flooding and consequential clean up’.
For each risk you need to:
- Define the risk category and short name;
- Describe the risk using an effective ‘risk meta language’;
- Determine if the risk is an opportunity or threat and quantify its effect;
- Prioritise the risk using qualitative assessment process;
- Determine the optimum response;
- Implement the response and measure its effectiveness (see more on risk assessment).
A simple Excel template such as this can help: http://www.mosaicprojects.com.au/Practical_Risk_Management.html#Tools
Managing issues is similar, the key difference is the consequences of an unresolved issue are certain – the issue is a fact that has to be dealt with (see more on issues management).
There are a number of factors that can cause both risks and issues to be improperly defined, some technical, most cultural. Three of the most important are:
- Dealing with easy to identify symptoms without looking for the root cause of the risk / issue (see more on root cause analysis).
- A management culture that does not allow open and honest reporting of risks and issues; preferring to hide behind amorphous descriptions such as ‘technical complexity’ rather than the real risk ‘management’s inability to manage this level of complicated technology’.
- Failing to allow adequate time to analyse the stakeholder community using tools such as the as the Stakeholder Circle so that the full extent of risks associated with people’s capabilities and attitudes can be understood – these can account for up to 90% of the actual risks in most projects.
Management culture is the key to both allowing and expecting rigorous and honest assessment of risk. One of the key functions of every organisation’s governing body is to design, create and maintain the organisation’s management culture, this is a problem that starts at the top! For more on the roles of governance see: http://www.mosaicprojects.com.au/WhitePapers/WP1096_Six_Functions_Governance.pdf.
Pat Weaver
Lynda Bourne
Aavssitedev's Blog