JWN105

2
 AL YAMAMA COMPANY FOR TRADING AND CONTRACTING
RISK MANAGEMENT PLAN
DOCUMENT No. JJWN105RMP- 001 REVISION: 0 DATE: 8-1-2018

DOCUMENT ACCEPTANCE and RELEASE NOTICE

This is Version 1.0 of EXECUTION OF NON-IMPLEMENTED SUBSIDIARY SEWER LINES

AND SEWERAGE HOUSE CONNECTIONS WITHIN CONTRACT (8C-2) AL-HAMRA AND
MUSHRAFA DISTRICTS IN JEDDAH Project Risk Management Plan.

The Risk Management Plan is a managed document. For identification of amendments each
page contains a release number and a page number. Changes will only be issued as
complete replacement. Recipients should remove superseded versions from circulation. This
document is authorised for release once all signatures have been obtained.

PREPARED: _______________________________DATE: 8/01/2018

(For acceptance)

ACCEPTED: _______________________________DATE: ___/___/___

(From Supervising Consultant)

ACCEPTED: ________________________________DATE: ___/___/___

(For release)

3
 AL YAMAMA COMPANY FOR TRADING AND CONTRACTING
RISK MANAGEMENT PLAN
DOCUMENT No. JJWN105RMP- 001 REVISION: 0 DATE: 8-1-2018

1. BUILD STATUS:
The most recent amendment first.

Version Date Author Reason Sections

1.0 8 – 01 – 2018 New

2. AMENDMENTS IN THIS RELEASE:

Section Title Section Amendment Summary
Number
All

3. DISTRIBUTION:
Copy No Version Issue Date Issued To
1 1.0 8-01-2018 NATIONAL WATER COMPANY

4
 AL YAMAMA COMPANY FOR TRADING AND CONTRACTING
RISK MANAGEMENT PLAN
DOCUMENT No. JJWN105RMP- 001 REVISION: 0 DATE: 8-1-2018

Table of Contents

1 Executive Summary............................................................................................................. 5

2 Introduction.......................................................................................................................... 5

3 Project Phases and Project Management Structure..........................................................6

3.1 Project Phases.............................................................................................................. 6

3.2 Project Management Processes....................................................................................9
3.3 Project Management Structure......................................................................................9

4 Risk Management Process................................................................................................11

5 Risk Assessment................................................................................................................ 12

5.1 Identification................................................................................................................12
5.2 Analysis and Evaluation...............................................................................................13

6 Risk Mitigation.................................................................................................................... 15

7 Risk Monitoring.................................................................................................................. 16

8 Roles and Responsibilities................................................................................................16

8.1 Steering Committee.....................................................................................................16

8.2 Project Manager.......................................................................................................... 16
8.3 Project Team............................................................................................................... 17

9 Emergency Response Team (Contact Nos)......................................................................17

5
1 Executive Summary
The purpose of this document is to provide a management framework to ensure that levels
of risk and uncertainty are properly managed for the remainder of the project. As risk
management is an ongoing process over the life of a project, the Risk Register must be
considered a ‘snap shot’ of relevant risks at one point in time.

This document will achieve this by defining the following:

 the process that will be/has been adopted by the Project to identify, analyse and
evaluate risks during the remainder of the project;

 how risk mitigation strategies will be developed and deployed to reduce the likelihood
and/or impact of risks;

 how often risks will be reviewed, the process for review and who will be involved;

 roles and responsibilities for risk management;

 how reporting on risk status, and changes to risk status, will be undertaken within the
Project and to the Steering Committee;

 A complete Risk Register containing all risks identified for the Project, their current
grading and the identified risk mitigation strategies to reduce the likelihood and
seriousness of each risk.

2 Introduction
The purpose of risk management is to ensure levels of risk and uncertainty are identified and
then properly managed in a structured way, so any potential threat to the delivery of outputs
(level of resourcing, time, cost and quality) and the realisation of outcomes/benefits by the
Business Owner(s) is appropriately managed to ensure the project is completed
successfully.

The objectives of the risk management approach in the Implementation of Sewerage Lines
and Sewerage House Connections Contract 20 Sector 11 Project are to identify, assess and
mitigate risks where possible and to continually monitor risks throughout the remainder of
the project as other risks or threats emerge or a risk’s impact or likelihood changes.

As risk management is an ongoing process over the life of a project, this Risk Management
Plan and Risk Register must be considered a ‘snap shot’ of relevant risks at one point in
time.

Where required, the process of risk identification, assessment and the development of
countermeasures will involve consultation with the Steering Committee members, the
Implementation of Sewerage Lines and Sewerage House Connections Contract 20 Sector
11 Reference Group, other relevant stakeholders and Project team members.

6
3 Project Phases and Project Management
Structure
3.1 Project Phases
Phases, or stages, are very important for project managers. By thinking in terms of phases,
you can ensure that the deliverables produced at the end of each phase meet their purpose,
and that project team members (or sub-teams) are properly prepared for the next phase.

You identify the required deliverables for each phase from the Work Breakdown Structure   
(WBS) for it. The WBS is drafted as part of your preparation activities, and then validated by
the rest of the project team. At the end of each phase, someone signs off on the deliverables
from that phase. (In your preparation phase, think through who needs to approve each
deliverable. Approvers may include the project board, project sponsor, or key stakeholders.)
Once the deliverables are approved, the phase is completed and the project team can pass
through the "gate" to the next phase. This is why the term "stage/gate" is used so often in
project management.

The exact phases, and the order in which they're completed, may vary slightly, depending on
what you need to achieve with your project. The phases are as follows:

 Project strategy and business case.

 Preparation.

 Design.

 Development and testing.

 Training and business readiness.

 Support and benefits realization.

 Project close.

7
  Project strategy and business case

In this phase, you define the overall project business requirement , and propose the
approach or methodology that you want to use to address it.

The gate at the end of this phase is the approval of your high-level project proposal and of
the business case that validates the approach you want to use. You must also show that you
can achieve the project's goal within the required timelines and budget.

 Preparation

Here, you work with key stakeholders and project team members who have already been
identified to establish and start the project:

Complete a high-level Work Breakdown Structure   .

Determine the project's high-level plan at the milestone level   . (Work with appropriate
project team members to produce detailed plans at each subsequent phase. This ensures
that they have a sense of ownership of these plans.)

Identify and recruit project members.

Produce the Project Initiation Document  .

Select third parties to use in the early project phases (for example, IT subcontractors or
partners).

Put actions in place to secure key resources. (For example, reserve rooms for the training
phase, and allocate desks and PCs/printers for the project team.)

 Design

I this phase you start the work involved with creating the project's deliverables, using the
project strategy, business case, and Project Initiation Document as your starting point. Then
work with relevant stakeholders to develop the designs of the main deliverables. In larger
projects, you may use business analysts to help you with this.

You probably have a project board or project sponsor who is responsible for signing off the
overall design, but make sure you also get input from other stakeholders as well. This helps
build business ownership of the project deliverables.

If changes to processes are required, use a Flow Chart   or Swim Lane Diagram   to create
a detailed map of how things will work. At this stage, you must do everything you can to think
through and deal with project issues before you start to build project deliverables – problems
are almost always easier and cheaper to fix at design stage than they are once the detailed
work of implementation has started.

8
Select stakeholders   carefully for the detailed design phase. A good detailed design is
more likely to lead to a good project deliverable. If the detailed design is poor, the project
deliverables are much less likely to meet requirements!

 Development and Testing

With all of the planning and designing complete, the project team can now start to develop
and build the components of the project output – whether it's a piece of software, a bridge, or
a business process.

As part of this phase, you need to test   these components thoroughly to confirm that they
work as they should.

 Training and business readiness

This stage is all about preparing for the project launch or "go live." Do the following things
during this phase:

Train users.

Put in place ongoing support.

Transfer data to new systems.

Identify what's required for the project to be effective from the launch date, and ensure that
you adequately address this.

 Support and benefits realization

Make sure you provide transitional support to the business after the project is launched, and
consider what's required before your team members are reassigned. Project teams are often
assigned to other work too soon after the project has gone "live", meaning that project
benefits are often not fully realized.

Monitor the delivery of project benefits   . You can use this to promote your project or to
give you information about other actions needed to ensure that the project is successful.

You can monitor benefits as part of "business as usual" activities, and you should (ideally)
continue to do so after the project is closed.

 Project close

Closing a project   is not the most exciting part of the project lifecycle, but, if you don't do it
properly, you may obstruct the ongoing delivery of benefits to the organization. Make sure
you do the following:

9
Complete and store documentation.

Carry out a Post-Implementation Review   , so that you and your colleagues can use the
experience you've gained in future projects.

Use your business connections to reassign project team members to appropriate roles in the
organization. You don't want to lose the experience and knowledge that they've gained from
working on the project.

3.2 Project Management Processes

The key project management processes, which run though all of these phases, are:

 Phase management.

 Planning.

 Control.

 Team management.

 Communication.

 Procurement.

 Integration.

3.3 Project Management Structure

There are three primary project management organizational structures that have become the
foundation for how an organization is run: functional, matrix, and pure project. Each structure
has advantages, and if used correctly and in the right environment, the structure can further
the completion of projects.

These structures have many disadvantages as well. An organizational structure can help or
hurt project success, plus some organizational structures can impair your ability to deliver
projects. A company’s organizational structure can either get in the way of, or help support
the overall success of their projects.

Some organizational structures may also impede the ability to share resources and impair
the workers ability to deliver projects. But these structures can still work well if the project
managers understand them correctly and good communication exists. Choosing the correct
organizational structure for each project is imperative for the success of that project.
Companies must compare and contrast all choices to pick the best one suited for their
particular project.

10
  Functional
The functional organization, the most common type of project management organizational
structure, works best in small organizations where all the sections are geographically close
together and provide a small number of goods and/or services. The organization is broken
up into different structures based on specialty in the functional organization.

An advantage to the functional structure is the role of the functional manager, which means
there’s only one boss. Having one boss makes it easier to manage specialists and reduces
or prevents conflicts of interest. The main disadvantage is that project managers have
limited authority and a limited career path in this type of structure.

 Matrix
The matrix organizational form is an attempt to combine the advantages of the pure
functional structure and the product organizational structure. This form is suited for “project-
driven” companies such as construction. The power and authority used by the project
manager come directly from the general manager since each project represents a potential
profit, so the project manager has total responsibility and accountability for project success.

Project management is a “coordinative” function, whereas matrix management is a

collaborative function division of project management. There are certain ground rules that
exist in a matrix development that include: participants spend full time on projects, horizontal
and vertical channels must exist for making commitments, quick and effective methods for
conflict resolution, good communication between managers, managers have input in the
planning process, horizontally and vertically oriented managers must be willing to negotiate
for resources, and horizontal lines must be permitted to operate as a separate entity (except
for administrative purposes).

The matrix structure can provide a rapid response to changes, conflicts, and other project
needs.

Conflicts are normally minimal, but those requiring resolution are easily resolved using
hierarchical referral. Almost all of the disadvantages of the traditional structure are
eliminated due to the abundance of advantages in the matrix structure.

 Pure Project
When an organization has a fewer number of projects but the projects have longer duration,
a pure project organization is proposed. Each project manager is appointed and he or she is
responsible to conduct all activities associated with the project, so the project manager is
responsible to the program manager.
The project manager has fully authority for the execution of the project and he reports to the
program manager in the parent organization.

This means lines of communication will be shortened because the project manager directly
communicates with the parent project organization members. In the pure project structure,
the fast reaction time keeps activities on schedule, but technology suffers because without
strong functional groups, which maintain interactive technical communication, the company’s
outlook for meeting the competition may be severely hampered.

11
4 Risk Management Process
Managing risks on projects is a process that includes risk assessment and a mitigation
strategy for those risks. Risk assessment includes both the identification of potential risk and
the evaluation of the potential impact of the risk. A risk mitigation plan is designed to
eliminate or minimize the impact of the risk events—occurrences that have a negative
impact on the project. Identifying risk is both a creative and a disciplined process. The
creative process includes brainstorming sessions where the team is asked to create a list of
everything that could go wrong. All ideas are welcome at this stage with the evaluation of the
ideas coming later.

Identifying the sources of risk by category is another method for exploring potential risk on a
project. Some examples of categories for potential risks include the following:

 Technical

 Cost

 Schedule

 Client

 Contractual

 Weather

 Financial

 Political

 Environmental

 People

12
5 Risk Assessment
5.1 Identification
Risk identification involves determining which risks or threats are likely to affect the project.
It involves the identification of risks or threats that may lead to project outputs being delayed
or reduced, outlays being advanced or increased and/or output quality (fitness for purpose)
being reduced or compromised.

For most large/complex projects, a number of high level risks should have been identified
during the project initiation stage – these should be used as the basis for a more thorough
analysis of the risks facing the project.

One of the most difficult things is ensuring that all major risks are identified. A useful way of
identifying relevant risks is defining causal categories under which risks might be identified.
For example, corporate risks, business risks, project risks and infrastructure risks. These can
be broken down even further into categories such as environmental, economic, political,
human, etc. Another way is to categorise in terms of risks external to the project and those
that are internal.

The wording or articulation of each risk should follow a simple two-step approach:

1. Consider what might be a ‘trigger’ event or threat (eg. ‘poor quality materials causes
costs to rise’) – several triggers may reveal the same inherent risk; then

2. Identify the risk - use a ‘newspaper headline’ style statement – short, sharp and snappy
(eg. ‘budget blow out’) then describe the nature of the risk and the impact on the project
if the risk is not mitigated or managed (eg. project delayed or abandoned, expenditure to
date wasted, outcomes not realised, government embarrassed etc).

Use the Risk Register (see Appendix A) to document the results.

For large or complex projects it can be beneficial to use an outside facilitator to conduct a
number of meetings or brainstorming sessions involving (as a minimum) the Project
Manager, Project Team members, Steering Committee members and external key
stakeholders. Preparation may include an environmental scan, seeking views of key
stakeholders etc.

For a small project, the Project Manager may develop the Risk Register perhaps with input
from the Project Sponsor/Senior Manager and colleagues, or a small group of key
stakeholders.

It is very easy to identify a range of risks that are outside the project and are actually risks to
the business area during output delivery, transition or once operational mode has been
established. These are not project risks and should not be included in the Project Risk
Register, but referred to the relevant Business Owner. It may be appropriate to submit an
Issues Paper to the Steering Committee recommending formal acceptance by the relevant
Business Owner for ongoing monitoring and management of specific risks.

13
In this section specify:

 what risk identification process has been undertaken (ie. brainstorm, facilitated session,
scan by Project Manager etc);

 any categories used to assist in the identification or relevant risks;

 when the risk identification process occurred; and

 Who was involved?

5.2 Analysis and Evaluation

Once risks have been identified they must be analysed by determining how they might affect
the success of the project. Generally the impact of a risk will realise one or any combination
of the following consequences:

 Project outcomes (benefits) are delayed or reduced;

 Project output quality is reduced;

 Timeframes are extended;

 Costs are increased.

Once analysed, risks should be evaluated to determine the likelihood of a risk or threat
being realised and the seriousness, or impact, should the risk occur.

'Likelihood' is a qualitative measure of probability to express the strength of our belief that
the threat will emerge (generally ranked as Low (L), Medium (M) or High (H)). 

'Seriousness' is a qualitative measure of negative impact to convey the overall loss of value
from a project if the threat emerges, based on the extent of the damage (generally ranked as
Low (L), Medium (M), High (H) or Extreme). 

14
From this risks will be graded as A, B, C, D or N according to the following matrix:

Seriousness

Low Medium High EXTREME

Likelihood
Low N D C A
Medium D C B A
High C B A A

The ratings for likelihood and seriousness determine a current grading for each risk that in
turn provides a measure of the project risk exposure at the time of the evaluation.

In this section specify:

 How the identified risks could potentially impact on the project in terms of the four
categories of consequence (eg. x have potential to delay or reduce project
outcomes/reduce output quality etc);

 Summarise the distribution of risks according to the grading (number of ‘A’ Grade risks,
‘B’ Grade risks etc)

 List any ‘A’ Grade risks.

15
6 Risk Mitigation
Mitigation of risks involves the identification of actions to reduce the likelihood that a threat
will occur (preventative action) and/or reduce the impact of a threat that does occur
(contingency action). This strategy also involves identifying the stage of the project when
the action should be undertaken, either prior to the start of or during the project.

Risk mitigation strategies to reduce the chance that a risk will be realised and/or reduce the
seriousness of a risk if it is realised have been developed. The following table is useful to
determine how risks will be treated in terms of preparation and/or deployment of mitigation
strategies during the life of the Project. Mitigation strategies are usually only prepared and/or
deployed for Grades A through to C, however where an existing risk graded at D appears
likely to be upgraded, and mitigation strategies should be prepared.

Grade Possible Action

Mitigation actions, to reduce the likelihood and seriousness, to be identified and
A
implemented as soon as the project commences as a priority.
Mitigation actions, to reduce the likelihood and seriousness, to be identified and
B
appropriate actions implemented during project execution.
Mitigation actions, to reduce the likelihood and seriousness, to be identified and
C
costed for possible action if funds permit.
D To be noted; no action is needed unless grading increases over time.
N To be noted; no action is needed unless grading increases over time.

In this section specify:

 The proportion of risk mitigation actions that are preventative (eg. 30%);

 The proportion of risk mitigation actions that are contingency (eg. 70%);

 Key stakeholders nominated as responsible for undertaking specific risk mitigation

actions;

 Any major budgetary implications

For any identified ‘A’ Grade risks specify:

 What type of mitigation action is proposed (preventative or contingency);

 Who is responsible for undertaking the proposed action; and

 Any cost implications for the project Budget.

16
7 Risk Monitoring
Risk Management is an iterative process that should be built into the management
processes for any project. It must be closely linked with Issues Management, as untreated
issues may become significant risks. If prevention strategies are being effective, some of
the Grade A and B Risks should be able to be downgraded fairly soon into the project.

In this section specify

 How frequently a review of the Risk and Issues Registers will be undertaken (eg.
fortnightly, monthly);

 Who will be involved in the review of the Risk and Issues Registers (eg. the Project
team);

 How often risks will be monitored to ensure that appropriate action is taken should the
likelihood, or impact, of identified risks change and to ensure that any emerging risks
are appropriately dealt with (eg. monthly);

 If the Risk Register will be maintained as a separate document or as part of the Risk
Management Plan;

 How often the Steering Committee or Project Sponsor/Senior Manager will be provided
with an updated Risk Register for consideration; and

 How often Risk status will be reported in the Project Status Reports to the Steering
Committee/Project Sponsor/Senior Manager (usually only Grade A and B risks).

8 Roles and Responsibilities

8.1 Steering Committee
Ultimate responsibility for ensuring appropriate risk management processes are applied
rests with the Project Sponsor and Project Steering Committee, and they should be involved
in the initial risk identification and analysis process. The Risk Management Plan and the
Risk Register should provide the Project Sponsor and Project Steering Committee with clear
statements of the project risks and the proposed risk management strategies to enable
ongoing management and regular review.

The Steering Committee will review the Grade A and B project risks on a <specify frequency,
eg. Monthly> basis via updated information provided in the Project Status Reports and
provide advice and direction to the Project Manager. The Steering Committee will also be
provided with an updated Risk Register for consideration, as required, when additional
threats emerge or the likelihood or potential impact of a previously identified risk changes.

17
8.2 Project Manager
The Project Manager will be responsible for:

 Development and implementation of a Project Risk Management Plan;

 Organisation of regular risk management sessions so that risks can be reviewed and
new risks identified;

 Assessment of identified risks and developing strategies to manage those risks for each
phase of the project, as they are identified;

 Ensure that risks given an A grading are closely monitored; and

 Providing regular Status Reports to the Steering Committee noting any ‘A’ Grade risks
and specifying any changes to the risks identified during each phase of the project and
the strategies adopted to manage them.

In large or complex projects, the Project Manager may choose to assign risk management
activities to a separate Risk Manager, but they should still retain responsibility. It should be
noted that large projects are a risk in themselves, and the need for the Project Manager to
reassign this integral aspect of project management may be an indication that the project
should be re-scoped, or divided into several sub-projects overseen by a Project Director.

8.3 Project Team

All members of the Project Team will be responsible for assisting the Project Manager in the
risk management process. This includes the identification, analysis and evaluation of risks
and continual monitoring throughout the project life cycle.

9 Contact Persons list in case of Emergency

(Emergency Response Team)

Person Name Designation Mobile No

Project Manager

Site Engineer

Safety Officer

18
EXECUTION OF NON-IMPLEMENTED SUBSIDIARY SEWER LINES AND SEWERAGE
HOUSE CONNECTIONS WITHIN CONTRACT (8C-2) PROJECT RISK REGISTER

APPENDIX A:

Rating for Likelihood and Seriousness for each risk

L Rated as Low E Rated as Extreme (Used for Seriousness
only)
M Rated as Medium NA Not Assessed
H Rated as High

Grade: Combined effect of Likelihood/Seriousness

Seriousness
low medium high EXTREME
low N D C A
Likelihood
medium D C B A
high C B A A

Recommended actions for grades of risk

Grade Risk mitigation actions
A Mitigation actions, to reduce the likelihood and seriousness, to be identified and
implemented as soon as the project commences as a priority.
B Mitigation actions, to reduce the likelihood and seriousness, to be identified and
appropriate actions implemented during project execution.
C Mitigation actions, to reduce the likelihood and seriousness, to be identified and costed for
possible action if funds permit.
D To be noted - no action is needed unless grading increases over time.
N To be noted - no action is needed unless grading increases over time.

Change to Grade since last assessment

NEW New risk  Grading decreased
— No change to Grade  Grading increased

Page 19
 EXECUTION OF NON-IMPLEMENTED SUBSIDIARY SEWER LINES AND SEWERAGE HOUSE CONNECTIONS WITHIN CONTRACT (8C-2)
PROJECT RISK REGISTER

Id Description of Risk Impact on L2 S3 G4 Change Date of Mitigation Actions Individual/ Cost Timeline WBS5
Project Review (Preventative or Group for
(Identification of Contingency) responsible mitigation
consequences1) for action(s)
mitigation
action(s)
<n> <A “newspaper <Describe the <Change <Date of <Specify planned <Specify who <Specify
headline” style nature of the risk in Grade last mitigation strategies: is responsible timeframe
statement. Also and the impact since last review>  Preventative for for
identify relevant on the project if review> (implement undertaking mitigation
triggers that may the risk is not immediately); each action(s) to
cause the risk to be mitigated or  Contingency mitigation be
realised.> managed> (implement if/when action(s)> completed
risk occurs).> by>

<n
+
1>

1
This can be useful in identifying appropriate mitigation actions.
2
Assessment of Likelihood.
3
Assessment of Seriousness.
4
Grade (combined effect of Likelihood/Seriousness).
5
Work Breakdown Structure – specify if the mitigation action has been included in the WBS or workplan.

Page 20
 EXECUTION OF NON-IMPLEMENTED SUBSIDIARY SEWER LINES AND SEWERAGE HOUSE CONNECTIONS WITHIN CONTRACT (8C-2)
PROJECT RISK REGISTER

1 Steering Committee Lack of

unavailable availability will
Triggers include: stall progress (ie.
 Steering delayed
Committee decisions will
meetings defer output
repeatedly finalisation,
rescheduled extend project
due to lack of timelines and
availability; staff resources
will be required
 Members do not
for longer than
attend despite
anticipated)
prior
confirmation of
attendance.

2 Inadequate funding Budget blow out

to complete the means cost
project savings must be
identified – ie.
Triggers include: reduce output
 Funding is quality, extended
redirected; timeframes,
 Costs increase outcomes
(poor quality (benefits) will be
materials/ delayed
inaccurate cost
estimates)

Page 21
 EXECUTION OF NON-IMPLEMENTED SUBSIDIARY SEWER LINES AND SEWERAGE HOUSE CONNECTIONS WITHIN CONTRACT (8C-2)
PROJECT RISK REGISTER

3 Staff reject new Rejection means

procedures additional time
Triggers include and resources
 Staff don’t required to
participate in achieve
training (not successful
prepared for implementation -
new roles); ie. Some outputs
languish; more
 New procedures
training is
not applied
required
(work-arounds
(additional cost,
still used).
time delays);
potential for
‘falling back into
old ways’ (more
change mgt
required); loss of
credibility for
project
(perception of
failure).
Note: This example is in brief and more detail would be added as required. For example, in larger projects separate documentation might be developed for each
major risk providing much more detail regarding mitigation strategies and costings.

Page 22