IT Project Risk Identification

© Copyright GAFM Academy® of Project Management - Managing RISKS in IT PROJECTS
Module 4
Risk Identification

Summary
2
This module discusses the process for identifying the
various types of risks affecting an IT project. These
risks need to be identified during System Initiation
phase. A Project Risk Register will be developed by the
project team that will be referenced in the remaining
phases of the System Development Life Cycle.

Risk Identification
PROJECT EXECUTION, MONITORING & CONTROL
COMMUNICATIONS MANAGEMENT
Risk
Identification

© Copyright GAFM Academy® of Project Management - Managing RISKS in IT PROJECTS 4
Define process
model and logical
data model.
Deliverables:
• Business
Requirements
• Functional
Specification
Sign off
Project Scope
Risk Register
Project Budget
Quality Plan
Project Charter
Sign off
Define technical
architecture,
create physical
database,
prototype system
components
Deliverables:
• Technical
Specification
• Project
Management
plan
Sign off
Program
development, system
installation for
development and test
environments,
physical database
creation, software
version control
management, backup
and recovery process,
preparation of test
cases, system
integration testing.
Detail Test plan
SIT sign off
Demonstrates that
developed system
conforms to
requirements
defined in the
Functional
Specification.
User acceptance
testing.
UAT sign-off
Execute the tasks
defined in the
Project Transition
plan to efficiently
migrate the project
from the
development
environment to the
production
environment.
Conduct end user
training,
Operations and
support training.
Project closeout.
Transition sign-off
REQUIREMENTS
DESIGN
INITIATION
CONSTRUCTION
ACCEPTANCE
IMPLEMENTATION
D O C U M E N T A T I O N
T R A I N I N G
P R O J E C T R I S K M A N A G E M E N T
P R O J E C T S C O P E M A N A G E M E N T
P R O J E C T C O M M U N I C A T I O N S M A N A G E M E N T

System Development Life Cycle
5
INITIATION REQUIREMENT DESIGN CONSTRUCTION ACCEPTANCE IMPLEMENTATION
Prepare for
System Initiation
Prepare for
Requirements
Analysis
Define Technical
Architecture
Prepare DEV
Environment
Prepare UAT
Environment
Prepare
PRODUCTION
Environment
Establish Project
Team
Determine Business
Requirements
Define System
Standards
Build, Test, &
Validate
Validate Data
Conversion
System Deployment
Define Scope Define Process
Model
Database Design Prepare SIT
Environment
Execute User
Acceptance
Testing
Transition
Management
Define Cost Define Logical Data
Model
Prototype System
Components
Conduct Integration
and System Testing
Issues
Management
Project Closeout
Identify Risk
Reconcile
Requirements /
Model
Develop Testing
Strategy
Scope Management Risk Management
Define Quality Produce Functional
Specification
Validate Work
Package
Develop Project
Documentations
Update Project
Documentations
Develop Project
Charter
Risk Assessment System
Acceptance
Develop Project
Management Plan

What is Risk Identification
6
Risk identification is the process of identifying the
threats and opportunities that could occur during the life
of the project along with their associated uncertainties.

Risk Identification
The project should be analyzed for risk in areas such as:
• culture of the Performing Organization
• anticipated impact on the Performing Organization of
the resulting product or service
• the level to which the end result is defined (the more
complete the definition, the lower the possibility of
risk)
• technology used on the project (proven vs. new)
• relationships among team members
• impact on work units

Types of Risk
EXTERNAL RISK
• Regulatory
• Natural hazards
• Market risks
• Currency changes
• Inflation
INTERNAL RISK
(non-technical)
• Management
• Schedule
• Cost
• Cash Flow
TECHNICAL
• Changes in
technology
• Design
• Performance
LEGAL
• Licenses
• Patents
• Contractual
• Force Majeure
8

Technical Risk
 Inadequate or less capable resources.
 Subcontractor is not familiar with some aspect of the
project such as the technology or the application
area.
 Subcontractor does not follow a proven methodology.
 The subcontractor does not use project management
techniques that allow problems to be identified early.
 Physical separation leads to technical
incompatibilities: You cannot run what the
subcontractor has produced.
9

Operational Risk
 The subcontractor’s staff goes on strike.
 The subcontractor lands a higher-priority project and
diverts key resources to other project.
 The physical distance to the subcontractor leads to
misunderstandings and confusion, as well as to
reduced visibility.
 Transportation causes problems. (The transporter is
also a subcontractor and is subject to many of these
risks.)
 Customs regulations delay import into your country
or export from the subcontractor’s country.
10

Financial Risk
 The subcontractor goes bankrupt.
 The subcontractor holds up shipment because your company
has not paid its last bills.
 The subcontractor uses your schedule as a means to extract
extra costs.
 The subcontractor “baits and switches,” replacing the high-
quality resources that were proposed with less capable
people.

Technical, quality or performance risks
 unproven or complex technology
 unrealistic performance goals
 changes to the technology used
 changes to the industry standards
12

Project management risks
 poor allocation of time and resources
 inadequate quality of the project plan
 poor use of project management tools and techniques
13

Organizational risks
 cost, time, and scope
objectives that are
internally inconsistent
 lack of prioritization of
projects
 inadequacy or
interruption of funding,
and resource conflicts
with other projects
14

External risks
 Changes in legal or
regulatory environment
 Labor issues, changing
owner priorities, country
risk, and weather.
 Force majeure risks
such as earthquakes,
floods, and tsunami
15

Historical Information
Information on risk from past projects may
be available from project files or published
through commercial, public databases,
articles, international papers from
conferences, seminars, or academic
sources. This can be a quick and reliable
source of information in identifying risk.
16

Risks associated with Subcontractor
 The subcontractor will not assign adequate or capable
resources.
 The subcontractor is not familiar with some aspect of
the project such as the technology or the application
area.
 The subcontractor does not follow a proven
methodology.
 The subcontractor does not use project management
techniques that allow problems to be identified early.
17

 The subcontractor’s staff goes on strike.
 The subcontractor lands a higher-priority project and
diverts key resources to another project.
 The physical distance to the subcontractor leads to
misunderstandings and confusion, as well as to reduced
visibility.
 Transportation causes problems. (The transporter is also
a subcontractor and is subject to many of these risks.)
 Customs regulations delay import into your country or
export from the subcontractor’s country.
18

 The subcontractor goes bankrupt.
 The subcontractor holds up shipment because your
company has not paid its last bills.
 The subcontractor uses your schedule as a means to
extract extra costs.
 The subcontractor “baits and switches,” replacing the high-
quality resources that were proposed with less capable
people.

Identify risks that impacted
Cost, Scope, Schedule, and Quality

Risk level varies depending upon how
much information received
No
Information
Partial
Information
Complete
Information
Unknown
Unknowns
Known
Unknown
Known
Known
Complete
UNCERTAINTY
Partial
UNCERTAINTY
Almost zero
UNCERTAINTY
degree of risks Very LowVery High
A project scope is subject to varying levels of risk depending
upon the information acquired regarding the risk and its
impact.

Risks affecting Scope of the project
Risks associated with changes in scope of the project
and/or scope of the product or service.
Risk conditions
 Additional requirements for “fixes” to achieve the required
technical deliverables.
 Poor definition of the scope breakdown.
 Inadequate scope control during implementation.
 Inadequate planning lead time.
 Unclear definition of business requirements.
22

Risks affecting Quality
Failure to complete tasks to the required level of
technical or quality performance.
Risk conditions
 Substandard design / materials / workmanship
 Inadequate quality assurance program
 Poor attitude to quality
23

Risks affecting project Schedule
Failure to complete the tasks within the project
schedule.
Risk conditions
 Errors in estimating time
 Errors in estimating resource availability
 Changes in scope of work without allowance for time
extensions
24

Risks affecting project Budget
Failure to complete tasks within the budget.
Risk conditions
 Unpredictable price changes
 Changes in currency fluctuations during procurement of
materials and resources
 Poor estimation of risk contingencies affecting labor,
material, and expenses
 Uncontrollable third party cost of resources or services.
25

Gathering information
26
Project
Sponsor
A person with the strategic vision is in a unique position
to identify risks that others may not know
Project Team
Members
Make certain to tap the team member’s knowledge
once the work has commenced
Stakeholders Stakeholders understand the risks associated with their
own business units and the business aspects of the
project.
Technical
Experts
IT experts, Engineers, Researchers, Construction
specialists, Policy makers, Business Process Analyst
can contribute toward the technical aspects of the
project

Gathering information (contd.)
27
Customers
End Users
The customer, or end user, understands the goals of the
project from a different perspective than the other project
participants.
Vendors Have experience working on similar projects can provide
insights to risks that may occur in all stages of the project
Other Project
Managers
Other Project Managers may share their views on your
list of risks.
Industry group LinkedIn and other professional network will be a good
source of information.
People with
previous
experience
Identify employee with previous experience in one area
of the business, human resource skills profiling
database.

Risks affecting a project
 Scope – risks associated with changes in scope, or the
subsequent need for “fixes” to achieve the required technical
deliverables.
 Quality – failure to complete tasks to the required level of
technical or quality performance.
 Time – failure to complete tasks within the project schedule.
 Cost – failure to complete tasks within the agreed budget.
Risk Management is the process in which risks are identified,
analyzed, prioritized, and determine what actions need to be taken
to avert these threats. Scope, cost, time, and quality are affected
by these threats.

Risk Owner
 Help develop the risk response and risk trigger and carry
out the execution of the risk response, if a risk event
occurs.
 Participate in the review, re-evaluation, and modification of
the probability and impact for each risk item on a weekly
basis.
 Identify and participate in the analysis of any new risks that
occur.
 Escalate issues/problems to Project Manager for those
risks :
 That significantly impact the projects triple constraint
 That require action prior to the next weekly review
 Where the risk response strategies are not effective
causing the need to execute the contingency plan.
29

Project Manager’s role in managing
risk
 Developing the Risk Register and Risk Management Plan.
 Continuous monitoring of the risk defined in the Risk
Register.
 Implementing the planned mitigation strategies.
 Continuous monitoring of the effectiveness of the Risk
Management Plan.
 Regular reporting on the status of risk to the Project
Sponsor and the Steering Committee.
30

Stakeholders role in risk management
 The Project Sponsor has ultimate accountability for risk
management. Project Sponsor ensure there are adequate
resources for managing the project’s risks and there is active
participation by a wide cross-section of stakeholders.
 The Steering Committee oversees the Risk Management
Plan and its periodic review.
 The Project Manager is responsible for monitoring and
managing all aspects of the risk management process under
the direction of the Project Sponsor/Steering Committee.
31

Impact to project objectives
The probability of risk occurring must be analysed against its impact to
project Budget, Scope, Schedule, Quality, and Resources.

Document Risk
After risk has been identified , the list of risks are usually registered
in a document called the Risk Register.
OUTPUT
Initial
Risk
Register
Risk Worksheet
INPUT
Perform Risk Identification
PROCESS
Using available tools eg Excel, the Project Manager can easily
register project risk and update these further during Planning phase.

Perform Risk Identification
Deliverable : Initial Risk Register
Initial Risk Register is the
only deliverable produced
after you have completed the
process “Perform Risk
Identification”
Initial Risk Register will be
revised further during
Planning phase to produce
the Project Risk Management
Plan.
Initial
Risk
Register

Techniques in identifying risks
 Reviewing Project Documents
 Interviews
 Brainstorming
 Nominal Group Technique
 Delphi Technique
 Status Meeting
 Assumptions analysis
 Diagramming Technique
35

Reviewing Project Documents
 Documentation reviews include a structured review of the
project plans and assumptions, both at the total project and
detailed scope levels as well as reviews of prior project files
and other information sources.
 Peer level reviews of project documentation, studies,
reports, preliminary plans, estimates and schedules are a
common and early method to help identify risks that may
affect project objectives.
36

Interviews
 Interviewing technique involves question and answer
sessions with:
 Experts
 Stakeholders
 Managers
 Project team members
 Business Process Analysts
 Other Project Managers
 Use Project Scope document and Work Breakdown
Structure as your input during the interviewing process.
37

Brainstorming
 Brainstorming is useful when project participants work at the
same location or are able to meet easily at a central location.
 Participants will highlight their risks interactively.
 Formal and informal brainstorming sessions are conducted in a
meeting room with project team members and other stakeholders
such as specialty groups and regulatory agency representatives.
 Performed by the project team, although a multidisciplinary set of
experts under the leadership of a facilitator or project manager.
 Sources of risk are identified in broad scope, posted, categorized
by type of risk, and then the definitions sharpened.
 Setback: Stronger group may dominate the discussion over more
timid group members.
38

Nominal Group Technique
 Similar to brainstorming, the
difference is that the
participants are required to
write down the list of risks on a
piece of sticky paper to be
handed over to the facilitator.
 Risks are not addressed
interactively, avoiding
domineering by stronger group.
39

Using the Delphi Technique
 Delphi technique uses questionnaires aimed at participants
who have subject matter expertise.
 Does not require a meeting.
 Questionnaires are distributed via emails or intranet site.
 Ideal for project participants who are not located together
geographically or those who find it difficult to attend a
meeting.
 The responses are submitted and then circulated to the
experts for further comment. Consensus may be reached in a
few rounds of this process.
 This technique helps reduce bias in the data and keeps any
person from having undue influence on the outcome.
40

Delphi Technique

Status Meetings
 Access the current phase of the project and the risks
associated in that particular phase.
 Discuss the risks that have already occurred.
 Discuss the impacts of those risk events that have
happened.
 Review the risk plans, and determine if they are working
 Determine if new risk events are likely to surface as a
result of response plans on past risks.
 Open the meeting to discuss new risks not previously
identified.
42

Assumptions analysis
 Every project is conceived and developed based
on a set of hypotheses, scenarios, or
assumptions.
 Assumptions analysis is a technique that
explores whether or not the assumptions are
valid.
 Identifies project risks from inaccuracy,
inconsistency, or incompleteness of
assumptions.

Diagramming technique
44
Ishikawa diagram also known as “fishbone” diagram is a popular
technique to look at the root cause of problems or issues.

Risk impact to project
 Analyze risk impact to the project objectives.
 Risks can result in four types of consequences:
 Changes affecting the project scope directly impacted
scope of the Product or Service
 The schedule may be extended
 Budget may increase
 Quality will be affected
45

Grading risk based upon Likelihood
and Consequences
46
Risks should be analyzed and evaluated in terms of likelihood
of occurrences and magnitude of consequences if they do
occur.

Extreme classification for Large or
Complex Project
In the case of larger or more complex projects, the matrix should be
expanded to ensure an “A” grading is automatically assigned to any risks
defined as extremely high consequences.

Recommended actions for grading 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
identified and appropriate actions implemented during project execution.
C
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.
Mitigation of risks involves the identification of actions to reduce the
likelihood that a threat will occur (preventative action) or reduce the impact
of a threat that does occur (contingency action).

Risk Mitigation strategies
 Preventative - planned actions to reduce the likelihood a
risk will occur. In other words, what should you do to
reduce the likelihood of this risk from occurring?
 Contingency - planned actions to reduce the seriousness
of the risk if it does occur. In other words, once the risk has
occurred, what will be your recovery actions to allow you to
move on and these plans of actions should be built into the
work breakdown structure for your project.
49

Risks affecting Scope of the Project
Changes in project scope to meet product requirements. e.g.
regulatory changes
Impact:
 More time is required to deliver additional material as a result of
changes in scope.
 More resources are required to execute the additional work
defined in the WBS.
 Additional work to meet the quality requirements of the project
has resulted in an increased in the project budget.
50

Risks arising from Subcontracting work
- Poaching of personnel
Subcontractor may campaign to work directly with your
customer or recruit key personnel from your organization.
PREVENTATIVE MEASURES
 Ensure that the subcontract includes an appropriate clause to
prevent solicitation of work or recruitment of your employees by the
subcontractor.
 Ensure that all contractual communications are channelled via your
company.
 Where the subcontractor is a known competitor restrict access
appropriately.
 Be aware of the dangers and escalate to your commercial manager
should any contravention be suspected.
51

Risks arising from Subcontracting work
- Poor Change Control
Subcontractor may initiate uncontrolled changes (e.g.
add/remove functionality) through ad-hoc
communications.
 The Statement of Work (SOW) should include a full Change Control
Procedure and this should be referenced in the subcontract
document.
 Ensure that approval authority for changes is assigned by both
parties.
 Ensure that your customer is aware of the formal Change Control
Procedure and that changes cannot be introduced directly to
subcontractors.
52

Risk arising from Subcontracting work
- Incompatible Working Practices
Methods, standards and cultural differences may differ from expectations
and cause friction in communications and make it difficult to gauge progress.
 Ensure that the SOW requires the subcontractor to supply a description
of its standard procedures and how these will be employed to undertake
the subcontract works.
 Detail the reporting requirements in the SOW.
 Obtain an organizational chart for the subcontracted resources to be
employed in the project with channels for escalation.
 Ensure that the subcontract kick-off meeting includes a review of
working practice alignment and have available templates for key
deliverable documents.
 Ensure that sufficient provision for progress meetings is made.
53

Risks associated with Procurement of
Products / Services
 Limited availability
 Complex to manufacture
 Integration of the product into existing environment
 Delays in delivery, testing and installation
 Unsafe use of hazardous materials
 Final product or service does not meet expectations
54

Risks associated with Procurement
Process
 Changes to scope or specifications
 Proper processes are not followed
 Risks are not adequately managed
 Tender process does not achieve value for money
 Government policies, not followed
55

Risks associated with Contract
Management
 Unrealistic time / cost expectations
 Conflict with existing contracts/supply
arrangements
 Limited capacity to access necessary information
 Legal complexities
 Delays in obtaining approvals
 Incorrect method of approach selected
56

Fixed-Price Contract
 Fixed-price contracts (also known as firm-fixed-price and
lump-sum contracts) are agreements that define a total price
for the product that the Seller need to provide.
 Fixed-price contracts must clearly define the requirements
that will be provided by the Vendor.
 Fixed-price contracts may also provide incentives for meeting
or exceeding contract requirements such as meeting
deadlines.
 Fixed-price contracts usually require the Seller to assume the
risk of cost overruns.
57

Cost-Reimbursable Contract
58
Contract Type Acronym Attribute Risk Issues
Cost Plus
Fixed Fee
CPFF Actual costs plus
profit margin for
seller
Cost overruns represent risk
to the buyer.
Cost Plus
Percentage of
Cost
CPPC Actual costs plus
profit margin for
seller.
to the buyer. This is the
most dangerous contract
type for the buyer.
Cost Plus
Incentive Fee
CPIF Actual costs plus
profit margin for
seller.
to the buyer.

Types of Contract and Risk variations
Cost Plus Percentage of Costs
Cost Plus Fixed Fee
Cost Plus Incentive Fee
Fixed-Price Fee
Time and Material
Buyer’s Risk
Sellers’sRisk
Highest Risk
High Risk
Medium Risk
Low
LowRisk
High
LowRisk
LowRisk
T&M can be a high risk for Buyer if contract does not include a “total not-to-
exceed” (NTE) clause.

Risk Breakdown Structure
60

 After you have identified the Risk, the next step is to develop the
Risk Register.
 Risk Register records details of all the risks identified at the
beginning and during the life of the project.
 Risk Register records their grading in terms of likelihood of
occurrences and seriousness of impact on the project.
 Risk Register record initial plans for mitigating each high level risk.
 Risk Register defines the costs and responsibilities of the prescribed
mitigation strategies and subsequent results.
 The Register should be maintained throughout the project and will
be updated regularly as existing risks are re-graded in the light of the
effectiveness of the mitigation strategy, and new risks are identified
61
Risk Register

 Has a unique Identifier for each risk item
 A description of each risk and how it will affect the project
 An assessment of the likelihood of occurrence and the
seriousness of an impact if it does occur (low, medium, high)
 A grading of each risk with reference to a risk assessment
table.
 A Risk Owner who is responsible for managing the risk
 An outline of proposed mitigation actions (prevention and
contingency)
 Costing for each mitigation strategy
62
Characteristics of a Risk Register

Why Would You Develop the Risk
Register?
 It provides a useful tool for managing and reducing the risks
identified before and during the project
 It documents risk mitigation strategies in response to the identified
risks and their grading in terms of likelihood and seriousness
 It provides the Project Sponsor, Steering Committee with a
documented framework from which risk status can be reported.
 To ensure the communication of risk management issues to key
stakeholders
 It provides a mechanism for seeking and acting on feedback to
encourage the involvement of the key stakeholders
 To identify the mitigation actions required for implementation of the
risk management plan and associated costs.
63

When would You Develop the Risk
Register
 Risk should be documented at the Conceptual phase or the
Origination phase of a project  Initial Risk Assessment
document.
 This initial risk assessment will form part of the Project Proposal
or Business Case for the project.
 Once the project is approved the Risk Management Plan and
Risk Register should be fully developed.
 In the case of smaller projects the Risk Register is sufficient to
serve as the Risk Management Plan.
64

Checklist prior to developing the Risk
Register
 Knowledge and understanding of the project.
 Knowledge and understanding of the Key Stakeholders.
 Knowledge and understanding of appropriate types of risk
management activities, or where to obtain them.
 Project Proposal/Brief, Project Business Case, or Project
Business Plan.
65

Components of a Risk Register
 Dates: As the register is a living document, it is important to record the
date that risks are identified or modified. Optional dates to include are
the target and completion dates.
 Description of the Risk: A phrase that describes the risk.
 Risk type (business, project, stage): Classification of the risk, business
risks relate to delivery of achieved benefits, project risks relate to the
management of the project such as
 Timeframes and resources, stage risks are risks associated with a
specific stage plan.
 The likelihood of occurrence: Provides an assessment of how likely it
is that this risk will occur.
 Examples of classifications are: L-Low (<30%), M-Medium (31-70%),
H-High (>70%).
66

Components of a Risk Register
 Severity of effect: Provides an assessment of the impact that the
occurrence of this risk would have on the project.
 Counter Measures: Action to be taken to prevent, reduce or
transfer the risk. This may include production of contingency
plans.
 Owner: Individual responsible must ensure that this risk is
managed and counter measures are undertaken.
 Status: Indicates whether this is a current risk or if risk can no
longer arise and impact the project.
Example classifications are: C-current or E-ended.
 Other columns such as quantitative value can also be added if
appropriate.
67

No. Rank Risk Description Category Root
Cause
Triggers Potential
Responses
Risk
Owner
Probability Impact Severity Status
R44 1
R21 2
R7 3
68
Sample
Risk Register
 Project severity = expectation (1-10) * impact (1-10)
 When should risk analysis be formed?
 Is not a time activity
 Periodic update and reviewed

end of module

IT Project Risk Identification

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (16)

Similar to IT Project Risk Identification

Similar to IT Project Risk Identification (20)

More from GAFM Academy of Project Management ® - ISO 29990 Certified International Board of Standards

More from GAFM Academy of Project Management ® - ISO 29990 Certified International Board of Standards (12)

Recently uploaded

Recently uploaded (20)

IT Project Risk Identification