Risk & Issue Management Tasks

Identify and make initial assessment of risks to the idea.

Identify potential risk impact on other parts of the portfolio.

Identify risks – discuss with key stakeholders. Consider holding an initial workshop involving key stakeholders (those promoting the idea, those who will have to implement it, those running the service area affected), to identify and capture key risks associated with the idea.

Also, remember to look at potential risks to other projects or activities that this new idea might create

Look at how risk are shared with funding or partner organisations – has the right mix of risk and reward been achieved in the proposal?

Assess risks – estimate cause-event-effect, evaluate probability, impact, and proximity.

Make an overall assessment of the “riskiness” of the idea (if appropriate, do this for each participating organisation too), which should be included in the business case alongside the costs and benefits to enable an overall judgement of desirability to be made at Decision Gate 1.

Identify and make initial assessment of risks to the idea.

Identify potential risk impact on other parts of the portfolio.

Check the risks, the could be positive or negative and consult with key stakeholders who may have a view,  a workshop on developing the idea should consider the risks that could come about.

Also, remember to look at potential risks to other projects or activities that this new idea might create, there will certainly be knock on effects somewhere.

Make an overall assessment of the “riskiness” of the idea, which should be included in the business case alongside the costs and benefits to enable an overall judgement of desirability to be made at Decision Gate 1. The Strategic Assessment Framework should be able to address this.

Clarify the obstacles that will be faced.

No change will be plain sailing, so it is important to record the challenges as risks and prepare for any potential issues (problems) that you will face.

Issues are problems you know you will face, risks are less predictable and you will need to think about them, better now than later.

At this stage, a simple list of obstacles  is sufficient.

Ensure the risks to the idea are documented in the risk register.

Risk probably the most important consideration at the moment.

Having a clear understanding of the risks is important to balance any over-enthusiasm for a good idea.

Equally, be careful that cold water isn't being poured over an idea unnecessarily so make sure that the opportunities (positive risks) are being presented as well to ensure there is a balanced view.

Complete Risk Profile Assessment

The Risk Assessment should be reviewed by the board to ensure that there is an overarching assessment of the level of risk.

The RPA will define the level of control and the delivery route that is required to ensure success.

Ensure known risks linked to the initiative are logged.

Ensure strategic risks are included in the brief.

Review aggregating effect of project risks if it is a programme.

The brief offers opportunities to head off resistance by including clarification, equally avoiding key issues may avoid early resistance but this may return to haunt the programme.

Acknowledging major risks in the vision will help the audience appreciate the reality of what is being aspired to.

Watch out for aggregating project risks that a common across the programme as these may be better managed at the programme level.

Programme level risks are principally associated with:

• Strategic alignment
• Levels of operational change
• Inter programme dependencies
• External events beyond the programmes control

There should be an up to date Risk Register in your organisations format. 

The risks listed should reflect both the short and long term risks. The risks should be related to delivery and the impact on the areas that will be affected. The risk profile has been updated and is still acceptable.

Assess the overall financial risk profile of the portfolio.

Ensure this is monitored through regular risk reviews at project, programme and portfolio level.

Ensure risk capacity and risk appetite are defined and communicated and that the mechanisms for financial evaluation are effective.

Look out for the cumulative effect of risks, and for secondary risk arising from actions and decisions are being valued.

Stakeholders have different perceptions of risk, and can help identify risks and possible solutions and funding options.

Establish risk appetite. The risk appetite for the portfolio should be reviewed for impact on benefits achievement.

Test that the risk profile of the benefits is realistic and being updated.

The level of risk associated with the benefits forecast at project, programme and portfolio level should be monitored.

The portfolio is likely to contain a balance of projects with different risk profiles (i.e. some high risk/high reward as well as some low risk/low reward projects)

The risk appetite will affect the ability to gain benefits. So if there isn’t an appetite to deal with big risks such as public opinion, then the ability to achieve risks will be reduced.  Consequently the risk appetite should be a driving factor in the level of ambition attached to benefits.

High risk benefits should be monitored closely.

Ensure risks of non-compliance are captured.

Compliance projects can be implemented in different ways that have different risks within the options. Investment appraisal should consider the relative risks (threats and opportunities) for different implementation options.

Review the risk profile relating to the rate of business change.

Check the overall risk profile of the portfolio and review on a regular basis.

Check for root causes that are undermining the rate of change and revise mitigation plans.

Assess effectiveness of dependency identification and management.

Encourage and reward an open culture in which everyone is encouraged to report, raise and discuss risk at all levels. Suppressing risks benefits no-one. The earlier risks can be identified, the better the chance of addressing and overcoming them.

Deep dive exercises can help identify root causes of risk. Use the “cause-event-effect” formula to get a deeper understanding of the root causes.

Failure to identify and manage dependencies effectively can lead to significant delay and cost escalation within the portfolio. Regular communication across the portfolio will increase visibility and enable improved performance.

Identify and allocate mitigation actions for risks that will be created when programme is closed.

Ensure that existing risks have owners post programme closure.

Update Corporate risk team on residual risks.

Review programme risk effectiveness.

Include risk lessons learned in the closure report.

The Issue Log will need to be reviewed to identify which issues can be resolved by the programme, and which will remain once the programme has closed. A plan for bringing early resolution or passing issues to another body needs to be put into place. Ownership of risks that will remain after the programme closes will need to be considered.

Ensure risks have a post programme action plan.

Both the Risk and Issue Logs should be reviewed and closed off.

It may be that some organisational risks have been owned by the programme during its lifecycle.

These now need to be handed over with ownership and mitigation plans put into place.

There are likely to be outstanding issues that may still exist when the programme closes. Not being able to resolve or transfer ownership may lead to delays. A review of project closure reports should be undertaken to ensure there are no outstanding follow on actions or legacy issues and problems that ownership has not been found for. A review of the effectiveness of the Risk Management, Issue Resolution Strategies and supporting processes should be part of the formal Programme Review.

Formalise handover of existing risks to relevant authorities

Evaluate effectiveness of risk performance of the programme

Close the risk register and hand over to the portfolio office

Residual risks should now be actively managed within the organisation’s standard risk management processes.

No issues should remain - they should have been handed over to the operational groups, organisational governance or other programmes or projects to resolve.

The risk appetite for the portfolio should be reviewed for impact on benefits achievement.

Confirm that the all benefits have the right risk rating associated with them.

Assess the impact of specific risks on benefits achievement.

Ensure the opportunity management activities are identifying new benefits.

The risk appetite will affect the ability to gain benefits. So if there isn’t an appetite to deal with big risks such as public opinion, then the ability to achieve risks will be reduced.  Consequently the risk appetite should be a driving factor in the level of ambition attached to benefits.

Each benefit in the programme and projects should have a risk calculation, this will be contributing to your benefit calculations, the application of the risk rating will be affecting the benefits valuation at the project.

There may be specific risks in the portfolio that may be causing a major problem in terms of benefits release, as such, these need to be re-evaluated and new mitigation plans put in place.

Ongoing benefits realisation and other post-project activities will contain a review of benefit related risks.

Ensure known risks linked to the vision are logged.

Vision Statement offers opportunities to head off resistance by including clarification, equally avoiding key issues may avoid early resistance but this may return to haunt the programme.  Acknowledging major risks in the vision will help the audience appreciate the reality of what is being aspired to.

Ensure risks associated with each option are clearly documented.

Analyse any new operational risks identified in the gap analysis.

Prepare mitigation plans for new risks.

This stage should remove some of the ambiguity about some of the risks but it may identify new ones as well.

Additional detail comes out of the evaluation and selection of the blueprint future state, meaning there should be a lot more information available to analyse and profile individual risks in the documentation, so overall, the level of risk should reduce as the understanding increases.

The output of this work may mitigate some risks; this should be factored into the development work.

There are likely to be high and low risk options that will need to be considered. Where information about current performance is missing then this will increase the risk for the programme.

Re-assess the risk profile based on the changed dossier

Culling of projects without proper understanding of value and impact may have long term implications for the programme, positive or negative. As such, these should be recorded as risks.

Tranches should be used to reduce risk where possible.

Define how the tranche plans will affect the risk profile of the programme.

Review the impact on project risks.

This is the start of the formalisation of the programme plan, so the windows when the risks could occur will become clearer and the Tranche plan can be used to manage risk exposures or mitigate risks, so this is an opportunity to lower the programme risk profile.

The Tranche plan will clarify projects that will not be needed but may already be running.

Culling of projects without proper understanding of value and impact may have long term implications for the programme, positive or negative. As such, these should be recorded as risks.

Using step changes reduces big bang style risks and enables avoidance of time bound risks. Selection of the end game and the journey will significantly affect the risk profile of the programme.

The programme Risk Register can now be updated to reflect reduced ambiguity.

Supply chain and operational risks should be included based on preferred option.

The impact of each delivery strategy option should be assessed for the impact on the risk profile of the programme.

Normally each option will have its own strengths and weaknesses but the overall impact on the risk profile will be a key element of the selection of the preferred option.

One of the areas to be captured will be opportunities that are lost as a result of selecting a particular option, so the focus should not just be on negative risk.

If these are logged in the Risk Register then an opportunity may arise to capture the benefit later through some tactical change.

The programme Risk Register can now be updated to reflect reduced ambiguity.

Review the individual major risks.

Scan for aggregating risks.

The overall risk profile should be a key element of the decision process. The Sponsoring Group should have visibility of all the risk and the overall risk profile for the programme, and the plan to mitigate the level.

This is a good point to re-scan (to identify) any new risks or aggregating impacts that had not been identified before.

Viability of existing mitigation plans should be reviewed as well as the effectiveness of the risk management activities so far.

Depending on the nature of the programme, external independent assurance of the risk profile may be required.

Focus on the cross project dependency risks to the programme.

Allocate programme risks mitigation actions to projects where possible.

At this point the project plans and Tranche plan are coming together so the overall map of risks and how they relate can be created, there will be better visibility of dependencies as well.

There may be external risks and inter programme risks that can be better defined and improved mitigation plans can be put into place.

Programme risks can be mitigated by project delivery. Market and organisational capability to deliver the projects should be considered as a risk. Any ambiguity about costs should be seen as a risk.

Complete the risk management strategy.

Consult corporate risk team on the programme approach.

Risk Management Strategy should be designed to define how risks will be managed during delivery, the needs and environment may be different to the design and define stages.

This could be quite a simple step, as the framework guidance should already be in place, the strategy should state this and explain any deviations specific to this programme.

The corporate risk management team should be consulted as part of the strategy development.

This may be integrated into one approach. A key area to focus on is how escalations will work, to ensure that risks are not buried too deeply, and also how risks from the programme will cascade risks down to projects. The other area should be to focus on how aggregation will be measured and monitored.

Risk management plan should be finalised.

Identify and assess any new risks.

Validate current risk profile.

There will be a lot of interaction with the development of the programme plans from other themes as these will be affecting the risk profile, so the risk mitigation plans are likely to be finalised after the other plans.

There should be a plan to fully mobilise and manage risk and issues for the programme.

Refine the programme risk profile.

Update the financial risks and their potential value.

Review aggregated project risks and their financial impact.

Define the required risk budget.

The project should be complaint to the risk management standards in the framework and how the risk management cycle will be used by the project.

The risk profile of the project should be included in the business case, this should be a contributing factor to the management controls, the higher the risk the higher the level of control.

Review the individual major risks.

Review the overall risk profile.

Scan for aggregating risks.

The overall risk profile should be a key element of the decision process. The Sponsoring Group should have visibility of all the risk and the overall risk profile for the programme, and the plan to mitigate the level.

This is a good point to re-scan (to identify) any new risks or aggregating impacts that had not been identified before.

Viability of existing mitigation plans should be reviewed as well as the effective of the risk management activities so far.

Depending on the nature of the programme, external independent assurance of the risk profile may be required.

Ensure the aggregating effect of project and programme risks are tracked.

Establish the risk management framework and monitor effectiveness.

Establish regular risk identification scans.

Undertake risk effectiveness reviews.

Ensure compliance of projects to risk process.

Programme risks can be cascaded down and owned by projects in some circumstances. For other programme risks, projects should be fully briefed to enable them to contribute mitigating actions where appropriate.

Track programme level impacts of aggregating project risks.

Review risk management effectiveness and implement improvements.

Regular review of strategic risk for new or changing causes.

Review the effectiveness of project risk processes.

Update the programme risk profile at each programme board.

Close off risks relating to transitional service stability.

Most of the energy will be focused on project risks and issues. It is important that the programme focuses on aggregating risk and monitoring for similar risks developing across the projects or threats to interdependencies developing. For example, operational risks will be developing that threaten the need or timescales of the projects.

The monitoring of risk should be a continuous process which scans the environment from 4 perspectives - programme, project, operational and strategic (threats and opportunities). Fluctuations of individual risks should be monitored against aggregated threats to the programme. Issue and change control should use the same four perspectives and the focus on resolution must be maintained to stop the programme being overrun with issues.

The project related risks should now be closing down but there will still be those which affect working practices, operational stability and performance. These should be moved to the operational Risk Register.  

The corporate Risk Register may also be updated as the achievement of the new way of working may mitigate a corporate risk that was part of the Business Case justification.

Undertake risk impact assessment of the changes.

Review risk management effectiveness and implement improvements.

Undertake risk identification review of any new programme threats or opportunities as a result of outcomes.

Update the risk management strategy from lessons learned if necessary.

Remove risks have now passed their proximity from the risk register.

At this point the level of change relating to this Tranche should be nearing completion so business stability risks should be reducing or should have passed, so this is a good moment.

The review of risk should look at the current aggregated exposure and the nature of the risks. In particular, the focus should be on the risks that affect the organisation's strategy, the ability to achieve the blueprint and realisation of the benefits.

The effectiveness of the Risk Management Strategy should be evaluated. Effectiveness of the escalation routes and the identification of both risks and issues, along with effectiveness of associated processes, including change control, mitigation plans and general levels of engagement will all enable improvements to be made to the approaches.

A key risk is unexpected operational dependence on systems being removed.

There is a danger that groups who have not transferred or migrated, or a part of the service still depends on the old processes and systems - missing these could cause major embarrassment.

Review the individual major risks.

Review the overall risk profile.

Scan for aggregating.

Review the effectiveness of risk management strategy.

The overall risk profile should be a key element of the decision process. The Sponsoring Group should have visibility of all the risks and the overall risk profile for the programme, and the plan to mitigate the level.

The risk profile will be a key element of the decision to continue or close the programme

This is a good point to re-scan (to identify) any new risks or aggregating impacts that had not been identified before.

Viability of existing mitigation plans should be reviewed as well as the effective of the risk management activities so far.

Depending on the nature of the programme, external independent assurance of the risk profile may be required.

Record risks to the service that the new model or transition may cause.

When considering risks, the most desirable design might carry the most risks, this doesn’t mean that the easier route should be taken but the level of risk needs to be understood and transparent.

Appraisal should track opportunities and threats from each of the options.

Each option should have a risk assessment, looking separately at:

(a) Threats/opportunities to delivery.

(b) Threats/opportunities to benefits and requirements.

Record any lost opportunities that should be tracked and any new threats identified from this option.

The preferred option may require compromise and the loss of some functionality or benefit that would have been useful. Log this as a risk so that it is tracked - an opportunity may arise to achieve this functionality in a different way later on.

Ensure recommended actions relating to risk are dealt with.

There should be evidence that the major risks are being actively managed.

Record risks to the achievement of the Business Operating Model for the project and its transition. 

There will be opportunities and threats identified as part of this activity. There may be organisational or technical challenges that could arise in the future - it is important that these are being tracked and considered. The complexityof  risk will be a factor in assessing the Business Case.

Ambiguities linked to the design should be recorded as a risk. 

During this activity there will be a number of areas of ambiguity arising, possibly from the knowledge of the team or how far the technology can be extended. The ability of the organisation to change to use the new capability is another area of risk, these should be captured as risks and recorded in the log.

Be careful to think about assumptions that are being made in the process, they may not have been recorded.

Update the Risk Register to reflect the increased certainty and any new risks related to the outcome.

There will be a wide range of risks that will need to be addressed, ranging from availability of suppliers to the complexity of the products. Scenario planning of what the potential outcomes will be, their effect on the Business Case and final solution should be undertaken on complex projects.

Assure that the risk profile is adequate and contingency plans are in place.

The assessment will consider the level of risk being managed. This may affect the level of control that is being applied in terms of contingency planning, which in turn should affect your plans for delivering the project and how it will be controlled.

Record any new risks and review the overall risk profile prior to signature.

There will be risks associated with achieving this milestone, these will include failure to agree a contract, loss of expected functionality or cost differences. Each scenario should be tracked as a risk and a contingency plan kept in place, for example, having a preferred supplier should not preclude continuing dialogue with other potential suppliers.

Update Risk Register and refine risk profile relating to compatibility and adaptability of the components.

The completion of the Business Operating Model will present risks (they may be human or technical) which should be tracked.

Where the Business Operating Model requires organisational structure changes then the level of overall risk will be higher and must be actively managed.

The risk profile of the project should be under regular review.

The final build and testing should provide the opportunity to remove risks, reduce the likelihood and impact of risks as the service should now be tested.

Any problems that have arisen are no longer risks but should actively be managed as issues.

Update risks to reflect the successful completion of testing.

The completion of acceptance testing should enable the removal of risks around functionality and interoperability. The focus of risk should now be on transition activities and any threats to the ultimate hand over to operations.

Update risk profile to reflect the business risks that could now become active.

Risk management will now focus on business and operational risk as the project moves into transition. Issue management should be clearly allocated with responsibility for issues relating to the contract and achievement of the specification that may continue post the project.

The risk profile of the project should be adjusted accordingly.

If the performance has deteriorated from the original baseline then the potential reputation risks will increase. Changes and schedules should be based on mitigation or removal of as much risk as possible.

If performance has improved since the baseline, the potential for a faster transition or acceptance of more risk may be acceptable.

Ensure that operational risks are logged and managed.

As the solution is going into service the levels of risk should be under review with the increasing stability being reflected in the lower levels of risk exposure.

However, this is the period when the operational groups will be fully involved in the transition. This is likely to lead to an increase in the number of change requests so there will need to be a good process, not only for logging them, but processing them as well. 

Close off risks relating to transitional service stability.

The project related risks should now be closing down but there will still be those which affect working practices, operational stability and performance. These should move to the operational Risk Register.  

The corporate Risk Register may also be updated as the achievement of the new way of working may mitigate a corporate risk, that was part of the Business Case justification.

Ensure that operational risks are transferred into corporate registers.

Lessons learned about the way risks have been managed should be recorded and distributed.

Only risks relating to decommissioning should now be on the log.

One of the risks that should be managed is the dependence of operations on the project resources in terms of skills and processes for managing the supplier.