The objective of the Risk, Issue and Change Management component is to give the PM the necessary knowledge and instruments to be able to face any events that might have an impact on the project’s products, resources, stages or objectives.
In this section both the Risk Management and the Issue and Change Management procedures will be defined as well as the categorisations that can be used to facilitate the identification, assessment and resolution of uncertain or un-forecasted events. These activities are the PM’s responsibility and should be performed in a proactive way.
The PM should actively monitor the project context and environment to identify any possible threat or opportunity and to deal with any problem that may have an impact on project progress. Additionally the PM must plan how these activities will be performed during the project as well as documenting any standards and policies to be applied.
The procedures, tools, techniques and responsibilities involved in the Risk, Issue & Change Management activities will be documented in the Risk and Issue Management Plan created during the Project Initiation process.
Although the procedures to deal with them are similar, Risks and Issues are different in nature. A procedure for each is outlined in this section. Furthermore, as the impact of Risks or Issues might result in a deviation from the forecasted tolerance levels, the Exception Procedure is also covered in this section.
Both the Risk and Issue Management procedures are a PM’s responsibility, however, it is extremely important for their correct application, that the correct people are involved during the various steps of the procedure to help the PM with decision making activities, impact and probability assessments and overall monitoring of the effect of the events on the project objectives to ensure project success.
A risk represents an uncertain event that could have an effect on the project objectives. This uncertainty is measured in terms of the probability of the risk and the possible impact the threat or opportunity might have on the project. The effect of the event on the project could be either beneficial or damaging and for this reason when approaching Risk Management, which covers both threats and opportunities, the PM should be aware of the differences between Threat Management and Opportunity Management.
The PM is responsible for all the risk management activities during the project. To help with these tasks the PM4SD model suggests a systematic proactive approach to risk management carried out following a structured procedure.
Risks need to be Identified, Assessed, and Controlled taking into account the nature of the risk itself, the project context and complexity, and the objective at risk; furthermore, adequate responses need to be planned and where the case might require it implemented. The PM is assisted in carrying out these steps by an appropriate cross-section of project stakeholders.
Before proceeding with any risk management activity he PM should be aware of the acceptable risk exposure for the project as stated by the Corporate or Programme Organisation as this knowledge will provide the basis for any impact analysis that will be performed.
This level can vary from project to project and is subject to external influences such as legislations, commercial factors, policy, socio-economic considerations or stakeholder involvement-preferences. Since this attitude towards risk taking can be strongly related to subjective preferences the PM should be prepared to review the situation at regular intervals, to make sure the Risk Management activities he is performing are still in line with the objectives of the project.
Risks need to be identified and recorded in the risk log. All stakeholders, Team Managers and people involved in the project have the responsibility of informing the PM of any Risks which may have an impact on the project’s objectives.
Before identifying any risks, the PM leads on the identification of the context of the objectives at risk. The context may be the whole project to identify high-level risks, with a focus on the project plan and interdependencies between stages. If the context is the creation of a stage plan then particular attention should be paid to those risks likely to impact the stage being prepared and the relevant products and objectives.
Once the context has been identified the PM should proceed to identify the known sources for risks. For example the knowledge of an imminent increase in the tax rate from the national bank might help us identify financial risks which we might have not considered. The risk identification step results in a good description of a risk including a description of its source and impact.
Once a Risk has been identified the PM should seek the support of appropriate people, stakeholders, project board members in order to ascertain what the probability (the likelihood of the event occurring) and impact (effect of the event on the project’s objectives) of the event will be for the project. This includes an impact analysis which takes into consideration all the objectives that might suffer from the occurrence of a risk, paying particular attention to the impact the risk will have on the Business Case and the Plans.
Furthermore the PM should also consider the Proximity value of the risk expressed in temporal terms from the moment the event is identified until the moment in which it will no longer have an impact on the project’s objectives and/or benefits (typical proximity categories would be “imminent” “short term” “ long term” “post project).
Albeit a PM responsibility, Risk Assessment is performed by the PM in collaboration with the relevant stakeholders who might be called to make decisions regarding plans to respond to risks or who might have the authority to decide what king of priority risks with a specific strategic, political, socio-economical
Once the probability impact and proximity for a risk have been assessed the PM would work with the stakeholders to plan suitable responses to manage the risk. Actions taken to manage a risk, e.g. actions to reduce the likelihood of it occurring, can give rise to further risks which could impact on the project.
The risk must be kept under control and reviewed regularly to ascertain the continued validity and success of the planned response or else to plan a new action.
Responses to risks are of two types: Proactive responses (implemented regardless of the risk occurring or not and often aimed at avoiding or reducing the chance of it ever occurring) and Reactive responses (implemented once the risk has occurred).
Activities to respond to a risk event must be assessed for their own impact on the project as they may give rise to further risks such as additional costs for the project (some projects may provide for this instance and allow for a risk budget to be added to the project original budget).
To facilitate the selection and the assessment of a response impact the PM is encouraged to categorise the responses as follows:
- Prevent: Eliminates the Risk completely.
- Mitigate: Reduces the Impact and/or Probability of the Risk occurring.
- Transfer: Transfers the financial impact of the Risk on a third party.
- Contingency: Provide for an alternative should the risk materialise.
- Accept: No response will be implemented
- Exploit: Take advantage of the opportunity
- Improve: Increase the likelihood of the opportunity occurring.
- Reject: The opportunity will be discarded.
The PM might not have the technical knowledge or skill to manage all the possible risks in a project particularly where the risk is related to technical aspects of the development work. To help with this the PM4ESD model provides for the use of additional roles used specifically in the Risk Management activities
The Risk Owner
- The risk owner is the individual with the best profile to manage the specific risk during its life cycle in the project
The Risk Actionee
- The risk actionee is the individual with the best profile to implement the planned response actions
ISSUE & CHANGE Management
To facilitate the PM in dealing with unforeseen events the Issue Management procedure outlines a structured yet efficient and agile way to respond to problems as they arise
The PM needs to categorise each issue according to its impact. This facilitates the identification of suitable responses, including the use of matrices or past lessons documenting the resolution of similar issues. The issue categories are:
- Change Request: a formal request to change an approved (Baseline) product or aspect of the project.
- Off-Specification: a non forecasted discrepancy between a product or aspect of the project from their planned description
- Problem/Question: any other event that impacts the project
Although issues can be managed in both a formal or informal way (depending on their nature, impact, and level of authority delegated to the PM) there are some instances where a formal procedure must be applied (Change Requests impacting Baseline products, Issues that are considered outside of the PM’s remit as per contractual agreements, policies, applicable standards).
The issue and change management procedure provides for the issue or change to be captured, categorised and recorded in the Issue Log.
Following the identification of the issue the PM must proceed to the priority and Impact assessment to ascertain the effect the issue has had or will have on the project objectives and to verify whether this impact is an exception situation or whether it can be resolved within the delegated authority and the stage/project tolerances.
Following the impact assessment the PM will proceed to find a suitable response before proposing it to the deciding authority.
Once a decision has been made on whether the response can be implemented, the PM will take any corrective actions planned and update any relevant documentation.
For major or complex issues, the PM might seek the help of external resources (ie. Stakeholders) to deal with the issues. A possible change budget might be planned as part of the project budget to cover any unplanned corrective actions arising from an issue.
The Management by Exception principle is always applicable and it stipulates that the PM might carry out activities and take decisive actions only as long as the combined impact of the event and its resolution remains within the assigned tolerances, in other words, within the PM’s own delegated authority level. Once this condition fails the Exception Procedure must be used:
- Issues, risks, stage assessments, external factors, changes in policies etc. can all cause a deviation from the forecasted objectives of the project. When this deviation takes the project outside the agreed tolerances (Project, Stage or even Work Package) an Exception situation occurs.
- Once recorded as an issue, the PM will proceed with the assessment of the causes and effects of the deviation on the projects, paying particular attention to the impact assessment on the Business Case, Plans, Resources, Long Term Benefit realisation and Sustainability aspects. Once the impact analysis is done appropriate solutions should be identified and their impact on the project should also be assessed before recommendations are made.
- When an actual or forecasted deviation from tolerance levels is identified the PM should report it via an Exception Report to the Project Board outlining the reasons for the exception, the assessment of the impact, the possible solutions and the PM’s recommendation.
Plan Exception Stage
- The Project Board will assess the report and make a decision on the most suitable solution proposed before asking the PM to provide a plan (an Exception Plan) outlining the implementation of the solution and the new outlook for the stage/products/objectives affected.
This request triggers the Stage Definition and Planning process as the PM will close the current stage at the moment of the identification of the exception and request an extra stage to be authorised (an exception stage) to replace the remaining unfinished stage.
Before the exception plan can be authorised, a control point will be required to assess the continued validity of the project and to update all the relevant documentation (paying particular attention to the Business Case and the Project Plan) to reflect the new outlook and to propose updated forecasts following the exception situation.
The Exception plan must be submitted to and approved by the Project Board, as for a normal Stage Plan. Provided authorisation is granted the Stage Control & Product Delivery process is triggered and the project proceeds according to the new plan.
Please refer to the Document Templates section for information regarding the contents of the Risk and Issue Management Plan, Risk Log, Issue Log, Exception Report.