I am pretty sure this article is going to raise some questions, even hackles, as it is a rather an emotive subject. However, it is very important that we understand why Risks and Issues are different, particularly when it comes to how we handle them. Let us look, firstly, at the key definitions of the two.
What is Risk?
A Risk is an event that may happen in the future (an uncertainty) and, recognizing that, allows it to be managed: (consider some action and plan that action) - Proactive
What is Issue?
An Issue is happening now or about to happen and there is NO management plan in place. And so whoever needs to be involved with the resolution can only Respond - Reactive
Now, let us consider what a Risk really is – it is a “potential issue” that has been identified, that MAY happen in the future. The “MAY” is one of the key differentiators here, and because we have picked up this “potential issue” early we can be Proactive and put some response in place.
Good, active and continuous Risk Management activities will reduce the number of occurrences of issues and their impact as they are now managed as a Risk so never become an Issue.
Manage a Risk – proactive
Respond to an Issue – reactive
Types of Risks
(Note: here I am not looking at the different levels of Risk, as in the ISO 31000, more of a broad understanding of Risk)
When working in a Project environment the risks we may (most likely will!) encounter here are defined with respect to the “uncertainty that should it occur could/will have an impact on the ability of the project being able to achieve its objective”.
So Project Risks remain within the project time-frame: once the project has been closed, the risk no longer exists in this capacity (as we no longer have a project objective!). When running a project, this is the type of risk we are concerned with:
- Risks are managed – that is a response is put in place – see my YouTube video that defines Risk Management and Risks in more detail.
- Risks can be Threats and/or Opportunities (and/or because this depends on the perspective of who perceives the uncertainty).
- Risks can be tracked and reviewed (imperative) throughout the project – especially at any planning activity.
However, we also have risks that impact on the organization from an Operational perspective. These are not the same type of Risks and also need to be considered at different levels. Project is Project level! Operational risk can be from the “engine room” (where the BAU work is carried out) right up to Strategic level (Enterprise Risk). These risks have a broader impact on the organization as a whole.
Types of Issues
Let us have a look at what an issue is and how it materialises.
An Issue can be:
- Part of an objective (or even the full objective!) that has not been delivered as originally defined – Off-Specification
- An addition or subtraction of the original Scope - Request for Change
- A Problem, Concern, or similar, that comes “out of the blue”
Now, for the first point (even the second), if the change initiative is being driven with real “agility” then these types of issues could almost be avoided/reduced/handled differently – NOT because of “empowerment” or Prioritization (in the main) but because of more direct Business Involvement. “Agility” at Project/Programme level AND at “Development/build” level. (another discussion!)
Unlike Risks that can be tracked throughout once the uncertainty has been recorded, an Issue comes out of the “Blue” and as such not is tracked in the same way as a Risk, the latter for which the response should already be underway and therefore tracked.
In each of the above situations, there needs to be a management response (means getting people out of their current activities to deal with it). No plan has been put in place. (As an example watch this video).
This will be in the form of some level of escalation depending on the level of “authority” (empowerment if you like) that has been defined at each level of the “initiative”, from build/development level, through Project, Programme to Corporate!
Another point to note is that issues that materialise during a project are initially reviewed with respect to the severity and impact on the project objectives, however, unlike risk (which are really reviewed and managed purely from this perspective), an issue can, (and often does) pass over into the Operations/BAU environment.
Such an issue may not be able to be resolved within the Project Timeframe and it is not a critical requirement that it is (will not have an impact on the objective), however, it will need to be resolved in the Operations/BAU environment and that – a key point here – the issue is accepted as part of the resolution and so “hand-over”, that it is to be resolved in the “Live” environment. Risks are NOT passed on. Once the project is closed, so are Project Risks.
Keeping the handling of Risks and Issues Separate
It is imperative that Risks and Issues are recognised, documented, tracked and handled differently and separately. There are a number of reasons for doing so, and I have laid these out below. When they are not handled this way there is, ironically, a big risk. I have pointed out the approach taken for the two types of project impact at the beginning of this article. Risks are “managed” because when we are aware of something before the event we can plan, hence manage. When something happens unexpectedly, an Issue, we can ONLY respond to it as no plan is in place. This the first and rather vital difference. The second is reflected in the last paragraph discussing types of Issues.
Issues, can, do and often are passed on in the Live environment, however, as also noted, it is imperative that this is an acceptable scenario (in fact, there is a post on this note of acceptance and working together as a “collective”), and that Operations have agreed to take this issue on! Thirdly, and more related to Programme Risk rather than just project risk. When there is a Risk that has been identified that relates to more than one project in a programme, the risk MUST be tracked as ONE and as a RISK throughout the programme.
For example, Project 3 and Project 6 in a programme could be impacted by the same risk, even though they are scheduled to run at different times during the programme time frame. Like a part delivery of equipment! If the Risk materialises for Project 3 and this is then moved (or worse doubled in both registers/logs) from the Risk to the Issue register/log, then this causes a risk itself. If it is MOVED to the Issue register/log, then Project 6 loses sight of it as a Risk, as it is now being tracked as an Issue, - NO, do NOT do this! Or, as noted above, doubled (both risk and issue register/log), then where is the correct information, are we tracking two things here now, Risk and an Issue? NO again! Or worse, the Risk is closed, as it is resolved for Project 3, yet It is still alive for Project 6!
In other words – a Risk is a Risk and NEVER an Issue
Now there are some other points to note here:
- A Risk response (not adequate or just because of the response) could initiate an Issue OR Residual Risk (if realized at planning/reviewing it might not be adequate) or Secondary Risk (this is ANOTHER risk, again realized at the time of planning/reviewing)
- Responding to an Issue could also raise a Risk as part of that response
- In points a) and b) the ensuing risk or issue is separate to the Inherent
The more Risk recognition and therefore managing that takes place in a project/programme, the fewer Issues the change initiatives are likely to have. Does NOT rule out having issues altogether, very unlikely.
Remember, a Project is a projection of an initiative and how we see it being run and hence can plan. One of the five characteristics of a project, as with anything for the future, is UNCERTAINTY. We CANNOT predict, only anticipate. Those situations that arise “out of the blue”, ISSUES, must be handled differently to those we anticipate may happen, RISKS.
Author Bio
Antony della Porta has experience of over 30 years in the project management profession. He is an established professional in the delivery of strategic business change and an advisor for programme and project recovery with critical systems thinking approach. He has been an Executive Advisor and Director at GPM Global and founded “The Sustainable PM” initiative, which is a platform that is set to help PMs become "sustainable”. He is also an accredited instructor and practitioner for a number of courses in the fields of management and project management.