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-thanadequate 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.