Risk Identification

Definitions
• Project risk is an uncertain event or condition that, if it occurs, has
a positive or negative effect on a project objective. A risk has a
cause and, if it occurs, an impact.
• Risk Identification is arguably the most important phase of the risk
process, since any risk not explicitly identified is being taken
unconsciously and unawares. It is therefore important that risk
identification receives proper attention.
• Unfortunately, the output of risk-identification techniques
frequently includes items that are not risks. This dilutes the value of
the risk process, introduces distractions at the early stages, obscures
genuine risks, and can lead to frustration and disillusionment
among participants. A clear definition of risk is vital to provide a
boundary to the risk-identification process, focusing on the two key
characteristics of risk; namely, uncertainty and effect on objectives.
Definitions
• Risk. These are uncertain events or sets of circumstances that, if
they occur, would affect the project objectives. Examples include
the possibility that planned productivity targets might not be met,
uncertainty over interest- or exchange-rate fluctuations, the
chance that client expectations may be misunderstood, or whether
a contractor might deliver earlier than planned.
• Effect. These are unplanned variations from project objectives,
either positive or negative, which arise as a result of risks
occurring. Examples include being late for a milestone, exceeding
the authorized budget, or failing to meet contractually agreed
performance targets.
Risk Metalanguage
• Risk metalanguage provides a three-part structured description of
a risk that includes cause, risk, and effect. By requiring each
element to be explicitly stated using precise words, confusion
between the three is minimized.
• The three elements of the risk metalanguage can be summarized
as follows: “As a result of <definite cause>, <uncertain event>
may occur, which would lead to <effect on objective(s)>.”
• The intention behind using the risk metalanguage is to provide a
structured framework that leads to proper identification of genuine
risks as distinct from causes or effects. It is, however, not essential
when recording risks (for example, in a Risk Register) to use all
three elements of the metalanguage description.
Risk Breakdown Structure
RBS 0
CEP Phase 2 L0

RBS 1 RBS 2 RBS 3 RBS 4

Technical External Organizational Project Mgt L1

Requirements * Customer Dependencies * Estimation

Interfaces * Regulatory Resources * Planning

Quality Market Funding Scheduling

Reliability Controlling
Physical Prioritization

Performance Change Mgt Communication

Vendor *
Artefacts * Contract * Deliverables *

Security
*
Tools/Process *
Environments *
Business Rules *
RIP - L0 Project
• Overall project risks
 Return on investment/payback period
 Will we get expected results and what results do we expect
 Goal alignment – how do we know we have been successful
 Overall cost
 Overall schedule
RIP - L1 Organization
• ORGANIZATIONAL RISKS
 Dependencies with other projects
 Resources; do we have enough resources? do the resources have the right skills?
 Funding; is the funding secured?
 Prioritization; will other projects/BAU get priority over the project
 Change management; can the organization handle the amount of change introduced by
the project?
RIP - L1 External
• EXTERNAL RISKS
 Customer; what is the risk to our customers?
 Regulatory; will the project introduce regulatory issues/risks?
 Market; is there a risk to our market? What are our competitors doing?
 Physical; do we have risks around physical facilities and resources?
 Vendor; does the vendor have the right skills? Will the vendor still be here for the
duration of the project? Does the vendor have the right processes that fits with us? Is there
a risk with timezone difference? How do we handle vendors that does not comply with
agreements? Is there an exit clause?
 Contract; Is it a T&M and if so what are the risk around overrun? If T&M what are the
rules for overruns? Does the contract have an exit clause? Are resources named or generic
(bait and switch)? How well is change management defined? What currency is the
contract in? Is there a contract arbitration defined? Early contract terminations by any
party. Invalid claims and warranties made by any contractors. Possibilities of a breach of
contract occurring due to poor contractor performance. Unethical behavior of suppliers or
contractors. Ownership of project artefacts and deliverables?
RIP - L1 Project Management
• PROJECT MANAGEMENT RISKS
 Estimation; are our estimated correct? Is there slack? Who and how was estimation
done?
 Planning; is the plan feasible? Does the plan cover all relevant areas? Is the plan
accepted/approved?
 Scheduling; is the schedule baselined? Is there a critical path? Have internal
dependencies been specified? Have the schedule been resource levelled?
 Controlling; is the project controls specific enough/timely enough to provide control of
the project?
 Communication; do we have the right formal communications? To little/to much? How
is it managed?
 Deliverables(*); is completion criteria's defined? Is quality criteria's defined? Have tasks
been defined? Do deliverables have responsible person? Do deliverables have estimates
and costs? Are resources assigned to deliverables?
RIP - L1 Technical 1
• TECHNICAL RISKS 1
 Requirements(*): are they verified? Are they prioritized? Can they be traced to
artefacts/business rules? Do we know where the requirements comes from?
 Business Rules(*): are they verified? Can they be traced to artefacts? Do we know where
it comes from? Who is responsible? Why do we have the business rule?
 Interfaces(*): Have we defined all interfaces? Have we specified type and method?
 Artefacts(*); is completion criteria's defined? Is quality criteria's defined? Have tasks
been defined? Do artefacts have responsible person? Do artefact have estimates and
costs? Are resources assigned to artefacts?
 Quality: how do we measure quality? How do we ensure quality? Who ensures quality?
 Reliability: how do we measure Reliability? What are the reliability criteria that must be
fulfilled overall/per artefact? What tools do we use? Will stress testing be conducted?
 Performance: how do we measure performance? What are the performance criteria that
must be fulfilled overall/per artefact? What tools do we use? Will load testing be
conducted?
 Processes/tools: are we using the right methodology for the type of project? Do we have
the right processes and tools? Is it agile or waterfall? Does everybody know the processes
and tools used?
RIP – L1 Technical 2
• TECHNICAL RISKS 2
 Environments(*): do we have required environments (TST, UAT, SIT, PRD)? Are they
stable? Who manages them? Is there a plan/method on how to refresh data in
environments? How is test data created and managed?
 Security: what security do we have? Is it protected during all phases of the project? What
is the security for each environment? Have the environments been security tested (pen
testing)?
 Data: do we store customer details? Do we store credit card/bank details? Who can access the data
and how? Is customer data scrubbed in TST environments?
 System: Who can access the data and how? Is there password policies? Is it possible to access
PRD remotely?
 Password policy's to system accounts? Who have access to system accounts in the different
environments especially PRD?
 Will the project to security testing?