new topic 2 – Risk/Issue

So. What is the difference between a Risk and an Issue.

We looked a little bit at this in the Introduction, but let’s explore it a bit more to be really sure we:

• are sure we know the difference
• can apply this understanding to how we go about managing the Risk & Issue Log.

Risk

A Risk is something which you feel there is a reasonable chance, might happen. Something negative.

There’s an almost ‘default’ set of Risks, so let’s set some of them out here that you would typically see:

Resources

• Organisational resources can’t be released from the day-to-day tasks of their BAU role
• not enough resources in total
• not enough of the right resources with the right skills
• not enough of the right resources at the right time
• not enough due to sickness absence (routine or mass absence eg Covid-related)
• resources leaving
• poor service from recruitment agency in supplying resources
• Not possible to build project plans with named resources assigned due to significant resourcing gaps

Project itself

• Project purpose/goals/objectives not clearly defined
• Assumptions not articulated
• Scope not clearly defined/scope creep
• Lack of core project documentation eg Business Case, Project Initiation Document, Risk & Issue Log
• No Benefits Realisation Management approach defined/implemented
• Governance mechanisms not defined/agreed/communicated
• Delays supplying kit to contractors impacts onboarding progress

Contracts

• Consultant/contractor/SME delays for contractual reasons
• Resource provider eg Recruiter not delivering as per contract causing resourcing issues

Schedule

• Project purpose/goals/objectives not clearly defined
• Scope creep impacting project schedule
• Pressure to truncate tasks/reduce agreed Deliverables impacts quality and benefits realisation
• Dependencies not well understood/articulated in plans/managed

Stakeholders

• Not all stakeholder groups are fully defined yet
• Stakeholders not on board with the project and reluctant to be involved

Technical

• Testing undefined/insufficient and likely to lead to high volume of calls to Service Desk post-Go Live

External

• Events such as extreme weather
• Inability to obtain physical project resources eg equipment, materials, or theft of
• Loss of a premises including ancillary resources eg car parking
• Issues with staff unions/strike action/staff leaving due to the project
• Change in legislation/regulation impact the project

The above list is not exhaustive – there will be more or different Risks to those shown above, but this gives a flavour of some of the areas you might expect to see in some form. In selecting any of the above to go into our Risk & Issue Log, you’re saying “I think these things could happen, they haven’t happened yet, but they could happen”. And that makes them Risks.

Issues

There are two ways we arrive at having Issues in our Risk & Issue Log.

1.

An existing Risk (which we know is something that might happen), actually happens. So let’s take this Risk as an example:

Not possible to build project plans with named resources assigned due to significant resourcing gaps

We’d said it could have a high impact preventing the creation of project plans with named resources assigned to each of the required tasks if we didn’t have enough known, named resources to enable this to be done. We said that could cause a delay of 2 or more weeks to key tasks affecting one or more key Deliverables.

So now, we are at the point where all our efforts to rectify the situation have failed and we’re two weeks behind, and one or more Deliverables are being delayed as we predicted might happen.

So the what we said could happen, despite the Mitigating Actions we applied, has now actually happened.

This is now an Issue, it is no longer a Risk – because it has happened.

On the Log we would therefore note in our update comments that it’s become an Issue and we would change it from Risk to Issue.

2.

A totally unforseen Issue happens, without warning, for which we have no plans in place, no Risks yet recorded; it’s totally blindsided us.

This could happen – we can only anticipate so much what issues may arise in a project and it’s not always possible to predict everything. It was Donald Rumsfeld who said:

“There are known knowns, things we know that we know; and there are known unknowns, things that we know we don’t know. But there are also unknown unknowns, things we do not know we don’t know.”

Donald Rumsfeld

For the most part, we’re typically pretty good at recognising an emerging problem whilst it’s still at the Risk stage – we’ve not logged it yet, but we can see it on the horizon, so we capture it as a new Risk and we successfully manage it so it doesn’t turn into an Issue. So coming across an Issue that had never ever been considered is more unlikely and far less common then just a Risk developing into an Issue, despite having applied all the mitigating actions to the best possible level.

This will be a good point for the Owner to make sure that Log reflects this change and it’s documented, to go ahead and review their mitigating actions, and decide if they want to alert the SLT (Senior Leadership Team)/Project Board for information / guidance / escalation.

Issues are inherently ‘worse’ than risks because they are impacting as we speak, they are no longer something that might be happening, they are happening.

Can an Issue become a Risk?

Yes.

This is part of the lifecycle of Risks/Issues and how they relate to each other. We already said how a Risk can become an Issue if the predicted impacts actually come to bear.

If we can managing that Issue, apply more / other mitigating actions and successfully bring that Issue down from being a Red, very serious, Issue, to a low Amber, well under control – with the agreement of project colleagues/SLT/Project Board, it may be possible to decide that it’s no longer constituting an Issue and it can be returned to being a Risk.

Can some Issues remain until the end of the Project?

Yes, some can, some won’t.

As a really key date in a project gets closer – we’re talking something major like a Go Live on a huge new system integration across 10 hospitals – there will be quite a number of active Issues at Red or Amber. Effectively, these Issues have to remain as Issues – until the Go Live happens. Because if you read each of them, they will all include the following wording “…. could impact Go Live” or “…could prevent Go Live”. Once Go Live happens, it’s happened, so the Issue can no longer impact Go Live – because it’s now happened. We hope nothing did actually affect or stop Go Live and it all actually happened smoothly. What we may need to do though is look at any individual aspects that aren’t necessarily just Go Live-specific, which still remain, and may need ongoing management after Go Live.

So you’d review any Issues like this, that were heavily tied to the Go Live, see which ones can be removed and what new mitigating actions are needed, what rewording and re-scoring might be needed, and whether it continues to be an Issue, or is now better classified as a Risk.

Alternatively, an Issue may not be tied to a single key date or single key activity, but it might be an issue, over and over, throughout the project, the same thing causing the issue, but in different ways at different times. A good example of this is resourcing issues – let’s say, difficulties in staff in the organisation being able to find time for project-related commitments. At any time this could affect:

• their ability to attend critical workshops
• their ability to attend training
• their ability to attend testing sessions
• their ability to find time to play around in the system in the sandbox environment provided

So these are issues which rumble on throughout multiple phases and there’s no one single date where the majority of those impacts instantly disappear – the impacts of not being able to attending trainingor play around in the system sandbox environment to get familiar with the new software, are impacts that could well continue to need to be managed after Go Live – maybe mop-up training sessions and other support which could continue for weeks until everyone who hadn’t had chance, could catch up with these activities. Only once absolutely everyone is shown to have attended the required training sessions, possibly weeks after Go Live, can that Issue be closed.