Project Outcome

Succeeded: is completed & on time & on budget with all features and functions as specified.

Failed: is cancelled before completion, never implemented or scrapped following installation.

Challenged: is completed & operational but over budget, late & with fewer features & functions than initially specified.

Success Criteria

Number	Success Criteria	Points
1	User involvement	19
2	Executive management support	16
3	Clear statement of requirements	15
4	Proper planning	11
5	Realistic expectations	10
6	Smaller project milestones	9
7	Competent staff	8
8	ownership	6
9	Clear vision and objectives	3
10	Hard-working, focused staff	3
Total		100

Data source from Standish group, 2006

Top 5 success factors

1. User involvement

2. Executive management support

3. Clear statement of requirements

4. Proper planning

5. Realistic expectations

Top 5 Key Risks

misunderstanding the project’s requirements

Failure to gain user commitment/involvement

Lack of project management skills

Insufficient Staff

Changing project’s scope/objectives

Size Is Important

Success by Project Size

Standish Group, ‘99 (www.standishgroup.com)

The “Inverted Pyramid” principle

as used by Newspapers around the world

Lead: Agile works, but it is hard work.

1. Mistake requirements for features.

2. Produce software each iteration which still needs to be properly tested (or can’t be potentially shipped).

3. Sacrifice quality for speed.

4. Accept a customer / decision maker who can’t or won’t prioritise features well.

5. Set up the project so that YOU bear the cost when the customer’s changing their mind.

6. Ignore old problems that are no longer hidden.

7. Think Agile is not just about Software, or Projects, or Money but also about marketing and relationships.

The problem? Agile looks easy

1. Customer lists known requirements (to a high level), then prioritises– f(value,effort).

2. Deliver time-boxed increments of high-value, well engineered, Working software often

3. The Customer can release the software at any time they want.

4. The Customer can add, delete or reprioritise features at any time. i.e. this is how we “embrace change”

5. We protect schedule commitments, despite change

Project Risks

What can go wrong?

What will the damage be?

What is the likelihood?

What can we do about it?

The GOAL is to deliver quality products on time and on budget that meet the customer’s real needs.

Retrospective (learning from experience)

What has worked? (do more, continue or although it worked but can we do better next time?)

What did not work? (reason can’t fix or stop or is still puzzling)

How can you improve your project? (based on feedback and then create possible solutions or actions)

Inspect/review and Adapt change

Risk Management

Introduction

How to analyse and manage of risks associated with a project.

It has sometimes been claimed that all project management is risk management.

The aim of the project manager is to combat the variety of different hazards to which a project may be exposed.

Essentially there are two parts to this work:

risk identification and analysis

risk management (risk management planning, risk response planning, and risk monitoring and control)

The IT Risk Management Process

A Framework for Integrated IT Risk Management

The risk management process

Techniques for managing risks including:

Risk management planning,

it can help improve project success by helping select good projects, and developing realistic estimates.

risk identification,

To determine which risks are likely affect a project and documenting the characteristics of each.

risk analysis,

Prioritising risks based on their probability and impact of occurrence.

Use various tools and techniques to rank risks and update information in the risk register.

The main output is risk register update.

risk monitoring and control

Include monitoring identified risks, identifying new risks, carrying out risk response plans and evaluating the effectiveness of risk strategies through out the life of the project.

Source from “IT project management, Kethy Schwalbe

Table 11-4. Potential Negative Risk Conditions Associated With Each Knowledge Area

Knowledge Area	Risk Conditions
Integration	Inadequate planning; poor resource allocation; poor integration management; lack of post-project review
Scope	Poor definition of scope or work packages; incomplete definition
Time	Errors in estimating time or resources availability; errors in determining the critical path; poor allocation and management of float; early release of competitive products
Cost	Estimating errors; inadequate productivity, cost, change, or contingency
Quality	Poor attitude toward quality; substandard design material and workmanship; inadequate quality assurance program
Human resources	Poor conflict management; poor project organisation and definition of responsibilities; absense of leadership
Communications	Carelessness in planning or communicating
Risk	Ignoring risk; unclear analysis of risk; poor insurance management
Procurement	Unenforceable conditions or contract clauses; adversarial management
Stakeholders	Lack of consultation with key stakeholder

Identifying Risks

Identifying risks is the process of understanding what potential events might hurt or enhance a particular project

Another consideration is the likelihood of advanced discovery

Risk identification tools and techniques include:

Brainstorming

The Delphi Technique

Interviewing

SWOT analysis

Risk Breakdown Structure

Brainstorming

Brainstorming is a technique by which a group attempts to generate ideas or find a solution for a specific problem by amassing ideas spontaneously and without judgment

An experienced facilitator should run the brainstorming session

Be careful not to overuse or misuse brainstorming.

Psychology literature shows that individuals produce a greater number of ideas working alone than they do through brainstorming in small, face-to-face groups

Group effects often inhibit idea generation

Delphi Technique

The Delphi Technique is used to derive a consensus among a panel of experts who make predictions about future developments

Provides independent and anonymous input regarding future events

Uses repeated rounds of questioning and written responses and avoids the biasing effects possible in oral methods, such as brainstorming

Interviewing

Interviewing is a fact-finding technique for collecting information in face-to-face, phone, e-mail, or instant-messaging discussions

Interviewing people with similar project experience is an important tool for identifying potential risks

SWOT Analysis

SWOT analysis (strengths, weaknesses, opportunities, and threats) can also be used during risk identification

Helps identify the broad negative and positive risks that apply to a project

Risk Breakdown Structure (RBS)

A risk breakdown structure is a hierarchy of potential risk categories for a project

RBS illustrates potential sources of risk.

Similar to a work breakdown structure but used to identify and categorise risks

Each descending level represents an increasing ly detailed definition of sources of risk to the project.

RBS acts as a prompt ad an aid to support the project management team in thinking through the potential sources of risk to the objectives.

Risk identification

May be a team activities or based on the individual project manager’s experience.

A checklist of common risks may be used to identify risks in a project

Technology risks.

Organisational risks.

People risks.

Requirements risks.

Estimation risks.

Sample Risk Breakdown Structure

Risk indicators

Risk type	Potential indicators
Estimation	Failure to meet agreed schedule; failure to clear reported defects.
Organisational	Organisational gossip; lack of action by senior management.
People	Poor staff morale; poor relationships amongst team members; high staff turnover.
Requirements	Many requirements change requests; customer complaints.
Technology	Late delivery of hardware or support software; many reported technology problems.
Tools	Reluctance by team members to use tools; complaints about CASE tools; demands for higher-powered workstations.

Examples of different risk types

Risk Type	Possible Risks
Estimation	The time required to develop the software is underestimated. (12) The rate of defect repair is underestimated. (13) The size of the software is underestimated. (14)
Organisational	The organisation is restructured so that different management are responsible for the project. (6) Organisational financial problems force reductions in the project budget. (7)
People	It is impossible to recruit staff with the skills required. (3) Key staff are ill and unavailable at critical times. (4) Required training for staff is not available. (5)
Requirements	Changes to requirements that require major design rework are proposed. (10) Customers fail to understand the impact of requirements changes. (11)
Technology	The database used in the system cannot process as many transactions per second as expected. (1) Reusable software components contain defects that mean they cannot be reused as planned. (2)
Tools	The code generated by software code generation tools is inefficient. (8) Software tools cannot work together in an integrated way. (9)

Examples of project, product, and business risks

Risk	Affects	Description
Staff turnover	Project	Experienced staff will leave the project before it is finished.
Management change	Project	There will be a change of organisational management with different priorities.
Hardware unavailability	Project	Hardware that is essential for the project will not be delivered on schedule.
Requirements change	Project and product	There will be a larger number of changes to the requirements than anticipated.
Specification delays	Project and product	Specifications of essential interfaces are not available on schedule.
Size underestimate	Project and product	The size of the system has been underestimated.
CASE tool underperformance	Product	CASE tools, which support the project, do not perform as anticipated.
Technology change	Business	The underlying technology on which the system is built is superseded by new technology.
Product competition	Business	A competitive product is marketed before the system is completed.

Data source: Sommerville, 2016, software Engineering, chapter 22

Risk Register

The main output of the risk identification process is a list of identified risks and other information needed to begin creating a risk register

A risk register is:

A document that contains the results of various risk management processes and that is often displayed in a table or spreadsheet format

A tool for documenting potential risk events and related information

Risk events refer to specific, uncertain events that may occur to the detriment or enhancement of the project

Risk Register Contents

An identification number for each risk event

A rank for each risk event

The name of each risk event

A description of each risk event

The category under which each risk event falls

The root cause of each risk

Triggers for each risk; triggers are indicators or symptoms of actual risk events

Potential responses to each risk

The risk owner or person who will own or take responsibility for each risk

The probability and impact of each risk occurring.

The status of each risk

Table 11-5. Sample Risk Register

No.: R44

Rank: 1

Risk: New customer

Description: We have never done a project for this organization before and don’t know too much about them. One of our company’s strengths is building good customer relationships, which often leads to further projects with that customer. We might have trouble working with this customer because they are new to us.

Category: People risk

Etc.

Risk : The risk stated in a complete sentence which states the cause of the risk, the risk, and the effect that the risk causes to the project.

Risk Category: Categorization of risks by area of project affected, source of risk or other useful category.

Root cause: This should describe the source of the risk, i.e. the event ( risk event is the area of uncertainty in terms of the threat or the opportunity)or situation that gives rise to the risk

Probability: The likelihood that a risk or opportunity will occur (on a scale from 0 to 10 with 10 being the highest).

Impact: The impact of the risk on the project if the risk occurs (scale from 0 to 10 with 10 being the highest).

Risk Score: Determined by multiplying probability and impact (scale from 0 to 100).

Impact: The impact of the risk on the project if the risk occurs (scale from 0 to 10 with 10 being the highest).

Risk Score: Determined by multiplying probability and impact (scale from 0 to 100).

Risk Ranking: A priority list which is determined by the relative ranking of the risks is (by their scores) within the project with the number one being the highest risk score.

Risk Response: The action is which is to be taken if this risk occurs.

Trigger: Something which indicates that a risk is about to occur or has already happened.

Partial risk Register

Partial Risk Register
Risk	Description	Category	Root Cause	Triggers	Potential Responses
Attrition	Key team members leaving co.	Staffing	Lack of incentives to stay	Late, lack of interest	More personal attention, incentives to stay
Uncoop. Users	Users are not cooperating, causing problems	Conflict	No plan for conflict management	Poor team dynamics	Develop a conflict management plan, provide training
Poor info	Not getting complete status info	Communications	No guide-lines for creating info	Poor status reports	Provide guidelines and personal training
Improve team health	Several team members want to improve health	Health/morale	Lack of attention to health	More energy, less sick days	Provide incentives to have team improve health, contest for participation/ improvement
Earn bonuses	If team does well, could get bonuses	Incentives	Desire to do well	Meeting/beating plans, good mgt feedback	Develop plan for earning bonuses

Risk types and examples

Risk	Probability	Effects
Organisational financial problems force reductions in the project budget (7).	Low	Catastrophic
It is impossible to recruit staff with the skills required for the project (3).	High	Catastrophic
Key staff are ill at critical times in the project (4).	Moderate	Serious
Faults in reusable software components have to be repaired before these components are reused. (2).	Moderate	Serious
Changes to requirements that require major design rework are proposed (10).	Moderate	Serious
The organisation is restructured so that different management are responsible for the project (6).	High	Serious
The database used in the system cannot process as many transactions per second as expected (1).	Moderate	Serious
The time required to develop the software is underestimated (12).	High	Serious
Software tools cannot be integrated (9).	High	Tolerable
Customers fail to understand the impact of requirements changes (11).	Moderate	Tolerable
Required training for staff is not available (5).	Moderate	Tolerable
The rate of defect repair is underestimated (13).	Moderate	Tolerable
The size of the software is underestimated (14).	High	Tolerable
Code generated by code generation tools is inefficient (8).	Moderate	Insignificant

Performing Qualitative Risk Analysis

Assess the likelihood and impact of identified risks to determine their magnitude and priority

Risk quantification tools and techniques include:

Probability/impact matrixes

The Top Ten Risk Item Tracking

Expert judgment

Probability/Impact Matrix

A probability/impact matrix or chart lists the relative probability of a risk occurring on one side of a matrix or axis on a chart and the relative impact of the risk occurring on the other

List the risks and then label each one as high, medium, or low in terms of its probability of occurrence and its impact if it did occur

Can also calculate risk factors:

Numbers that represent the overall risk of specific events based on their probability of occurring and the consequences to the project if they do occur

Top Ten Risk Item Tracking

Top Ten Risk Item Tracking is a qualitative risk analysis tool that helps to identify risks and maintain an awareness of risks throughout the life of a project

Establish a periodic review of the top ten project risk items

List the current ranking, previous ranking, number of times the risk appears on the list over a period of time, and a summary of progress made in resolving the risk item

Table 11-6. Example of Top Ten Risk Item Tracking

MONTHLY RANKING
Risk Event	Rank This Month	Rank Last Month	Number of Months in Top Ten	Risk Resolution Progress
Inadequate planning	1	2	4	Working on revising the entire project management plan
Poor definition	2	3	3	Holding meetings with project customer and sponsor to clarify scope
Absense of leadership	3	1	2	After previous project manager quit, assigned a new one to lead the project
Poor cost estimates	4	4	3	Revising cost estimates
Poor time estimates	5	5	3	Revising schedule estimates

Watch List

A watch list is a list of risks that are low priority, but are still identified as potential risks

Qualitative analysis can also identify risks that should be evaluated on a quantitative basis

Risk Response Planning

After identifying and quantifying risks, you must decide how to respond to them

Four main response strategies for negative risks:

Risk avoidance:

Identified risks are avoided through a different course of action

Risk acceptance:

Risks are accepted and contingency strategies are planned

Risk transference:

Transfer of risk to another party through the use of contracts

Risk mitigation:

Steps are taken to reduce the occurrence or impact of stated risks

Threat Responses	Opportunity Responses
Avoid (e.g. cancel the project (not even join the game!)	Exploit
Reduce: probability and/or impact (e.g. add extra resource because worrying Fallback: reduces impact only Transfer: reduces impact only, and often only the financial impact	Enhance
Share (lose or opportunity)	Share (lose or opportunity)
Accept (do nothing, e.g. record risks, monitor risks etc)	Reject (data source: PRINCE2, p.85)

Risk Assessment Example Management

A key employee with wide access to restricted and privileged information about a project to develop a new product becomes dissatisfied, leaves her employer and takes the knowledge she has acquired to a new employer-the firm’s main rival. This has now jeopardised the project to develop the new product, since it becomes highly likely that the rival firm will develop a competing product very quickly. The project was sensitive to the risk of specialist knowledge becoming available to a rival firm.

Only when we have identified risks and have an idea of their likelihood can we plan what to do about them, and gauge their impact on project estimates, budgets and schedules.

Techniques for managing risks including:

risk response planning:

take steps to gain opportunities and reduce threats to meet project objectives. Using outputs from the preceding risk management processes, project team can develop risk responds strategies that often result in updates to the risk register. E.g. PM plan, risk related contract decisions.

Risk Management

Key Definitions

1. RISK-

The potential for occurrences that would be detrimental to the project.

Risk is measured as the combined effect of the likelihood of the occurrence and

a measured or assessed consequence given that occurrence.

2. RISK IDENTIFICATION AND ANALYSIS-

means assessing the probability of risks occurring and their impact on the project.

3. RISK MANAGEMENT

is what the project manager does to respond or prepare for the risks.

Reactive Risk Management

project team reacts to risks when they occur

mitigation—plan for additional resources in anticipation of fire fighting

fix on failure—resource are found and applied when the risk strikes

crisis management—failure does not respond to applied resources and project is in jeopardy

Proactive Risk Management

formal risk analysis is performed

organisation corrects the root causes of risk

examining risk sources that lie beyond the bounds of the software

developing the skill to manage change

Technology, Teams and Managing Risk

Volatile nature of technology

Technology may also influence project risk by giving project managers new tools to assess risk

e.g. knowledge management systems can help in risk identification

Forming teams during projects incorporates risk

Risk & Project Life Cycle

Initiation stage

Identification and selection of specific projects

Inside or outside of organization’s core competencies

Planning stage

Procurement

Unreliability of new technology delivery timeframe

Development of accurate project schedule

Execution stage

Missed scheduled delivery date

Technology upgrades

Control stage

Implementation of risk plan

Modification of project schedule

Closing stage

Acceptance of project as finished

General Categories of IT Project Risk

Ongoing changes to technology

Finding, assigning, and retaining skilled personnel

Gaining user acceptance

Choosing the correct development methodology

Outsourcing / Offshoring

Positives:

Expanded skill set availability

Cheaper labor

Reduced requirements for non-core competencies

Negatives:

Internal resistance

Possible solutions to reduce risk:

Ensure strong upper management support

Select the right personnel

Involve managers early in the outsourcing process

Educate and reassure internal employees

Increased security and privacy concerns

Possible solutions to reduce risk:

Increase physical security measures

Use software event logging and monitoring tools

Intrusion detection systems and firewalls

Encryption hardware/software

Topics Addressed in a Risk Management Plan

Methodology

Roles and responsibilities

Budget and schedule

Risk categories

Risk probability and impact

Risk documentation

Contingency and Fallback Plans, Contingency Reserves

Contingency plans are predefined actions that the project team will take if an identified risk event occurs

Fallback plans are developed for risks that have a high impact on meeting project objectives, and are put into effect if attempts to reduce the risk are not effective

Contingency reserves or allowances are provisions held by the project sponsor or organization to reduce the risk of cost or schedule overruns to an acceptable level/risk tolerance level

Broad Categories of Risk

Market risk

Financial risk

Technology risk

People risk

Structure/process risk

Risk Breakdown Structure

A risk breakdown structure is a hierarchy of potential risk categories for a project

Similar to a work breakdown structure but used to identify and categorise risks

Potential Negative Risk Conditions Associated With Each Knowledge Area

Knowledge Area	Risk Conditions
Integration	Inadequate planning; poor resource allocation; poor integration management; lack of post-project review
Scope	Poor definition of scope or work packages; incomplete definition
Time	Errors in estimating time or resource availability; errors in determining the critical path; poor allocation and management of float; early release of competitive products
Cost	Estimating errors; inadequate productivity, cost, change, or contingency
Quality	Poor attitude toward quality; substandard design/materials/workmanship; inadequate quality assurance program
Human Resources	poor conflict management; poor project organisation and definition of responsibilities; absense of leadership
Communications	Carelessness in planning or communicating; lack of consultation with key stakeholders
Risk	Ignoring risk; unclear analysis of risk; poor insurance management
Procurement	Unenforceable conditions or contract clauses; adversarial realtions

The Risk Matrix

A risk factor can be introduced in order to quantify the potential impact of a risk event. The factor is a ranking placed on the risk taken from the combination of

the probability that the risk will happen

the impact the risk would have on the project if it did happen

Risk control

Use Gantt Chart to master whole project and also use spreadsheet to assign the team jobs

use different colours to indicate the project status or risks

R	A	G	C

Dept (IT project)	Owner(S)	W.E. 01/11/04	W.E 08/11/04	Milestone Date
General	Harry L.			14/12/11
Development	Gary S.			19/12/11
Testing	Ronny J			20/12/11

A example of Programme/Project Status

	Previous Period	Current Period
Overall	Red	Amber
Scope	Amber	Amber
Plan	Red	Amber
Quality	Green	Green
Budget	Green	Green
People	Amber	Amber
Customer Satisfaction	Green	Green

Probability and Impact Factors

Probability Factor	Rating		Impact Factor	Rating (people consequences only)
5. Very Likely	A common event, likely to occur 6 or more times a year		5. Major	Possible multiple deaths,
4. Likely	Likely to happen once or twice a year		4. Severe	Possible death, severe multiple injuries
3. Possible	May occur. Has occurred before		3. Significant	Possible significant injuries, multiple minor injuries
2. Unlikely	An improbable event, but has happened		2. Minor	Possible minor injuries
1. Very Unlikely	No known occurrences, but could happen		1. Slight	Possible slight injuries, or no potential risk of injuries

Various definitions can be attached to the probability and impact factors depending on the application
(this was part of a safety case assessing impact on people)

Risk Register

The main output of the risk identification process is a list of identified risks and other information needed to begin creating a risk register

A risk register is:

A document that contains the results of various risk management processes and that is often displayed in a table or spreadsheet format

A tool for documenting potential risk events and related information

Risk events refer to specific, uncertain events that may occur to the detriment or enhancement of the project

Risk Register Contents

1. An identification number for each risk event

2. A rank for each risk event

3. The name of each risk event

4. A description of each risk event

5. The category under which each risk event falls

6. The root cause of each risk

7. Triggers for each risk; triggers are indicators or symptoms of actual risk events

8. Potential responses to each risk

9. The risk owner or person who will own or take responsibility for each risk

10. The probability and impact of each risk occurring

11. The status of each risk

Qualitative Risk Analysis

Assess the likelihood and impact of identified risks to determine their magnitude and priority

Risk quantification tools and techniques include:

Probability/impact matrices

The Top Ten Risk Item Tracking

Expert judgment

Probability/Impact Matrix

A probability/impact matrix or chart:

lists the relative probability of a risk occurring on one side of a matrix or axis on a chart and the relative impact of the risk occurring on the other

List the risks and then label each one as high, medium, or low in terms of its probability of occurrence and its impact if it did occur

A probability/impact matrix or chart:

Can also calculate risk factors

Numbers that represent the overall risk of specific events based on their probability of occurring, and

the consequences to the project if they do occur

Top Ten Risk Item Tracking

Top Ten Risk Item Tracking is a qualitative risk analysis tool that helps to identify risks and maintain an awareness of risks throughout the life of a project

Establish a periodic review of the top ten project risk items

List the current ranking, previous ranking, number of times the risk appears on the list over a period of time, and a summary of progress made in resolving the risk item

Example of Top Ten Risk Item Tracking

Monthly Ranking
Risk Event	Rank This Month	Rank Last Month	Number of Months in Top Ten	Risk Resolution Progress
Inadequate planning	1	2	4	Working on revising the entire project management plan
Poor definition	2	3	3	Holding meetings with project customer and sponsor to clarify scope
Absence of leadership	3	1	2	After previous project manager quit, assigned a new one to lead the project
Poor cost estimates	4	4	3	Revising cost estimates
Poor time estimates	5	5	3	Revising schedule estimates

Risk Response Planning

After identifying and quantifying risks, you must decide how to respond to them

Four main response strategies for negative risks:

Risk avoidance:

Identified risks are avoided through a different course of action

Risk acceptance:

Risks are accepted and contingency strategies are planned

Risk transference:

Transfer of risk to another party through the use of contracts

Risk mitigation:

Steps are taken to reduce the occurrence or impact of stated risks

General Risk Mitigation Strategies for Technical, Cost, and Schedule Risks

Technical Risks	Cost Risks	Schedule Risks
Emphasise team-support and avoid stand-alone project structure	Increase the frequency of project monitoring	Increase the frequency of project monitoring
Increase project manager authority	Use WBS and CPM	Use WBS and CPM
Improve problem handling and communication	Improve communication, project goals understanding, and team support	Select the most experienced project manager
Increase the frequency of project monitoring	Increase project manager authority
Use WBS and CPM

Response Strategies for Positive Risks

Risk exploitation

Risk sharing

Risk enhancement

Risk acceptance

Risk Monitoring and Control

Involves executing the risk management process to respond to risk events

Workarounds are unplanned responses to risk events that must be done when there are no contingency plans

Main outputs of risk monitoring and control are:

Requested changes

Recommended corrective and preventive actions

Updates to the risk register, project management plan, and organisational process assets

Using Software to Assist in Project Risk Management

Risk registers can be created in a simple Word or Excel file or as part of a database

More sophisticated risk management software, such as Monte Carlo simulation tools, help in analyzing project risks

The PMI Risk Specific Interest Group’s Web site at www.risksig.com has a detailed list of software products to assist in risk management

Results of Good Project Risk Management

Unlike crisis management, good project risk management often goes unnoticed

Well-run projects appear to be almost effortless, but a lot of work goes into running a project well

Project managers should strive to make their jobs look easy to reflect the results of well-run projects

Risk Management

ACTIVITY 3.3

Imagine that it is important for you to be able to open your firm’s new office in time to coincide with a visit by the chief executive officer. He will want to see the office ‘working’.

For each of the three risks identified in the table below, suggest one action to reduce or otherwise deal with each risk.

Risk                Potential action

Building work or decorating incomplete

A supplier lets you down and either furniture or equipment is delivered late

Some items of equipment incompatible with remainder

identifying which type of strategy

Risk	Strategy	Type
Supplier goes bankrupt	Identify and approach alternative	Contingence Plan
Supplier does not deliver on time	Insert penalty clause in contract with supplier
	Add extra time to project plan after told to supplier
Specification of components must be		supplier

Strategies to help manage risk

Risk	Strategy
Organisational financial problems	Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business and presenting reasons why cuts to the project budget would not be cost-effective.
Recruitment problems	Alert customer to potential difficulties and the possibility of delays; investigate buying-in components.
Staff illness	Reorganise team so that there is more overlap of work and people therefore understand each other’s jobs.
Defective components	Replace potentially defective components with bought-in components of known reliability.
Requirements changes	Derive traceability information to assess requirements change impact; maximise information hiding in the design
Organisational restructuring	Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business.
Database performance	Investigate the possibility of buying a higher-performance database.
Underestimated development time	Investigate buying-in components; investigate use of a program generator.

Contingency Plan

contingency allowances  Provisions held by the project sponsor or organization to reduce the risk of cost or schedule overruns to an acceptable level; also called contingency reserves

contingency plans  Predefined actions that the project team will take if an identified risk event occurs

contingency reserves  Provisions held by the project sponsor or organization to reduce the risk of cost or schedule overruns to an acceptable level; also called contingency allowances

Controlling Risks

Involves executing the risk management process to respond to risk events and ensuring that risk awareness is an ongoing activity performed by the entire project team throughout the entire project

Workarounds are unplanned responses to risk events that must be done when there are no contingency plans

Main outputs of risk control are:

Work performance information

change requests

updates to the project management plan, other project documents, and organisational process assets

Using Software to Assist in Project Risk Management

Risk registers can be created in a simple Word or Excel file or as part of a database

More sophisticated risk management software, such as Monte Carlo simulation tools, help in analysing project risks

You can purchase add-ons for Excel and Project 2013 to perform simulations

Results of Good Project Risk Management

Unlike crisis management, good project risk management often goes unnoticed

Well-run projects appear to be almost effortless, but a lot of work goes into running a project well

Project managers should strive to make their jobs look easy to reflect the results of well-run projects

Risk Management

Having studied this section you should now be able to:

give a general list of the kinds of risks related to deficient deliverables describe the:

process of risk assessment,

using the WBS,

carry out a simple risk assessment,

listing risks

appropriate strategies for them in an area with which you are familiar

Having studied this section you should now be able to:

describe risk management techniques and

suggest appropriate strategies for defined risks in an area with which you are familiar

describe risk reduction and

suggest risk reduction strategies for defined risks in an area with which you are familiar

explain what is meant by risk avoidance and give a simple example

Having studied this section you should now be able to:

explain how risk transfer can be used to compensate for a hazard

explain where contingency planning fits into risk management

develop a crisis management plan

understand conditions leading to conflict and how to manage conflict

Chapter Summary

Project risk management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives

Main processes include:

Plan risk management

Identify risks

Perform qualitative risk analysis

Perform quantitative risk analysis

Plan risk responses

Control risks

brainstorming  A technique by which a group attempts to generate ideas or find a solution for a specific problem by amassing ideas spontaneously and without judgment

contingency allowances Provisions held by the project sponsor or organization to reduce the risk of cost or schedule overruns to an acceptable level; also called contingency reserves

contingency plans  Predefined actions that the project team will take if an identified risk event occurs

contingency reserves  Provisions held by the project sponsor or organization to reduce the risk of cost or schedule overruns to an acceptable level; also called contingency allowances

Delphi technique  An approach used to derive a consensus among a panel of experts to make predictions about future developments

expected monetary value (EMV) The product of a risk event probability and the risk event’s monetary value

fallback plans  Plans developed for risks that have a high impact on meeting project objectives, and implemented if attempts to reduce the risk are not effective

flowcharts  Diagrams that show how various elements of a system relate to each other

influence diagram  A diagram that represents decision problems by displaying essential elements, including decisions, uncertainties, and objectives, and how they influence each other

interviewing  A fact-finding technique that is normally done face to face, but can also occur through phone calls, e-mail, or instant messaging

known risks  Risks that the project team has identified and analyzed and that can be managed proactively

management reserves  Funds held for unknown risks

probability/impact matrix or chart A matrix or chart that shows the relative probability of a risk occurring and the relative impact of the risk

risk  An uncertainty that can have a negative or positive effect on meeting project objectives

risk acceptance  Accepting the consequences if a risk occurs

risk appetite  The degree of uncertainty an entity is willing to take on in anticipation of a reward

risk-averse  Having a low tolerance for risk

risk avoidance  Eliminating a specific threat or risk, usually by eliminating its causes

risk breakdown structure  A hierarchy of potential risk categories for a project

risk enhancement  Changing the size of an opportunity by identifying and maximizing key drivers of the positive risk

risk events  Specific uncertain events that may occur to the detriment or enhancement of the project

risk exploitation  Doing whatever you can to make sure a positive risk happens

risk factors  Numbers that represent the overall risk of specific events, given their probability of occurring and the consequence to the project if they do occur

risk management plan  A plan that documents the procedures for managing risk throughout a project

risk mitigation  Reducing the impact of a risk event by reducing the probability of its occurrence

risk-neutral  A balance between risk and payoff

risk owner  The person who will take responsibility for a risk and its associated response strategies and tasks

risk register  A document that contains results of various risk management processes, often displayed in a table or spreadsheet format

risk-seeking  Having a high tolerance for risk

risk sharing  Allocating ownership of a risk to another party

risk tolerance  The maximum acceptable deviation an entity is willing to accept on a project or business objectives as the potential impact

risk transference  Shifting the consequence of a risk and responsibility for its management to a third party

Top Ten Risk Item Tracking  A qualitative risk analysis tool for identifying risks and maintaining an awareness of risks throughout the life of a project

triggers  Indications for actual risk events

unknown risks  Risks that cannot be managed proactively because they have not been identified and analysed

watch list  A list of risks that have low priority but are still identified as potential risks

workarounds  Unplanned responses to risk events when no contingency plans are in place