Issues, Risks and Assumptions

							                      Issues, Risks and Assumptions, What is the difference?
Issue
An Issue is an unresolved item (point of question, debate and/or dispute) related to a deliverable, Project and/or
Programme.

Risk
All projects have risks, some will be acceptable, others need managing or resolving. A risk is something which may lead to
failures in elements of the programme. "Acceptably" is as judged by the customer in the final analysis, but from an
organisation's perspective a failure is anything accomplished in less than a professional manner and/or with a less-than-
adequate result.

Risk vrs Consequence
A Risk can have one or more Consequences (or impacts), which have some measurable cost to the organisation. It is here
that the important distinction between a Risk and Consequences is made. The Risk is in essence a description of an event
that has not occurred, but has some likelihood of occurrence. The Consequence is a measure of the cost after the Risk event
is triggered.

Risk vrs Issue
Thus, while an issue is something related to the deliverables/Project/Programme that is currently unresolved (e.g. a
requirements specification needs to be produced but there are no resources to do it), a risk is a potential consequence on the
projects success (e.g. not knowing whether real time is a requirement for a data warehouse project may jeopardise the
future proofing or cost and therefore success of the project). The Project Manager needs to consider whether a current issue
is a potential ‘risk’ to the successful delivery of the project.

Assumptions
These are the soft issues and risks of the project. An assumption is where an issue/risk is accepted with a ‘best guess’
resolution. Assumptions are associated to an issue and does not exist in isolation. An assumption is made simply to carry
on with the issue outstanding and therefore does not replace and issue.
___________________________________________________________________________________
Summary
An assumption provides a temporary work around to Issue/Risk(s). It is for the Project Manager to determine the level of
risk the issues (including those with assumptions) have on the successful delivery of the project.
___________________________________________________________________________________
Recording

Probability
The difference between issue and risk is probability – an issue is current and a problem today, a risk is something that may
happen in the future (this probability is often estimated on a risk logs).

Level of Impact
From a recording viewpoint the level of the ‘problem’ affects its categorisation. Generally:
 Assumptions will be used to temporarily ‘resolve’ an issue at the deliverable level e.g. a Business Requirements
    specification may assume that 9-5 work day support is required. This assumption does not delay the deliverable and is
    unlikely to affect the Projects success at this stage.
 Unresolved issues will usually affect the success of the deliverable e.g. it is an issue that the Business do not have
    enough time to speak to the Business Analyst.
 Risks are potential issues that may affect the ultimate delivery of the project e.g. there is a risk that the project will be
    delayed as the Business may not agree the change.

Suggestion: Issues are recorded with priority and assumptions – thus a lower level issue such as to the support
requirements will have a low priority in the Business Specification stage and assumption (e.g. 9 to 5 working days). The
priority may increase significantly if responses to tenders can only provide this support and not, say 24x7. The PM would
identify if issue(s) may jeopardise the projects success and whether an associate risk should be raised. If Issues can be
maintained at the project level they have visibility across the stages and it is easier to monitor changes through the project –
as in the case of the requirement for support (low priority Business Requirements stage, but high at ITT stage).

Target Audience
Issues and Risks are generally prioritised1 influencing the level of reporting. Sometimes the prioritisation indicates its
escalation level/target audience, thus generally:
  Issues will be raised and changed to Assumptions at the deliverable level
  Project Managers will usually be involved with unresolved high priority issues and consider/raise any associated risk

1
    Usually based on (potential) consequence
    Project Board would be involved with the Risks.

Issues and Risks can be cross referenced, as separate, or the same list, but would all have priorities, thus for instance PM’s
would be involved in resolving high level issues, the Project Board would only deal with the top 10 risks.

Extracts for Reporting on Issues and Risks:
Maintain at least 2 'levels' of register, in line with the Governance Structure.
Define them arbitrarily as High & Low level.
A High level issue or risk is a 'programme level problem', something that the team itself cannot fully mitigate or control,
and the number of Issues/Risks on the high level register should be carefully controlled !
     A typical project Issues Table would probably contain the following columns:
          Ref No (Unique reference number within the project).
          Originator (The person who raised the issue).
          Owner (The individual who currently owns [the resolution of] the issue).
          Issue Description (Detailed description of the issue).
          Issue Impact (Include Costs).
          Issue Level (H/M/L - suggest level within the programme that the issue needs to be resolved).
          Priority (H/M/L - suggest action required within 48 Hrs/5 days/>5 days).
          Status (N/O/C - New, Open, Closed).
          Required Action (Detailed description of all actions required - probably bulleted - to fully resolve the issue,
              with dates where appropriate).
          Resolver (The individual who executes the required actions)
          Action By Date.
     A typical project Risk Table would probably contain the following columns:
          Ref No (Unique reference number within the project).
          Originator (The person who raised the issue).
          Owner (The individual who currently owns [the resolution of] the issue).
          Risk Description (Detailed description of the Risk).
          Impact Description (Detailed description of the Impact of the risk)
          Risk Level (H/M/L - suggest level within the programme that the issue needs to be resolved).
          Probability (H/M/L - the probability of the Risk occurring - suggest >70%/70-30%/<30%)
          Impact (H/M/L - on timeline or cost - suggest >15%/15-5%/<5%)
          Current Ability to Mitigate (suggest 48 Hrs/5 days/>5 days - you may not be able to or may not want to
              mitigate against High Probability/High Impact Risks at this time)
          Cost if Occurs (suggest a financial measure is attempted)
          Cost of Mitigation (suggest a financial measure is attempted).
          Status (N/O/C - New, Open, Closed).
          Required Action/Update.
          Mitigation.
          Contingency.
          Resolver (The individual who executes the required actions).
          Action By Date.

These could be categorised e.g. programmatic, technical, cost, schedule, supportability. There also needs to be clarity with
the risks as to whether to include those:
 1. inherent in any such project/programme e.g. one part of a release not being ready on time
 2. acquired i.e. those related to the specific approach being taken in this instance.

Some policy statements refer to Risk and Compliance and have similar registers for both. While both need to be identified
and managed, they are separate and compliance (or non compliance) is likely to result in an associated risk.