abc guide part b – sample documents july 2012...abc has a five-year rolling business plan that...

ABC Guide Part B – Sample Documents

July 2012

© AXELOS Limited 2012All rights reserved.

Reproduction of this material requires the permission of AXELOS Limited.The swirl logoTM is a trade mark of AXELOS Limited

M_o_R® is a registered trade mark of AXELOS Limited

Contents Contents 1 Introduction 3 2 Risk management policy 4 3 Risk management process guide 9 4 Risk management strategy 12 5 Risk register 17 6 Issue register 19 7 Risk improvement plan 21 8 Risk communications plan 23 9 Risk response plan 27 10 Risk progress report 29

of 32




Introduction

1 Introduction

1.1 Purpose This document contains supplementary guidance to the OGC publication “Management of Risk: Guidance for Practitioners” (M_o_R®).

It is being provided to M_o_R Accredited Training Organisations to provide them with additional training materials that demonstrate each of the documents described in M_o_R.

1.2 Use of the guide This document (The ABC Guide Part B – Sample Documents) is available to candidates prior to but not during the M_o_R practitioner examination. The document “ABC Guide Part A – Techniques” is also available to candidates prior to the M_o_R practitioner examination but is available for use during the practitioner examination.

The M_o_R foundation examination is a closed book examination.

1.3 The sample documents The following table identifies the techniques documented in the 2010 M_o_R guide and the techniques described in this document:

• Risk management policy

• Risk management process guide

• Risk management strategy

• Risk register

• Issue register

• Risk improvement plan

• Risk communications plan

• Risk response plan

• Risk progress report

1.4 Acknowledgements The APM Group would like to thank:

• For their contributions to the original ABC Guide:

• Dr Robert Chapman, for producing all of the risk documents and descriptionsof the common techniques

• Graham Williams for reviewing the above and for editing them into this singledocument

• For the editing of this version:

• John Fisher, M_o_R Chief Examiner

• Keith Gray M_o_R Exam Panel

• William Layne M_o_R Exam Panel.

of 32




Risk management policy

2 Risk management policy

2.1 Scenario ABC has a five-year rolling business plan that focuses on delivering the company’s strategy. Each business unit and support function derives its objectives from the plan and these are cascaded to form individual objectives. The plan covers all the key trading and financial performance measures and targets to deliver the financial returns on the capital employed in the business.

On an annual basis these plans are combined with detailed budgets and also our balanced scorecard (which we call our Steering Wheel) which unites the Group's resources around our customers, people, operations and finance. This enables the business to be operated and monitored on a balanced basis with due regard for all stakeholders. In our fast moving business, our financial performance is measured on a monthly basis, and the Steering Wheel is reviewed quarterly. In addition, all major initiatives require business cases to be prepared incorporating a risk assessment, normally covering a minimum period of five years. Post-investment appraisals are also carried out.

The Board has overall responsibility for internal control, including risk management. We agree appropriate policies that will safeguard the achievement of the company's objectives. Executive management is responsible for identifying, assessing and controlling financial and non-financial risks. It is the Executives' role to implement and maintain the control systems across the company in accordance with the Board's policies and in line with best practice identified in the Turnbull Guidance.

2.2 Example 2.2.1 Introduction

ABC, like all organisations, faces a wide range of risks at all levels of the organisation. The aim of this policy is to communicate why risk management should be undertaken, provide a common risk management language and a description of the approach that will be adopted by ABC to manage its risks.

ABC recognises that up to now it has not formally managed risk throughout the organisation and now wishes to improve the maturity of its risk management practices.

The policy forms part of the company’s internal controls and corporate governance arrangements.

This policy, and the adoption of the overall risk process, is owned by the Finance Director with delegated authority from the Management Board. The Finance Director also has responsibility for all of ABC’s internal control mechanisms.

The purpose of this policy is to define how management of risk will be handled throughout ABC Consulting.

The purpose of this policy and the adoption of risk management are to derive the commonly accepted benefits of risk management which include enhancing overall company performance and invigorating opportunity seeking practices. A broader description of the benefits of risk management is described in the M_o_R Guide.

The policy explains: the company’s underlying approach to risk management; documents the roles and responsibilities of the Board, the senior management team, and other key parties; outlines key aspects of the risk management process; and identifies the main reporting procedures.

The policy describes the process the Board will use to evaluate the effectiveness of the company’s internal control procedures.

of 32




Risk management policy 2.2.2 Risk appetite and capacity

Our risk appetite and capacity will be reviewed on a regular basis as the market place is constantly changing necessitating changes from time to time.

Our risk capacity is determined by the ability to raise finance through shareholders and loans from banks. On an annual basis the Finance Director will calculate the capacity based on the data used for the annual report

Our risk appetite is defined by:

• The level of professional indemnity cover that we hold and are prepared to offerclients.

• The type of consultancy services that we are prepared to offer.

• Our bidding strategy.

• The contract terms that we are prepared to accept (and in particular any penaltyclauses).

• The payment terms that we are prepared to accept, as this affects our liquidity andability to make payments in a timely manner.

• The level of overheads that we are prepared to accept as a proportion of ourincome (which includes investment in IT hardware and software).

• The degree of outsourcing that we implement (which might offer financial prudencebut diminish the degree of control we have over key support services).

2.2.3 Risk tolerance and thresholds Described below are the organisational activities where tolerance levels will be established. Where outcomes are predicted to deviate from planned outcomes beyond prescribed limits, the referral must happen as soon as the deviation is forecast. This includes forecasts that may enhance objectives as well as those that may erode objectives.

Strategic level A return on investment calculation will be carried out on any planned major investment so that the risk reward balance is made explicit and understood. All major investments will have to be approved by the Board. Where analysis indicates that the returns will deviate by more than 5% of the original assessment these will have to be returned to the Board for approval.

Programme level Quantitative analysis will be carried out for all programmes. A contingency will be defined for the budget and schedule. Programme contingency will be managed by Programme Managers. Any expenditure over and above the contingency for a programme will have to be approved by the Finance Director.

Project level For each project a contingency will be defined for both the budget and the schedule. Quantitative analysis will be carried out for all projects over £1million. The project contingency will be managed by project managers. Any expenditure over and above the contingency has to be approved by the Programme Manager.

Operational level A risk contingency will be defined for each operational activity which will be 5% of the annual budget allocated to the activity. Any expenditure over this threshold will have to be approved by the Operational Director.

of 32





2.2.4 Procedure for escalation Escalation is the process whereby a manager’s limit of authority has been reached or is likely to be reached. Our escalation process enables managers to understand who to consult when escalation is required in the event that threats or opportunities have been identified that will significantly affect an activity’s objectives.

Points of contact for escalation are listed below.

Strategic investments: Escalate to the Managing Director (who may involve the remaining Board members)

Programme level: Costs escalate to the Finance Director, schedule or objectives-escalate to the Managing Director

Project level: Costs, time or project objectives-escalate to the Programme Manager

Operational level: Risks or groups of risks that exceed the threshold are to be escalated to the Operational Director

2.2.5 Roles and responsibilities The board: Approve funding for risk management (including the appointment of risk staff), act as the risk champions driving risk from the top down, ensure all major decisions are subject to a risk assessment and agree the remit of and appointments to the audit and risk committees. The board will regularly review the most serious risks threatening the strategic objectives.

The internal audit committee: Provide assurance that the risk management practices are effective and ensure that their reports are impartial and objective.

The risk committee: Provide guidance on the current maturity of the company’s risk management practices, make recommendations for improvement, assist in embedding risk management throughout the company, develop appropriate techniques, recommend the adoption of software tools, comment on audit reports and provide trend analysis on the company’s risk exposure.

Senior management: Ensure that they understand the risk policy, process and reporting requirements, ensure a risk register is compiled and maintained for each major activity, escalate risks as required by this policy, support internal and external audits and carry out the complete risk management process on all major activities.

2.2.6 Glossary of terms As a consequence of adopting the M_o_R Guide, we will adopt the terminology from that publication unless we have operational reasons for deviating – these deviations will need to be agreed on an individual basis with the appropriate member of the management board. The key terms are included below. For a full glossary of terms refer to the M_o_R Guide.

Key terms

of 32




Risk management policy Risk is defined as an uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring and the magnitude of its impact on objectives.

Management of Risk is defined as the systematic application of policies, methods, and practices to the tasks of identifying, estimating and evaluating risks and then preparing and implementing risk responses. This provides a disciplined environment for proactive decision-making

Risk appetite is defined as an organisation’s unique attitude towards risk taking, which in turn dictates the amount of risk that it considers acceptable.

Risk tolerance is defined as the threshold levels of risk exposure, which with appropriate approvals, can be exceeded, but which when exceeded will trigger some form of response (e.g. reporting the situation to senior management for action).

2.2.7 Risk management process Some level of risk is both inevitable and necessary. The task of risk management is therefore to ensure that ABC adopts an effective risk process to support better decision taking through a good understanding of risks and their likely impact. Risk management is not a one-off exercise. It is a continuous process because the decision making processes it underpins are continuous. Risk management must become an integrated part of good management within ABC, but not be over bureaucratic and a process for its own justification.

The process to be adopted is described in the document “Risk management process guide”.

2.2.8 Key performance indicators and early warning indicators Our goal is not to measure everything that can be measured, but solely those issues which will provide a view of company health and highlight those areas that may become a risk to the survival of the company if left unchecked.

The following will be assessed on a monthly basis:

• Monthly sales

• Monthly salary costs

• Monthly overheads

• Late payments by 30days (value)



• Level of reserves

• Disputes / litigation

• Percentage of bids lost

• New commissions won

• Staff turnover

• Number of consecutive months costs have had to be met from reserves

2.2.9 When risk management will be implemented Risk management will be applied to internal programmes and projects and as a minimum to the preparation of: major bids, outsourcing contracts, offshore contracts and investment calculations. In addition it will be applied to the following activities: moving premises, procuring new premises, divestments, acquisitions and organisational change.

of 32





of 32




2.2.10 Reporting The following describes the reports that will be produced and their frequency:

• Strategic risk reports will be submitted to the Board on a two monthlycycle.

• Monthly reports (identifying key risks and risk management actions) will beprepared for each programme and project.

• Individual risk reports will be prepared prior to each investment,acquisition, contract or outsourcing decision.

• Business divisions will submit monthly key performance indicator reports.

• A risk management report will be prepared to be included in the Companyannual review.

2.2.11 Quality Assurance This Policy will be subject to document control, version control, reflect the common policy structure, be updated at least annually, and be revised to reflect changes in legislation, risk management best practice and significant changes in corporate governance.

2.2.12 Annual review

Audit and risk committees The internal audit committee will carry out audits of the application of risk management and its overall effectiveness, and will report to the Board on its findings.

The risk committee will:

• Review the findings of the internal and external risk audit reports and makerecommendations on proposed changes to the policy.

• Review the company’s risk appetite against any changes in the context of theorganisation.

• Consider the maturity of the company’s risk management practices and makerecommendations.

Additional information sources ABC risk management guidance and training material is available on the Corporate Governance area of our intranet, under the sub heading of internal controls.

Reference material The following international and national standards and guides provide useful guidance on the implementation of risk management:

• OGC publication “Management of Risk: Guidance for Practitioners” 2010

• Project Management - Guide to the Management of Business Related Project RiskBS 6079-3:2000 (UK)

• Risk Management: Guideline for Decision Makers CAN/CSA-Q850-97 (Canada)

• Risk Management AS/NZS 4360: 2004 (Australia/New Zealand)

• ICAEW Guide “Successful management of IT Risk” 2007

• IT adviser “Managing risk to enhance stakeholder value” 2007

Risk management process guide

of 32

3 Risk management process guide

3.1 Scenario As ABC does not have a fully documented internal approach to managing risk, the Board has decided to adopt the guidance included within the publication “Management of Risk: Guidance for Practitioners” (the M_o_R Guide) published by the OGC. Hence this Guide should be read in conjunction with the M_o_R Guide.


The purpose of this Guide is to ensure that risk management is carried out in a consistent manner following best practice procedures, so that the results obtained can be relied upon by the Board to make reliable robust decisions for the future growth and prosperity of the business.

This Guide provides a road map for the implementation of risk management by describing the steps in the process and the activities involved in each step.

Additionally, this Guide is part of a set of guidance within ABC and must be read in conjunction with the ABC Risk Management Policy and adhere to its requirements.

3.2.2 Roles and responsibilities This Guide has been prepared by the Risk Manager and any questions on its content should be referred to him/her.

Guide updates will be issued from time to time to include improvements to enhance the maturity of ABC’s risk management practices and or include changes in legislation, corporate governance publications or ABC internal controls.

This Guide has been reviewed and accepted by the Audit Committee and must be followed to accomplish the internal control assurance process.

The Guide makes recommendations on the use of techniques and tools. Their use should be tailored to the circumstances of the activity being undertaken.

The risk management function reports to the Managing Director and supports all Programmes, Projects and Operations.

3.2.3 Steps in the process The ABC Risk Process is based on the M_o_R Guide and subdivided into 4 processes known as: Identify, Assess, Plan and Implement.

Collectively these processes form a logical sequence of steps necessary for the adoption of a robust approach to the implementation of risk management. They are carried out in a sequence as any one step cannot be undertaken until the proceeding step has been completed. However they are all iterative in nature in that when additional information becomes available, it is often necessary to revisit earlier steps and carry them out again, to achieve the most informative result.

The overall process is illustrated in the figure below. The steps are represented as a circle of arrows for it is common for the entire process to be completed several times in the life cycle of a Programme, Project or other activity of a long duration.

The activity ‘communicate’ deliberately stands alone as risk reports are to be issued on a regular basis during long term activities.

For details of each process step, please refer to the M_o_R guide.




Risk management process guide

of 32




Figure 1: The ABC risk process (which mirrors the M_o_R process)

3.2.4 Tools and Techniques The following techniques will be used throughout the risk management process. Please refer to the Risk Manager, the M_o_R Guide or the ABC Guide Part A – Techniques for further details. Note that there are no associated techniques for the Plan and Implement process step.

Process step Techniques associated with this process step in the ABC process

Identify – context • Stakeholder analysis including RACI diagrams

• PESTLE analysis

• SWOT analysis

• Define the probability impact grid

Identify – risks • Checklists

• Prompt list

• Cause and effect diagrams

• Risk descriptions

Assess – estimate • Expected value assessment

Assess – evaluate • Summary risk profiles

• Summary expected value assessment

• Probability trees

3.2.5 Templates Please see the samples in the M_o_R Guide. Templates for each document can be found on the corporate intranet.

3.2.6 Glossary of terms See the M_o_R guide for a list of risk management terms.

Risk management strategy

of 32

4 Risk management strategy

4.1 Scenario As ABC does not have a fully documented internal approach to managing risk, the Board has decided to adopt the guidance included within the publication “Management of Risk: Guidance for Practitioners” (the M_o_R Guide) published by the OGC.


The purpose of this Strategy is to act as a communication tool to ensure the Programme participants understand the key Programme parameters (budget, schedule and activities), the responsibilities of the parties, the process to be adopted, the measures of probability and impact to be employed, the software tool to be used, the issues to be reported on and the timing of risk management activity.

This Risk Management Strategy refers specifically to the Technology Replacement Programme.

This Strategy has been prepared by the Risk Manager and any questions on its content should be referred to him/her.

Additionally, this Strategy must be read in conjunction with the ABC Risk Management policy and adhere to its requirements.

The purpose of the Technology Replacement Programme is to support the development of new business services based upon an e-platform. Increasingly:

• CAD drawings are exchanged electronically,

• Project records are stored and accessed on a Project web site or a host site toenable the participating design consultancies and the client organisation to have ready access to the latest Project files;

• Clients seek to invite and receive tenders electronically; and

• Correspondence is predominantly exchanged electronically.

Key Programme parameters Timeline: the Programme has to be completed in 9 months as many competitors have already established new services based on an e-platform.

Budget: the Programme budget is £1.2m based on the purchase of hardware and multiple software licences, software training, alterations to the web site (and additional storage space) and ‘dual running’ while some legacy systems have to be maintained until the new service has been fully bedded down.

Approvals: the Programme Manager is responsible for developing a Programme lifecycle / implementation plan and prior to the commencement of each stage in the lifecycle, the Programme Manager has to seek approval to proceed to the next stage.

Stakeholders: the Programme stakeholders include the investors, the Board, the Managing Director, Programme Manager, Project Managers, staff and suppliers.

Activities: the Programme primarily consists of the installation of new hardware, software, policies, procedures, adjustments to the web site and staff training.

4.2.2 Summary of the risk management process steps The M_o_R process will be adopted, which is composed of the following four primary processes: identify, assess, plan and implement.





of 32

Figure 2: The risk management process diagram as included in the M_o_R Guide

Sections 4.2 to 4.7 of the M_o_R Guide describe activities that will be carried out during these processes.

Refer to our ABC Risk Management Process Guide for implementing the steps in the risk management process.

4.2.3 Tools and Techniques All appropriate techniques will be used. Reference will be made to the M_o_R Guide to aid selection of the technique(s) to be used at the different stages of the Programme life cycle.

Risks will be captured on a company wide basis using a proprietary software tool that enables bespoke reports to be prepared. An appropriate number of licences will be held to enable all divisions/departments to be able to upload their revised assessments on a regular basis. In addition a simulation software tools will be acquired to carry both cost and schedule quantitative risk analysis.

4.2.4 Records The following records should be kept:

• Risk detail should be summarised in the risk register using the software tool asdescribed in section 4.2.3. above. Significant risks above medium probabilityand medium impact will record the detail in a risk response plan.

• Issues should be recorded in the issue register see section 6 in this documentfor the format of the risk register.

4.2.5 Reporting Reporting will be carried out in accordance with the requirements of the risk policy.

4.2.6 Roles and responsibilities All the participants in the Technology Replacement Programme will be required to follow the Risk Management Policy.





of 32

IT Director: The IT Director is the line report for the Programme Manager and the Risk Manager. Any expenditure over and above the Programme contingency will have to be approved by the IT Director.

Programme Manager: The Programme Manager will report to the IT Director. The Programme Manager will integrate risk management into the Programme processes to improve the likelihood of their Programme accomplishing its objectives.

Project Managers: The Project Managers will report to the Programme Manager. Each Project Manager will integrate risk management into the Project processes to improve the likelihood of their Projects accomplishing their objectives.

Risk Manager: The Risk Manager will report to the IT Director. The Risk Manager will be responsible for supporting the Projects in facilitating the risk management process. In the fulfilment of this role, the Risk Manager will conduct qualitative and quantitative risk analysis, calculate contingency sums and contingency schedules, confidence levels, maintain the risk register (and other records) and provide risk management reports as agreed with the Project Managers.

The Risk Manager will be responsible for supporting the Programme in facilitating the risk management process. In the fulfilment of this role, the Risk Manager will conduct quantitative risk analysis (including the analysis from the relevant Projects), calculate contingency sums and contingency schedules, confidence levels, maintain the risk register (and other records) and provide risk management reports as agreed with the Programme Manager.

The Risk Manager will prepare a return on investment calculation on the Programme to support the strategic direction of the business, so that the risk reward balance is made explicit and understood.

4.2.7 Scales for estimating probability and impact

Probability A five-point scale has been selected for probability to give sufficient granularity to the assessment of how likely a risk or opportunity is to materialise.

Probability Criteria Likelihood

Very High > 75% Almost certainly

High 51% - 75% Probable

Medium 26% - 50% Possible

Low 6% - 25% Remote

Very Low 0% -5% Very remote

Impact The Board consider the Programme is critical to business growth and so require it to be completed as soon as possible. In addition they require the Programme to absorb the minimum of financial resources (to leave funds available for other Programmes). Hence a very high risk impact is described as low as 20 days and a very high impact as low as £100k. Both could have been set higher. These scales are for use prior to the implementation of mitigation actions.





of 32

Category Cost Time Requirements

Very High > 100k > 20 days Major shortfall in any of the critical requirements

High 75k – 100k 15 days – 20 days Shortfall in any of the critical requirements

Medium 50k – 75k 10 days – 15 days Shortfall in multiple requirements

Low 25k – 50k 5 days – 10 days Shortfall in ancillary requirements

Very Low > 25k < 5 days Minor shortfall in ancillary requirements

Expected value The expected value calculation is to be used to provide a quick assessment of the combined net effect of the risks and opportunities. This is calculated by multiplying the average of the impact by the probability.

4.2.8 Risk category The risk register is to include a column headed ‘response category’ and against each risk a response is to be recorded from the options: reduce, retain, remove, transfer and share. Descriptions of thee categories are explained in the M_o_R Guide.

4.2.9 Budget required The Risk Manager will be assigned to the Programme for the entire life cycle including for three months after the system becomes live.

4.2.10 Templates Reports will be set up in the proprietary software tool in terms of: risk register, prioritised risks, risks by risk owner, risks by risk category, risks by proximity and so on.

4.2.11 Early warning indicators The following will be assessed on a monthly basis (providing a trend analysis) to provide guidance on the Programme health.

• New risks that materialised during the month

• Risks closed during the month

• New opportunities that materialised during the month

• Opportunities exploited during the month

• Contingency spend during the month

• Anticipated outturn cost

• Anticipated outturn duration

• Number of disruptions to existing business streams

• Staff turnover in month

• Number of changes introduced during the month

• Increase in scope during the month

4.2.12 Timing of risk management activities A complete review of the threats and opportunities will be undertaken at each decision gate, prior to the next stage of the Programme to enable the Board to decide (at each





of 32




gate) whether they wish to proceed, conduct further activities prior to proceeding, postpone the Programme or abandon the Programme.

4.2.13 Glossary of terms The M_o_R Guide must be referred to for the terms to be used for risk management throughout the life of the Programme.

Risk register

of 32

5 Risk register

Risk ID

Risk Category

Date Raised

Risk Description Risk Status

Strategic October As a result of the desire to run concurrent projects and resource them both internally, there is a risk of slippage of both of these key projects at the same time, which may result in the programme being unable to deliver the projected benefits (so that a return on investment can be obtained within the planned timeframe).

Active

Pre-response Post response

Probability Cost Impact

Expected Value

Proximity Probability Cost Impact

Expected Value

Proximity

Medium High 27K 6 to 12 months

Low Medium 12K 6 to 12 months

Risk response Action

1. Avoid: cancel one of the projects (we cannot meet corporate objectives)2. Reduce: run the projects in sequence not parallel – elongates timeframe but

reduces overall impact3. Reduce: acquire more resources to undertake one or both the projects

(depending on which is most critical)4. Share: contract out development associated with project1 to include liquidated

damages in the case of late delivery – though would need careful handling toensure delivers to time/quality (project2 remains internally resourced). Increasescosts but should protect time and quality

5. Accept: unacceptable – must address this risk or stop the programme

Option selected: Opt 4 share – bring in external contractor to support project 1 includes diverting internal resources from project1 to project2 to enable it (project2) to run to plan

Action Status

Discuss with risk owner the process for the selection of external contractor

Secondary risks

Cause: External contractor may not deliver on time. Event: Although liquidated damages will ensure financial compensation, the delivery will still be late. Effect: Project fails to meet customer delivery date

Risk Owner

Managing Director Risk Actionee

Contracts Manager to ensure correct contract is in pace. Risk Manager to ensure secondary risk is identified and estimated for.

Note: This is only one risk of many that would appear on the risk register. It gives a high level view of a single risk

This example was generated using the risk management software tool that ABC are using to record their risks.




Risk register

of 32




Issue register

6 Issue register

Issue Log No TRP 01

Author Robert Chapman Date 31/07/06 Version Number 01

Programme TECHNOLOGY REPLACEMENT PROGRAMME

Issue Owner Programme Manager (PrM) Sponsor IT Director (DIR)

Issue Description

Contractor, company XYZ, which had been appointed to undertake one of the projects with the Technology Replacement Programme, has gone into liquidation and will no longer be able to carry out the contract

Issue Category Contractor

No Description of impact Time Cost

A The Programme will not be able to be completed to schedule High Medium

B The planned benefits of the Programme will not be realised as planned

High High

C Bottom line company performance will be reduced. High Medium

D Market competition may erode market share Medium High

E The Office Refurbishment Project and the Infrastructure Upgrade Project will be delayed.

High Medium

No Action required Date to be implemented

Date implemented

Actionee

01 Make arrangements to speak to the administrators at the earliest opportunity to establish what materials have been ordered, what materials have been paid for and which sub contractors have been appointed and paid. Establish the protocol for speaking to suppliers and sub contractors direct. Establish precisely the status of the Programme.

TBA DIR

02 Notify the stakeholders of the liquidation. TBA DIR

03 Notify the delay to the Project Managers of the interlinked projects.

TBA PrM

04 Revisit the tender file and establish with the other bidders, if their tender prices are still valid.

TBA PjM

05 Negotiate with the lowest bidder. TBA PrM

06 Contact the primary suppliers and establish the viability and prudence of placing orders direct, to try to recover part

TBA PjM

of 32




Issue register

of 32




of the schedule.

07 Consider splitting the Programme into smaller elements so that activities can be overlapped to try and recover the schedule.

TBA PrM

08 Establish if there have been any changes in technology which (due to the delay) could now be incorporated.

TBA PjM

09 Notify any important customers who had been previously notified of the programme.

TBA PrM

10 Review any internal and external approvals that have to be obtained and how the delay will affect these approvals

TBA PrM

11 Revise the schedule and notify the primary stakeholders.

TBA PjM

Risk improvement plan

7 Risk improvement plan

7.1 Scenario A recent healthcheck carried out on the technology improvement programme has identified significant weaknesses with the application of risk management across the programme.

7.2 Example 7.2.1 Date:

November

7.2.2 Category group The groups that have been identified for this particular improvement initiative are the Programme and Project Managers. The rationale being that this group has the greatest ability to integrate risk management into project and programme activities. While risk management has been mandated by the Board in the past, without an understanding of how and where it should be applied, such initiatives are reduced to just aspirations rather than being integrated as new effective working practices.

This group has the ability to be very influential within the company.

7.2.3 Existing behaviours Currently risk management is perceived as a discretionary ‘bolt on’ rather than a key discipline.

Hence risk management is not automatically integrated into bid/no bid decisions, assessment of consultancy contract clauses, the review of outsourcing contracts, acquiring new premises, or penetrating new markets.

Additionally it has not been routinely included into programme and project activities.

7.2.4 Target behaviour The aim is for risk management activities to be integrated into day to day activities, but particularly within key activities of programmes and projects with the aim of achieving greater certainty in these activities achieving their objectives.

7.2.5 Target date This change of behaviour is to be accomplished within one year.

A programme is to be prepared with key delivery milestones made explicit.

7.2.6 Mechanisms

• The risk management activities to be carried out at each decision gate during thelife cycle of each programme and project are to be documented.

• Feasibility studies are to include risk assessments.

• Budgets and schedules are to be subject to risk assessments to determineconfidence levels in programme and project objectives.

• The selection of procurement routes is to be subject to risk assessments.

• Risk management is to be routinely part of the tender process.

7.2.7 Measurement Measurement will be undertaken by an assurance process to understand where and how risk management has been applied and how effective it has been.

Evidence will have to be produced to illustrate how risk management has been applied.

of 32




Risk improvement plan

of 32




Risk communications plan

8 Risk communications plan

8.1 Scenario The risk communications plan has been produced to describe how information will be disseminated to, and recovered from, all stakeholders of the Technology Replacement Programme.

It has been agreed with the Programme Board that the key information for the Programme will be saved on the project web site. The site will be structured so that it can be readily navigated and each discipline will have its own area.

Programme members will be notified of the inclusion of a new document being placed on the web by email, citing its title, document code, revision, date, author and location on the web. The web site will always have the latest revision of any document.

The content of each email will follow a consistent format as laid out in the email template. Each email will have a unique identifier as part of the document control system clearly indicating the Programme phase to which it relates.

8.2 Example 8.2.1 Key elements of Programme information to be distributed

Programme information saved on the web will include:

• PID (project initiation document)

• Programme execution plan (including a description of the programme information tobe produced for each board meeting)

• Objectives

• Programme brief

• Programme members list of deliverables

• Budget

• Schedule

• Organisational chart and job descriptions

• RACI diagram

• Document schedules

• Document control reports

• Gateway reports

• Change control requests

• Risk register, issue log, confidence levels, risk reports, risk management plan

• Drawings

• Summary description of roles of the primary stakeholders

• Approvals submissions

• Implementation method statement

• Contracts

• Supplier agreements

• Programme proformas / templates

of 32




Risk communications plan • Lessons learned log

• Meeting minutes

• Close out (end) report

Information will be updated as a minimum on a monthly basis.

8.2.2 Roles and responsibilities for communication Specific duties are described below.

IT Director The IT Director will:

• Be responsible for effective communication among stakeholders about the

• Set and communicate the risk appetite for the programme investment decision postreceipt of programme contingency advice from the Risk Manager and the management team (Programme and Project managers).

• Approve the funding for the Programme and hence approve any additional funding ifappropriate, post receipt of escalated risks or calls for increased contingency levels.

• Assist in the risk process by helping to set the Programme context or notifying theProgramme during its life cycle of actions of the Board which affect the Programme.

• Cooperate with the appropriate public relations / communications unit within ABC tocoordinate all communication with third parties outside the Programme that are impacted by it or are contributing to it.

Programme Manager The Programme Manager will:

• Communicate the risk escalation procedures downwards. Escalate to the ITDirector, calls for an increase in budget or contingencies levels, if required.

• Inform the Programme members of the importance of participating in riskmanagement activity led by the Risk Manager.

• Communicate risk management responsibilities through the use of seminars and jobdescriptions.

• Support the Risk Manager or communicate directly to the Programme members thetiming of risk management interventions (feasibility, procurement and contract analysis and gateway reviews).

• Receive proposals on the Programme contingencies, communicate these to theDirector and agree contingency amounts (time and cost)

• Sign off Programme change control forms ensuring threats and opportunities havebeen taken into account.

Project Managers Project Managers will participate in the Programme as follows:

• Escalate risks above agreed tolerance levels.

• Inform the Project members of the importance of participating in risk managementactivity led by the Risk Manager.

• Communicate risk management responsibilities through the use of team meetings.

• Support the Risk Manager in carrying out risk management interventions (feasibility,procurement and contract analysis and gateway reviews).

of 32




Risk communications plan • Receive proposals on the Project contingencies; communicate these to the

Programme manager (time and cost).

• Sign off Project change control forms ensuring threats and opportunities have beentaken into account.

Risk Manager The Risk Manager will participate in the Programme:

• To provide assurance of the Programme’s risk management.

• To communicate risk events that occurred on previous IT Programmes andProjects.

• To collect risk information for specific pre-planned risk management activities (i.e.gateway reviews between Programme phases).

• To communicate the need for Programme members to notify risks between gatewayreviews.

• To communicate the results from the risk assessments and present the risk analysisfindings.

• To communicate the need for the different disciplines to integrate their deliverablesto ensure activities are not over looked which may threaten the completion date.

• To support decision-making.

• To obtain new IT risk knowledge.

• To co-ordinate with other parties (such as the sub-contractors and suppliers) andplan responses to reduce the incident of risk events.

• To give decision makers and stakeholders a sense of responsibility about riskmanagement.

• To improve risk and opportunity awareness.

8.2.3 List of stakeholders and information requirements See full list of stakeholders on the separate Stakeholder Map

8.2.4 Communication Mechanisms The primary mechanisms will be the: schedule, budget and project brief. These collectively describe the three main Programme objectives – time, cost and quality.

The ‘direct participative’ mechanisms will be the: workshops, meetings and seminars.

The ‘indirect participative’ mechanisms will be the: RACI diagram, risk register, change control sheets, e-mail and reports.

The ‘non participative’ mechanisms will be for example the: electronic newsletters sent to the staff to update them on the progress of the Programme and the schedule of meeting dates.

8.2.5 Process for handling feedback Feedback is integral to the communication process. However it is important that all communication is timely particularly where problems have or are anticipated to occur which may affect the Programme objectives. Programme members must notify their Project Manager initially who will in turn notify the Programme manager as required.

8.2.6 Schedule of communication activities Communication activities: refer to the Programme schedule (see above) for the timing of (for instance) of the - completion of the project brief, submission of the gateway reports, submission of the approvals, completion of the risk management reports and close out

of 32




Risk communications plan

of 32




report. Other communications, such as the issue of change control requests, will occur as and when required.

Risk response plan

9 Risk response plan Risk ID

TR007

Risk Description As a result of a hastily prepared high level functional requirements specification, there is a risk that the technology replacement programme will deliver a capability, which fails to meet the identified business needs (i.e. user satisfaction is below expectations), which may result in poor customer satisfaction and failure to capture the market share planned. Pre-response Probability Cost Impact Expected Value Proximity

High High Reduce

Post response Probability Cost Impact Expected Value Proximity

High High Reduce

Action

1. Establish a full gateway review process for the Programme, whereby each stage isscoped, costed, resourced and scheduled. Achievement milestones to be established for each stage.

Owner Actionee Date of action Cost of response

IT Dir. PMs Week 1 No cost Secondary risk To be identified

Action 2. Conduct peer reviews (where members of another Programme review this Programme)Owner Actionee Date of action Cost of

response IT Dir. PMs At Stage Gates No cost Secondary risk

To be identified

Action 3. Break the Programme into manageable ‘lumps’Owner Actionee Date of action Cost of

response IT Dir. PMs Week 2 Additional

project staff

Secondary risk

As a result of breaking the Programme into small ‘packages’, there is a risk that a lack of coordination between the ‘packages’ arises leading to work items ‘falling between the cracks’ which may result in late discovery of work items, rework to integrate unanticipated work, missed long lead items, protracted approvals, lack of compliance with the brief and or schedule slippage.

of 32




Risk response plan

of 32




.

Risk progress report

10 Risk progress report

10.1 Scenario The overall Programme aim is to support and contribute to an incremental improvement in bottom line performance. To do this two projects have been initiated.

The ‘Applications Development’ project is aimed at upgrading existing information technology equipment and defining, procuring and installing a new e-platform, for the delivery of new services and getting closer to clients (to better understand and respond to their needs). This project is aimed at both creating a new market and consolidating the existing market.

The Security / Business Continuity Management (BCM) project is designed to provide the organization with both organizational resilience and the ability to operate following an adverse event or events. The aim of the project is to provide the organization with the ability to [1] maintain the confidentiality, availability and integrity of its information assets and [2] to identify and record what needs to be done before an incident occurs to ensure its people, reputation, assets, systems and information, remain secure and operational.

The two projects have been integrated to ensure that the introduction of the e-platform does not interrupt the delivery of existing services and starve the business of income required for both BAU (business as usual) and investment in programmes required for both sustainability and long term growth.

The programme organisational structure is:

Programme Sponsors: The Board

Director responsible for the Programme: IT Director Dave Spencer

Programme Manager: Bob Smith

Project Manager (Applications Development):

Steve Wright

Project Manager (Security / BCM): Dave Austin

Risk Management: Jen Hawkins

In the past month the following has been identified:

Threats: 15 new threats have been Identified, adding £32,000 to the overall risk EV.

Opportunities: 3 new opportunities have been identified, reducing the overall risk EV by 12,000

Issues: The price of the enabling software has risen and additional staff have had to be drafted into the project on a temporary basis.

10.2 Example The following is an extract from the last monthly programme report for the programme.

of 32





10.2.1 Trends of overall risk exposure Quantitative risk analysis results:

QRA (Time) ( € ) Notes

75% Confidence level

75% Confidence level

Last report October

10 weeks 0.4m Confidence levels reflect the organisation’s lack of experience of this type of projects and the desire to include leading technology.

This report November

12 weeks

(suggested)

0.44m (suggested)

Number of new risks outweighed closed risks and new opportunities

Spend against contingency sum:

Contingency (Time) Spend against contingency

Percentage remaining

% of Programme lapsed

Last report October

0 100% 0%


5 weeks 50% 11%

Contingency (€) Spend against contingency

Percentage remaining

% of Programme lapsed

Last report October

0 100% 0%


20,000 95% 11%

Change in insurance requirements

No changes are planned for the insurance provisions at this time.

Movement against the key performance indicators:

Key Performance indicators November October

New risks that materialised during the month

15 12

Risks closed during the month 4 2

New opportunities that 3 7

of 32




Risk progress report Key Performance indicators November October

materialised during the month

Opportunities exploited during the month

2 0

Anticipated outturn cost 1,242,000 1,200,000

Anticipated outturn duration 9months + 5weeks 9months

Number of Issues that have arisen

2 0

Summary of trend status

• The level of risk is currently increasing which is common for projects at this stagein their life cycles.

• The rate of spend of the cost contingency is modest whereas the rate of spendof the time contingency gives rise for concern.

• The true success of the risk response actions will not be readily transparent untilsuch time that we are able to provide a RAG status report as described in Section 4.2.

• The rate of ‘burn’ of the schedule contingency relative to the stage of theProgramme currently indicates that the baseline schedule plus contingency may be exceeded if unknown risks materialise or known risks cannot be significantly reduced.

• There are no issues at the moment that would warrant terminating theprogramme; however any more slippage in the schedule may result in loss of market share.

10.2.2 Numbers and trends of risks emerging Number of risks by category:

Risk categories November October Funding 4 3

Strategic Goals 3 2

Competitors services 1 0

Requirements capture 9 6

Platform content 11 9

Scalable e-commerce 20 18

Preparation of specification 12 12

Technology 10 10

Software 21 16

Tender preparation 4 4

of 32





of 32




Risk categories November October Tender process 3 3

Acceptance testing 6 6

Training 2 2

Trials 3 3

Personnel 4 4

Total 113 98

Top ten risks:

Risk ID Risk Category Risk Description 32 Platform

content The time taken to define the services to be offered on the e-platform exceed expectations

17 Requirements capture

Mapping the automated features to the services / products to be offered and the payment regime requires complex mapping

9 Funding There are competing needs within the business for funding and overspend elsewhere leaves a shortfall for this programme

45 Strategic Goals

Changes in the business’s strategic objectives and long range planning, reduces support for the programme.

81 Scalable e-commerce

Matching anticipated client needs with scalable e-commerce proves more time consuming than anticipated

12 Technology The technology for on line trading platforms is constantly evolving and results in design rework to reflect the new configuration on products now available on the market.

16 Personnel Changes in personnel disrupt platform development 4 Personnel There are competing needs for staff to support the

platform development and support ongoing commissions / assignments

35 Software Inclusion of electronic sales and refunding necessitates the purchase of additional software

21 Competitor’s services

Changes in competitor’s offerings requires a change to the programme brief.