100% found this document useful (1 vote)

2K views

Project Quality & Risk Management-Manual

Project Quality & Risk Management-Manual project management

Uploaded by

Kashif Niazi

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

2K views

Project Quality & Risk Management-Manual

Project Quality & Risk Management-Manual project management

Uploaded by

Kashif Niazi

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 290

Project Quality and Risk Management - Module Handbook- MSPM II

Project Quality and Risk

Management
PRM 702
MSPM Program
Module Handbook

Ghazala Amin
Faculty of Project Management
Department of Management Sciences

Department of Management Sciences, CIIT Islamabad

1 of 7

Project Quality and Risk Management - Module Handbook- MSPM II

Table of Contents

Introduction ....................................................................................................

Objective .......................................................................................................

Contacting the module instructor ..................................................................

Rationale including Aims ..............................................................................

Pre-Requisites ..............................................................................................

Teaching and Learning Outcomes ...............................................................

Teaching Methodology .................................................................................

Assessment Scheme ...................................................................................

Reading Materials ........................................................................................

Course Requirement and Expectations ........................................................

Academic Dishonesty ...................................................................................

Module Contents ..........................................................................................

Department of Management Sciences, CIIT Islamabad

2 of 7

Project Quality and Risk Management - Module Handbook- MSPM II

Introduction
An indispensable component of any advanced postgraduate study program in project management is to
acquaint the course participants with project management as it is being applied by different
organizations in different contexts. Supplementing the project internship, this course module will give
the course participants the valuable opportunity to learn from, and interact with, different project
management practitioners, both Pakistani and foreign, how their organizations apply project
management concepts, and the processes and tools developed to deliver a project which meets/exceeds
the customers expectations.

Objective

To introduce MSPM students to various Project Management Risk and Quality tools and
techniques.

This course would introduce MSPM students with Project Quality and Risk management
concepts.

This is a 3 credit hour course, comprising 3 hours of teaching per week.

Contacting the Module Instructor

You can contact your module instructor in the following ways:
Email:

[email protected]

Cell Phone:

Number XXXXXXXX

Rationale Including Aims

This module will give the program participants an intensive review of Project Quality management and
Project Risk management to manage projects. Topics covered are aimed to provide practical insight into
the field of project management and the use of Risk and Quality management theory and techniques.
This would enhance the understanding of origins and growing popularity of adopting Quality and Risk
techniques to maximize efficiency of managing projects in private and public-sector organizations.

Prerequisites
As this is the second semester course in MS Project Management studies, therefore a thorough
knowledge of Project Management LINGO and concepts are mandatory for studying this course. Work

Department of Management Sciences, CIIT Islamabad

3 of 7

Project Quality and Risk Management - Module Handbook- MSPM II

experience of leading or participation in project implementation and execution can also be beneficial
and/or necessary to gain the maximum benefit from this class.

After studying this course the participants should be able to understand:

Project Quality and Risk Management

This module will give the program participants a detailed insight into managing and delivering a high
quality project. Techniques will be discussed to identify, prioritize and manage diverse project-specific
risks in order to minimize their potentially adverse effects on projects. Emphasis will be placed on
quality assurance and quality control techniques which are being applied in complex projects.
Participants will be introduced to modern quality management processes and will learn the mandatory
components of a quality management plan. Qualitative and quantitative analysis of risk and quality
aspects will be discussed to deliver a high quality, international standards compliant project.

Project Quality and Risk Management:

This course introduces the program participants with a detailed insight into managing and delivering a
high quality project. Techniques will be discussed to identify, prioritize and manage diverse projectspecific risks in order to minimize their potentially adverse effects on projects. Emphasis will be placed
on quality assurance and quality control techniques which are being applied in complex projects.
Participants will be introduced to modern quality management processes and will learn the mandatory
components of a quality management plan. Qualitative and quantitative analysis of risk and quality
aspects will be discussed to deliver a high quality, international standards compliant project.

Project Quality Management Processes, Models, Quality Control Tools and techniques:
Project quality managements terminology and project quality concepts are reviewed. Quality
dimensions between goods and services industry are emphasized. Project Quality Gurus; Demings
cycle (Plan, Do, check, Act); Dr. Jurans quality trilogy (Quality improvement, planning and
control); Dr. Crosbys (Four absolutes of quality) and other definitions are reviewed. Students get an
insight into why Quality is given so much emphasis in todays project management approach. The
importance of good quality management on project is highlighted and international standards like
ISO, CMMI, Six sigma, and PMIs Organizational Project Management Maturity Model (OPM3) are
discussed. Quality Planning; Quality Assurance and Quality Control are defined and their usage
along with the associated inputs and subsequent outputs along with the methods used are discussed.

Project Risk Management Concepts, Analysis, Identification and Mitigation:

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. Risk
management is often overlooked in projects, but it can help improve project success by helping
select good projects, determining project scope, and developing realistic estimates. The objectives of
risk mitigation and planning are to explore risk response strategies for the high-risk items identified
in the qualitative and quantitative risk analysis. Risk Management is one of the nine knowledge areas
recognized for making a comprehensive project management plan. It is important for the project

Department of Management Sciences, CIIT Islamabad

4 of 7

Project Quality and Risk Management - Module Handbook- MSPM II

manager to understand what the risks are and how the project should plan deal with them. The risk
management plan has direct impact on time and cost management.

Teaching Methodology
It is important to me that each of you is successful in this course. The topic as well as the concepts will
be discussed. During the semester, student will learn and be engaged in management theories, their
applications, and attempting of quizzes, participation in assignments, the midterm and final exam. The
assessment and evaluation of the students will be based on the below stated areas.

Individual reading and study, together with lectures.

Ability to understand various case studies.

Assessment Scheme
Quiz #1 after 4 weeks

Assignment#1 after 8 weeks

10%

Mid-term examination after 09 weeks

25%

Quiz#2 after 13 weeks

Terminal Examination after 16 week

50%

Reading Materials

Study Notes and class discussions

A guide to the Project Management Body of Knowledge (PMBOK)

Dr. Harold Kerzners book

o Project Management-A Systems Approach To Planning, Scheduling and Controlling

Course Requirements and Expectations

Grades: Letter grades will be assigned based on the universitys MS standard grading scale.
A+

90%

Department of Management Sciences, CIIT Islamabad

5 of 7

Project Quality and Risk Management - Module Handbook- MSPM II

80-89%

70-79%

60-69%

Being Prepared for Class: Student must review the prior weeks presentation and reference material
before listening to the next lecture. You should understand the concepts by different perspectives.

Academic Dishonesty
Academic dishonesty is an offence that will not be tolerated in any form. Any student who is involved
in any such activity will be penalised to the fullest extent possible allowed by university regulations. If
you have any doubts about whether an action constitutes academic dishonesty, before consult with your
virtual campus administrator before taking the action.

Plagiarism and Cheating: the presentation by a student as his or her own work but is actually stolen
from some one else. Whenever a student submits a piece of writing claiming it to be his own authorship,
it is generally understood that all the ideas, opinions, facts, figures, conclusions, revisions, words are the
students original work, unless he/she has explicitly indicated otherwise using citations, footnotes,
attribution in the text, and/or used quotation marks.

The use of unauthorised material during an examination in order to secure or give help will not be
tolerated. Academic dishonesty also encompasses unauthorised copying and distribution of
examinations, assignments, reports, projects or term papers or the presentation of unacknowledged
material as if it were the students own work. A person failing to acknowledge and recognise the
contribution of the original author will be held responsible under academic deception. Such action will
necessitate measures to discipline the student under the Universitys academic dishonesty policy. Any
academic dishonesty would call for swift punitive action by the faculty and the names of the students
involved would be reported to the concerned administrative incharge.

Department of Management Sciences, CIIT Islamabad

6 of 7

Project Quality and Risk Management - Module Handbook- MSPM II

Module Contents
1-Project Quality Management Overview
2-Project Total Quality Management
3_Project Quality Management Processes
4- Project Quality Management QA & QC Tools
5_Troubled Projects and ways to minimize issues leading to failed projects
6_Project Quality Management (ISO 9000 and the series)
7_Project Quality Management Six Sigma
8_Project leadership and Habits of effective Manager
9- Project Risk Management10_ Project Risk Management- Quantitative and Qualitative Analysis
11-Project Risk Management Identification and Mitigation techniques

Department of Management Sciences, CIIT Islamabad

7 of 7

What Went Wrong?

In 1981, a small timing difference caused by a computer
program caused a launch abort.*
In 1986, two hospital patients died after receiving fatal
doses of radiation from a Therac 25 machine after a
software problem caused the machine to ignore
calibration data.**
Britains Coast Guard was unable to use its computers
for several hours in May 2004 after being hit by the
Sasser virus, which knocked out the electronic mapping
systems, e-mail, and other computer functions, forcing
workers to revert to pen, paper, and radios.***

Lec#2
Project Quality Management
Ghazala Amin

*Design News (February 1988).

**Datamation (May 1987).
***Fleming, Nic, Virus sends coastguard computers off course (http://news.telegraph.co.uk/news/
main.jhtml?xml=/news/2004/05/05/ncoast05.xml) (May 15, 2004).

Why Quality?

Why Quality ?
A good definition of project success is getting the project completed;

Requirements

Within time
Within time and cost
Within time, cost and technical performance requirements
Within time, cost, performance and accepted by the customer/user.

Quality

Schedule

Cost

What is Quality?
The Quality Movement

Quality is:
the totality of characteristics of an entity which
bear on its ability to satisfy stated or implied
needs
-ISO 9000 definition.

Quality is defined by the customer

Quality is linked with profitability
Quality has become a competitive weapon
Quality is now an integral part of strategic
planning process
Quality requires an organization-wide
commitment

Quality is not:

Excellence, Luxury, Prestige, or Grade

Other experts define quality based on:

Conformance to requirements: The projects processes and products meet written specifications.
Fitness for use: A product can be used as it was intended
5

What is Quality?

Difference between Quality and Grade?

Grade is a category or rank given to
entities having the same functional use
but different technical characteristics.

Other experts define quality based on:

Conformance to requirements:
The projects processes and products meet
written specifications.
Fitness for use:
A product can be used as it was intended

Low quality is always a problem; low

grade may not be.
7

Difference between Quality and Grade?

For example:
A software product may be of high quality
(very few defects, a readable users
manual etc.) but of low grade meaning it
has a limited number of features.

Dimensions of Quality for Goods

Or, a software product may be of low

quality but of high grade meaning it has
many defects but lots of customer features.

Operation
Reliability & durability
Conformance
Serviceability
Appearance
Perceived quality

Quality

Importance of Quality

Service Quality Attributes

Reliability

Responsiveness

Costs & market

share
Companys
reputation
Product
liability
International
implications

Competence

Tangibles
Understanding

Access
Courtesy

Security
1995 Corel Corp.

Credibility

Communication
11

Market Gains
Reputation
Volume
Price
Improved
Quality

Increased
Profits
Lower Costs
Productivity
Rework/Scrap
Warranty
12

Defining Quality -ities

Salability: Other Definitions

Salability: the balance between quality and cost

What makes for salability? "Find a need and fill it" is no
longer enough. "Build a need and fill it." It's like the
Internet where you can download free plug-ins and free
browsers to get you ever deeper into the cyberaddiction.
http://www.maxwideman.com/guests/cult/salability.htm

the quality of being salable or marketable

wordnetweb.princeton.edu/perl/webwn
Saleability (also called profitability) is a technical analysis term
used to compare performances of different trading systems or
different investments within one system. Note, it is not simply
another word for profit. ...
en.wikipedia.org/wiki/Salability
The extent to which something can easily be sold
en.wiktionary.org/wiki/salability
salable - capable of being sold; fit for sale; "saleable at a low
price"
wordnetweb.princeton.edu/perl/webwn
salable - Alternative spelling of saleable
en.wiktionary.org/wiki/salable

Defining Quality -ities

Produce ability: the ability to produce the product

with available technology and workers, and at an
acceptable cost

Flexibility: The ability of a product to be used for

different purposes at different capacities and
under different conditions.

Social acceptability: the degree of conflict

between the product or process and the values
of society (i.e., safety, environment)
Operability: the degree to which a product can be
operated safely
15

Availability: the probability that the product, when

used under given conditions, will perform
satisfactorily when called upon

Defining Quality -ities

Reliability: the probability of the product
performing without failure under given conditions
and for a set period of time.
(MTBF-Mean-Time-Between-Failure)

Maintainability: the ability of the product to be

retained in or restored to a performance level
when prescribed maintenance is performed
(MTTR-Mean-Time-To-Repair).
17

Quality Specialist-Job responsibility

Responsibilities

Reports monitoring and measurement of processes and

services of different process areas to Quality Manager and
Information Security Manager of appropriate disposition
Assists in the facilitation of formulation, implementation
and follow-up of corrective and preventive actions (RCA)
related to customer feedback, audits, process and service
monitoring and measurement
Conducts periodic process audits for QMS and ISMS
Prepares and submits reports results of audits to QMS
Lead and Quality Manager
Coordinates with point of contacts of different process
areas regarding documentation of processes for QMS and
ISMS
Reviews and facilitates documentation of processes on a
regular basis
Facilitates review, approval, uploading, disposition of
documents using the organizations document control
system
Guides external auditors during the process of audits
Assists in gathering and processing data, as green belts in
some six sigma projects

Lec#3
Project Quality Management
Ghazala Amin

Requirements

Preferably has experience in any productivity or

quality improvement projects
Preferably has experience being quality assurance,
quality control, or management system audit
Preferably has experience in a service-oriented
organization, specifically in HR BTO
Comprehensive knowledge of ISO 9001 and ISO
27001 requirements
Good knowledge of Companys Quality Policy,
Objectives/Metrics, and clients requirements
Basic knowledge on principles of management
system audit
Basic problem solving tools
Preferably, knowledgeable on Six Sigma
Methodologies
Good Communication Skills (Verbal and written)
Good analytical skills
Excellent presentation skills
Good organization skills
Excellent adaptability skills
Certified Internal Auditor (preferable by IRCA)
Six Sigma Green Belt

http://ph.jobstreet.com/jobs/2008/8/i/20/1941336.htm?fr=J

Project Quality Management

The processes required to ensure that the

project will satisfy the needs for which it was
undertaken.

A company dedicated to quality usually

provides training for all employees.
A company dedicated to quality has strategic
vision of quality.

Modern quality management complements

modern project management in that both
recognize the importance of customer
satisfaction and prevention over inspection.

A company dedicated to quality has long term

vision and mission to stay in the market
place.
3

Why Quality Management ?

Customer satisfaction:

Management responsibility:

Understanding, managing, and influencing needs

so that customer expectations are met.
Requires a combination of conformance to
requirements and fitness for use. (the
product/service must satisfy real needs)

success requires the participation of all

members of the team, but it remains the
responsibility of management to provide the
resources needed to succeed.

Processes within phases:

Prevention over inspection:

the repeated plan-do-check-act cycle

according to Dr. Shewart and Dr. Deming.
(described later)

the cost of preventing mistakes is always much

less than the cost of correcting the mistakes, as
revealed by inspection.
5

When Quality is not Managed ?

Goals of Quality Program

Customer satisfaction

Failure to meet quality requirements effectively and

timely can have serious negative consequences for
the project stakeholders. For example:

the customers feelings about a product or

service

Fitness for use

Meeting customer requirements by overworking the project
team may produce negative consequences in the form of
increased employee attrition.

Is the product or service capable of being used?

Fitness for purpose

Does the product or service meet its intended
purpose?

Meeting project schedule objectives by rushing planned

quality inspections may produce negative consequences
when errors go undetected.
Complete inspection for the products is expensive and time consuming

Conformance to requirements
7

the condition of the product or service in relation

to the customers requirements

ISO 9000
International Organization for Standardization( ISO),
based in Geneva, Switzerland is a consortium of
industrial nations and standards.

Quality Movement

ISO 9000 is not set of standards nor is it specific to

any industry
It is a quality system standard applicable to any
product, service or process in the world.
ISO 9000 is an international standard for quality management systems
9

ISO Standards

ISO 9000 is a quality system standard that:

Is a three-part, continuous cycle of planning, controlling,
and documenting quality in an organization.

ISO 15504, sometimes known as;

SPICE (Software Process Improvement and Capability
dEtermination),

Provides minimum requirements needed for an

organization to meet its quality certification standards.

is a framework for the assessment of software processes.

Helps organizations around the world reduce costs and

improve customer satisfaction.

ISO 9000 series

ISO 9000
Defines key terms and acts as road map for standards within the series
ISO 9001
Defines model for quality system when contractor demonstrates
capability to design, produce and install products.
ISO 9002
Quality system model for quality assurance in production and
installation
ISO 9003
Quality system model for quality assurance in final inspection and
testing
ISO 9004
Quality mgmt. guidelines for organization wishing to develop and
13
implement a quality system.

ISO -Wikipedia
ISO 9000 is a family of standards for quality management systems.
ISO 9000 is maintained by ISO, the International Organization for Standardization
and is administered by accreditation and certification bodies.
The rules are updated, as the requirements motivate changes over time.
Although the standards originated in manufacturing, they are now employed
across several types of organizations. A "product", in ISO vocabulary, can mean a
physical object, services, or software.
Some of the requirements in ISO 9001:2008 (which is one of the standards in the
ISO 9000 family) include;
A company or organization that has been independently audited and certified to
be in conformance with ISO 9001 may publicly state that it is "ISO 9001 certified"
or "ISO 9001 registered". Certification to an ISO 9001 standard does not
guarantee any quality of end products and services; rather, it certifies that
formalized business processes are being applied.
15

ISO Quality Requirements

ISO Requirements are centered around the Plan, Do, Check, Act
methodology.
Plan
Establish the objectives and processes necessary to deliver results in
accordance with customer requirements and the organizations policies.
Do
Implement the processes.
Check
Monitor and measure processes and product against policies, objectives,
and requirements for the product and report the results
Act:
Take actions to continually improve process performance
14

ISO 9000-Wikipedia

Lec#4
ISO-Wikipedia

Ghazala Amin

References
^ "So many standards to follow, so little payoff". Stephanie Clifford. Inc
Magazine, May 2005.
^ a b c "Good Business Sense Is the Key to Confronting ISO 9000" Frank
Barnes in Review of Business, Spring 2000.
^ a b "The 'quality' you can't feel", John Seddon, The Observer, Sunday
November 19, 2000
^ "A Brief History of ISO 9000: Where did we go wrong?". John Seddon.
Chapter one of "The Case Against ISO 9000", 2nd ed., Oak Tree Press.
November 2000. ISBN 1-86076-173-9
^ "Is ISO 9000 really a standard?" Jim Wade, ISO Management Systems
MayJune 2002
^ a b "ISO a GO-Go." Mark Henricks. Entrepreneur Magazine Dec 2001.
^ The ISO Survey 2005 (abridged version, PDF, 3 MB), ISO, 2005
^ Abrahamson, E. (1996). "Managerial fashion." Academy of Management
Review. 21(1):254-285.

ISO 9000-Wikipedia

ISO 9000-Wikipedia
ISO 9000 is a family of standards for quality
management systems.
ISO 9000 is maintained by ISO, the International
Organization for Standardization and is
administered by accreditation and certification
bodies.
The rules are updated, as the requirements
motivate changes over time.
3

Some of the requirements in ISO 9001:2008 (which is

one of the standards in the ISO 9000 family) include;
a set of procedures that cover all key processes in
the business
monitoring processes to ensure they are effective
keeping adequate records
checking output for defects, with appropriate and
corrective action where necessary
regularly reviewing individual processes and the
quality system itself for effectiveness and
Facilitating continual improvement
4

ISO 9000-Wikipedia

A company or organization that has been

independently audited and certified to be in
conformance with ISO 9001
may publicly state that it is "ISO 9001 certified"
or "ISO 9001 registered".
Certification to an ISO 9001 standard does not
guarantee any quality of end products and
services; rather, it certifies that formalized
business processes are being applied.

Although the standards originated in

manufacturing, they are now employed
across several types of organizations.
A "product", in ISO vocabulary, can mean
a physical object, services, or software.
5

ISO 9000-Wikipedia

ISO 9000-Wikipedia-Contents

ISO 9001:2008 Quality

management systems

Few hi-level Content requirements of ISO 9001

Requirements is a document
of approximately 30 pages
which is available from the
national standards
organization in each country.

SCOPE
QUALITY MANAGEMENTS SYSTEM
MANAGEMENT RESPONSIBILITY
QUALITY POLICY
RESPONSIBILITY, AUTHORITY AND COMMMUNICATION
MANAGEMENT REVIEW
RESOURCE MANAGEMENT
INFRASTRUCTURE
WORK ENVIRONMENT
DESIGN AND DEVELOPMENT
PURCHASING
CONTROL MECHANISM
AUDITING

ISO 9001 certification of a fish wholesaler in Tsukiji

ISO 9000-Wikipedia-Certification

ISO does not itself certify organizations.

Many countries have formed accreditation bodies to
authorize certification bodies, which audit
organizations applying for ISO 9001 compliance
certification.
Although commonly referred to as ISO 9000:2000
certification, the actual standard to which an
organization's quality management can be certified is
ISO 9001:2008. Both the accreditation bodies and the
certification bodies charge fees for their services.
The various accreditation bodies have mutual
agreements with each other to ensure that
certificates issued by one of the Accredited
Certification Bodies (CB) are accepted worldwide. 9

The applying organization is assessed based on an

extensive sample of its sites, functions, products,
services and processes; a list of problems ("action
requests" or "non-compliance") is made known to the
management. If there are no major problems on this list,
or after it receives a satisfactory improvement plan from
the management showing how any problems will be
resolved, the certification body will issue an ISO 9001
certificate for each geographical site it has visited.
An ISO certificate is not a once-and-for-all award, but
must be renewed at regular intervals recommended by
the certification body, usually around three years. There
are no grades of competence within ISO 9001: either a
company is certified (meaning that it is committed to
the method and model of quality management
described in the standard), or it is not.
10

ISO 9000-Wikipedia-Advantages

It is widely acknowledged that proper quality management

improves business, often having a positive effect on
investment, market share, sales growth, sales margins,
competitive advantage, and avoidance of litigation.

ISO often gives the following advantages:

The quality principles in ISO 9000:2000 are also sound,

according to Wade and Barnes, who say that "ISO 9000
guidelines provide a comprehensive model for quality
management systems that can make any company
competitive implementing.

Create a more efficient, effective operation

Increase customer satisfaction and retention
Reduce audits
Enhance marketing
Improve employee motivation, awareness, and morale
Promote international trade
Increases profit
Reduce waste and increases productivity.

ISO 9000-Wikipedia-Problems

A common criticism of ISO 9001 is the amount of money, time and

paperwork required for registration.

According to Seddon, ISO 9001 promotes specification, control,

and procedures rather than understanding and improvement.

According to Barnes, "Opponents claim that it is only for

documentation. Proponents believe that if a company has
documented its quality systems, then most of the paperwork has
already been completed.

Wade argues that ISO 9000 is effective as a guideline, but that

promoting it as a standard "helps to mislead companies into
thinking that certification means better quality, ... [undermining] the
need for an organization to set its own quality standards."
Paraphrased, Wade's argument is that reliance on the
specifications of ISO 9001 does not guarantee a successful quality
system.

ISO 9001 is not in any way an indication that products produced

using its certified systems are any good.

While internationally recognized, most US consumers are not

aware of ISO 9000 and it holds no relevance to them. The added
cost to certify and then maintain certification may not be justified if
product end users do not require ISO 9000. The cost can actually
put a company at a competitive disadvantage when competing
against a non ISO 9000 certified company.

A company can intend to produce a poor quality product and

providing it does so consistently and with the proper
documentation can put an ISO 9001 stamp on it.

ISO 9000-Wikipedia-Problems

The standard is seen as especially prone to

failure when a company is interested in
certification before quality.
Certifications are in fact often based on
customer contractual requirements rather than
a desire to actually improve quality.
"If you just want the certificate on the wall,
chances are, you will create a paper system
that doesn't have much to do with the way you
actually run your business," said ISO's Roger
Frost.
15

Certification by an independent auditor is often seen

as the problem area, and according to Barnes, "has
become a vehicle to increase consulting services." In
fact, ISO itself advises that ISO 9001 can be
implemented without certification, simply for the
quality benefits that can be achieved.
Another problem reported is the competition among
the numerous certifying bodies, leading to a softer
approach to the defects noticed in the operation of the
Quality System of a firm.
Abrahamson argued that fashionable management
discourse such as Quality Circles tends to follow a
lifecycle in the form of a bell curve, possibly
indicating a management fad.
16

ISO 9000-Wikipedia
Summary
A good overview for effective use of ISO 9000 is
provided by Barnes:
"Good business judgment is needed to
determine its proper role for a company. Is
certification itself important to the marketing
plans of the company? If not, do not rush to
certification Even without certification,
companies should utilize the ISO 9000 model as
a benchmark to assess the adequacy of its
quality programs."
17

People and Quality Management

Management defines type and amount of work
Management is 85% responsible for quality
The employee can only assume responsibility for meeting
the requirements of completing the work when the
employee:
Know whats expected to meet the specifications
Know how to perform the functions to meet the
specifications
Has adequate tools to perform the function
Is able to measure the performance during the process
Is able to adjust the process to match the desired
outcome

Lec#5
Project Quality Management
Total Quality Management (TQM)
Ghazala Amin

People and Quality Management

Employee Empowerment

Project quality team consists of:

Getting employees involved in product &

process improvements
85% of quality problems are due to process &
material

Techniques

1995 Corel Corp.

Support workers
Let workers make decisions
Build teams & quality circles

Senior Management
Project Manager
Project Staff
Customer
Vendors, suppliers, and contractors
Regulatory Agencies

Project Manager has the ultimate responsibility for Quality

Control and Quality Assurance.
Customer sets the requirement for acceptable quality level.
3

People and Quality Management

Total Quality Management (TQM)

Reviews & Audits

Management reviews determine the status, progress
made, problems, and solutions
Peer reviews determine whether proposed or completed
work meets the requirements
Competency center reviews are used to validate
documentation, studies, and proposed technical solutions
to problems.
Fitness reviews and audits determine the fitness of a
product or part of a project. (addresses specific issues)

Total Quality Management (Department of

Defense)
Quality is key to maintain level of readiness
Quality is vital to our defense, requires a
commitment by all personnel
Quality is a key element of competition

Ways in Which Quality Can Improve

Productivity

Total Quality Management (TQM)

Total Quality Management is;

Sales Gains

an ever improving system for integrating various organizational

elements into design, development and manufacturing efforts,
providing cost-effective products or services that are fully acceptable
to the customer.

Improved response
Higher Prices
Improved reputation

Externally;

Improved
Quality

TQM is customer oriented and provides ,meaningful customer

satisfaction.

Internally;

Increased productivity
Lower rework and scrap costs
Lower warranty costs

TQM reduces production bottlenecks and production costs,

enhancing product quality while improving organizational morale.

Reference/Source: Dr. Kerzners book, Chapter 23

Reduced Costs

Increased
Profits

Flow of Activities Necessary to

Achieve Total Quality Management

Organizational Practices
Leadership
Mission statement
Effective operating procedure
Staff support
Training
Yields: What is important and what is to be
accomplished

Organizational Practices
Quality Principles
Employee Fulfillment
Customer Satisfaction
9

Employment Fulfillment

Quality Principles

Customer focus
Continuous improvement
Employee empowerment
Benchmarking

Empowerment
empowerment requires workers to assume
greater responsibility

It involves comparing actual or planned project practices

to those of other projects (either within the performing
organization or external) to generate ideas for
improvement and to provide a standard by which to
measure performance.

Just-in-time
Tools of TQM
Yields: How to do what is important and to be
accomplished

Organizational commitment
Yields: Employees attitudes that they can
accomplish what is important and to be
accomplished

TQM: A Project Management

approach

Customer Satisfaction

Total Quality management can be defined as:

Winning orders
Repeat customers
Yields: An effective organization with a
competitive advantage

Providing customer with right product at the right time

and right place.
Meeting or exceeding customer requirements and/or
expectations.
Less wastage and rework to satisfy the customers.

TQM: Primary strategies

TQM: Secondary strategies

Primary strategies to achieve Total Quality Management:

Solicit ideas for improvement from employees.
Encourage and develop teams to identify and solve problems.
Encourage team development for performing operations and
service activities resulting in participative leadership.
Benchmark every major activity in the organization to ensure
that it is done in the most efficient and effective way.
Utilize process management techniques to improve customer
service and reduce cycle time.
Develop and train customer staff to be entrepreneurial and
innovative in order to find ways to improve customer service.
Implement improvements so that the organization can qualify as
an ISO 9000 supplier

Secondary strategies to achieve Total Quality Management:

Maintain continuous contact with customers; understand and
anticipate their needs.
Develop loyal customers by not only pleasing them but by
exceeding their expectations.
Work closely with suppliers to improve their product/service
quality and productivity.
Utilize information and communication technology to improve
customer service.
Develop the organization into manageable and focused units in
order to improve performance.
Utilize concurrent or simultaneous engineering.
15

Malcolm Baldridge National Quality

Award (1987)

TQM: Objectives and focus areas

The Malcolm Baldrige National Quality Improvement Act was

established in 1987.
Purpose of the act was to promote quality awareness; to recognize
quality achievements of U.S. companies, and to publicize successful
quality strategies.
Award is presented to companies that achieve world-class
competition through quality management of products and services.

Malcolm Baldridge National Quality

Award (1987)

Baldridge Performance Excellence Award

From: Baldrige Performance Excellence Program [mailto:[email protected]]
Sent: Tuesday, October 05, 2010 1:50 AM
Subject: New Names for a New Era

Malcolm Baldridge Award criterias include;

Leadership
Strategic planning
Customer and market focus
Information and analysis
Human resource development and management
Process management
Business results

We are pleased to announce that, effective today, our name is changing from the Baldrige National Quality Program to the Baldrige
Performance Excellence Program and the Award name is changing to the Malcolm Baldrige Award.
As you know, over the more than 20 years since the inception of the program and the Award, the field of quality has evolved from a
focus on product, service, and customer quality to a broader, strategic focus on overall organizational quality. In line with this concept
of overall organizational excellence (which some people refer to as big Q quality), the Baldrige Criteria have evolved to stay on the
leading edge of validated enterprise management practice and needs. This commitment to evolution is a key reason that the Criteria are
increasingly seen as the standard for organizational performance excellence worldwide. It is also the reason that the Baldrige
Community has embraced performance excellence as the term that best reflects who we are and what we do, as indicated in an
independent branding study in 2007 that supported the changing of the Award and Program names.
With this in mind, the Obama Administration and our Congressional oversight committee made the name changes a part of an overall C
realignment that takes place this month. The public announcement of the realignment takes place today, so we are pleased to announce
the new names to you and other program stakeholders.
In the coming days, weeks, and months, you will see our new names appearing on our Website, in our publications, and in other public
communications.
To learn more about the name change, please visit us at www.nist.gov/baldrige. If you have any questions, feel free to contact us at
[email protected] or 301-975-2036.
Sincerely,
The Outreach and Communications Team
Baldrige Performance Excellence Program

IBM, General Motors, Corning Glass, Xerox, Kodak,

Federal Express, Ritz Carlton etc.
19

Quality Gurus
Lec#6
Project Quality Management
Total Quality Management

Deming, Juran, Crosby

Ghazala Amin

Quality Experts
Deming was famous for his work in rebuilding
Japan and his 14 Points for Management.
Juran wrote the Quality Control Handbook and ten
steps to quality improvement.
Crosby wrote Quality is Free and suggested that
organizations strive for zero defects.
Ishikawa developed the concepts of quality circles
and fishbone diagrams.
Taguchi developed methods for optimizing the
process of engineering experimentation.
Feigenbaum developed the concept of total quality
control.

Demings quality plan for management

Approximately around 1927-1950 timeframe
Poor quality is because, management is preoccupied with
today rather than worrying about future.
85% quality problems require management initiative to
change process, only 15% can be controlled by the workers
on the floor.
Example: poor quality of raw material result in low quality
product due to managements decision to procure low cost
bid. So, improved quality needs change in purchasing policy
and procedures.
Common cause of quality issues;
Low quality raw material, poor design, unsuitable work condition,
equipment cannot meet design tolerances etc.
Deming believed in ceasing mass inspections and ending awards based on price
3

Demings Cycle for Improvement

Immediate remedies
Future Actions

Objectives
Methods

Act
Check

Create constancy of purpose for improvement of product and service.

Adopt the new philosophy.
Cease dependence on inspection to achieve quality.
End the practice of awarding business on the basis of price tag alone. Instead,
minimize total cost by working with a single supplier.
Improve constantly and forever every process for planning, production, and
service.
Institute training on the job.
Adopt and institute leadership.
Drive out fear.
Break down barriers between staff areas.
Eliminate slogans, exhortations, and targets for the work force.
Eliminate numerical quotas for the workforce and numerical goals for
management.
Remove barriers that rob people of workmanship. Eliminate the annual rating or
merit system.
Institute a vigorous program of education and self-improvement for everyone.
6
Put everybody in the company to work to accomplish the transformation.

Plan

6.
7.
8.
9.
10.
11.

Against Objectives
How methods are executed

Demings 14 Points for Management

1.
2.
3.
4.

Train
Execute

12.
5

13.
14.

Dr. Juran's Quality Philosophy

Jurans 10 steps to Quality Improvement

1.
2.
3.

Juran Trilogy (Approximately 1954 in Japan ):

Quality Improvement, Planning & Control

4.
5.
6.
7.
8.
9.
10.

Manufacturer Vs. Customer views:

Adherence to Specs Vs. Fitness for Use

Legal Implications of Quality:

Criminal, Civil, Appropriate Corporate Actions
and Warranties

Build awareness of the need and opportunity for improvement.

Set goals for improvement.
Organize to reach the goals (establish a quality council, identify
problems, select projects, appoint teams, designate facilitators).
Provide training.
Carry out projects to solve problems.
Report progress.
Give recognition.
Communicate results.
Keep score or keep track.
Maintain momentum by making annual improvement part of the
regular systems and processes of the company.

Jurans definition of quality believed in products fitness for use

Crosbys 14 steps to Quality Improvement

Crosbys Four Absolutes of

Quality

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Quality means conformance to requirements

Quality comes from prevention
Quality means that the performance standard
is zero defects
Quality is measured by the cost of nonconformance

12.
13.
14.

Make it clear that management is committed to quality.

Form quality improvement teams with representatives from each department.
Determine where current and potential quality problems lie.
Evaluate the cost of quality and explain its use as a management tool.
Raise the quality awareness and personal concern of all employees.
Take actions to correct problems identified through previous steps.
Establish a committee for the zero-defects program.
Train supervisors to actively carry out their part of the quality improvement program.
Hold a zero-defects day to let all employees realize that there has been a change.
Encourage individuals to establish improvement goals for themselves and their groups.
Encourage employees to communicate to management the obstacles they face in attaining
their improvement goals.
Recognize and appreciate those who participate.
Establish quality councils to communicate on a regular basis.
Do it all over again to emphasize that the quality improvement program never ends.

Crosby believed that zero defects in a product is achievable

Do the Right Thing Right the First

Time (DTRTRTFT)

Concepts of Project Quality

Management

Implies that it is easier and less costly to do

the work right the first time than it is to do it
the second time.
Entails the training of personnel to ensure
sufficient skills and tools to correctly complete
the work.
11

Continuous Improvement Process

(CIP)

Continuous Improvement

A concept which recognizes that the world is constantly

changing and any process that is satisfactory today may well
be unsatisfactory tomorrow.

Represents continual improvement of

process & customer satisfaction
Involves all operations
& work units
Other names

A sustained, gradual change to improve the situation.

Rather than manage the output of the project, the focus is on
managing the total process and sub processes.

Kaizen (Japanese)
Zero-defects
Six sigma

The process is held constant only after it has been proven

capable of the work. Hence, the product naturally meets the
requirements.

1984-1994 T/Maker Co.

Continuous Improvement Process

(CIP)

Zero Defects

CIPs four steps:

Implies that there is no tolerance for errors
within the system.

Define and standardize processes (and sub

processes).

The goal of all processes is to avoid defects

in the product or service.

Assess process performance.

Improve processes.
Measure progress.

Similar to six sigma: almost zero defects

The Customer is the Next Person

in the Process

Quality Circles

The internal organization has a system that ensures

the product or service is transferred to the next
person in the process in a complete and correct
manner.

Group of 6-12 employees from same

work area
Meet regularly to solve work-related
problems
4 hours/month
Facilitator trains & helps
with meetings

The product or service being built is transferred to

another internal party only after it meets all the
specifications and all actions at the current work
station.
Avoids incorrectly assembled components and poor
workmanship.

Resolving Customer Complaints

Best Practices

1995 Corel Corp.

Just-in-Time (JIT)

Make it easy for clients to complain

Respond quickly to complaints
Resolve complaints on the first contact
Use computers to manage complaints
Recruit the best for customer service jobs

Relationship to quality:
JIT cuts cost of quality
JIT improves quality
Better quality means less inventory and better,
easier-to-employ JIT system

Just-In-Time (JIT) Example

Just-in-Time (JIT)
Pull system of production/purchasing
Customer starts production with an order

Involves vendor partnership programs to

improve quality of purchased items
Reduces all inventory levels

Work in process inventory level

(hides problems)

Inventory hides process & material problems

Unreliable
Vendors

Improves process & product quality

Just-In-Time (JIT) Example

Reducing inventory reveals
problems so they can be solved.

Unreliable
Vendors

Scrap

Capacity
Imbalances
23

Scrap

Capacity
Imbalances
22

Project Quality Management

(Slide Repeated)
The processes required to ensure that the
project will satisfy the needs for which it was
undertaken.
Modern quality management complements
modern project management in that both
recognize the importance of customer
satisfaction and prevention over inspection.

Lecture #7
Project Quality Management
Quality Processes
Ghazala Amin

A company dedicated to quality usually provides training for all employees

Quality Leadership

Who is responsible for Quality?

Reference:

Dr. Harold Kerzners PROJECT MANAGEMENT A SYSTEMS APPROACH TO PLANNING, SCHEDULING, AND CONTROLLING
Page 915: QUALITY LEADERSHIP

PMBOK Area: Quality Management

Principles of Quality Management Program at

Sprint

Project Quality Management includes the

processes for ensuring that the project
satisfies the needs and requirements for
which it was undertaken in the first place.

Teamwork
Strategic Integration
Continuous Improvement
Respect for people
Customer Focus
Management by Fact
Structured Problem Solving

Project Quality Management addresses both

the project output (goal-focus) as well as the
management of the project (process-focus).
It recognizes the importance of customer
satisfaction, prevention over inspection,
management responsibility and continuous
improvement.
Processes covered under Project Quality
Management are quality planning, quality
assurance performance, and quality control.

Project Quality Management

Project Quality Management Processes

Project Quality Management Processes (per PMBOK);

Processes include:
Quality planning: Identifying quality requirements and/or
standards relevant to the project and documenting how
the project will demonstrate compliance.
Quality assurance: Periodically auditing overall project
quality control measurements to ensure that appropriate
quality standards are used.
Quality control: Monitoring and recording specific project
quality activities to assess performance and recommend
necessary changes.

Quality Planning
Quality Assurance
Quality Control

Process Groups Initiation

Planning

Execution

Control

Quality
Planning

Quality
Assurance

Quality Control

Closing

Knowledge
Areas
Quality
Management

Project managers are ultimately responsible for quality management on their projects.

Quality Planning

Quality Planning
Quality planning should be performed regularly
and in parallel with other project planning
processes. For example:

Quality planning involves identifying

which quality standards are relevant to
the project and documenting how the
project will demonstrate compliance.

The changes in the project product/service required to

meet identified quality standards may require cost or
schedule adjustments.
The desired product/service quality may require a
detailed risk analysis of an identified risk source.

Quality should be planned in, not inspected in.

Quality Planning

Quality Planning - Inputs

Implies the ability to anticipate situations and

prepare actions to bring about the desired
outcome.

Some mandatory inputs to quality planning

should be;
Quality policy
Project Scope statement
Product description
Standards and regulations
Other process outputs

Important to prevent defects by:

Selecting proper materials.
Training and indoctrinating people in quality.
Planning a process that ensures the appropriate
outcome.

For example, procurement planning may identify

contractor quality requirements.
11

Quality Policy Statements

Quality Policy

Quality Policy is the overall quality intentions and

direction of an organization with regard to quality as
formally expressed by top management. (ISO-8402)
Project management team is responsible for ensuring
that the project stakeholders are fully aware of the
quality policy.
Example
Providing best available health care facility to the patients
at affordable price. Medical facilitys quality policy.

We at HCL are committed to provide

our products and services in
conformance to the Quality &
Environmental Standards satisfying
our clients requirements.
http://www.husnain.com.pk/images/fl
ash/ISO14001.htm

Quality Policy Statements

Quality Planning Methods

Some commonly used tools & techniques
employed for Quality planning are;

WATEEN SOLUTIONS Project Delivery is

committed for delivering projects on time,
within budget, meeting the requirements
and striving for excellence in all
endeavors in achieving total customer
and stakeholder satisfaction".
http://solutions.wateen.com/AboutUs/Poli
cies.aspx

Benefit/cost analysis
Benchmarking
Flowcharting
Design of experiments
Cost of Quality

Quality Planning Methods

Some commonly used tools & techniques
employed for Quality planning are;

Some commonly used tools & techniques employed for

Quality planning are;
Benefit/cost analysis
Must consider benefit/cost tradeoffs during quality planning.
The primary benefit of meeting quality requirements is less
rework which translates to higher productivity, lower costs,
and increased stakeholder satisfaction.
The primary cost of meeting quality requirements is the
expense associated with project quality management
activities.
Understand that the benefits of the quality management
discipline outweigh the costs.

Benchmarking
It involves comparing actual or planned project
practices to those of other projects (either within
the performing organization or external) to
generate ideas for improvement and to provide a
standard by which to measure performance.

Quality Planning Methods

Some commonly used tools & techniques employed

for Quality planning are;

Quality Planning results in ;
Quality management plan
Operational definitions
Checklists
Inputs to other processes

Cost of Quality
Three types of incurred costs:
prevention,
appraisal, and
failure (where failure is)

internal cost
external costs.
25

Quality is never an
accident, it is always the
result of an intelligent
effort

Lecture #8
Project Quality Management
Quality Management Plan
Ghazala Amin

John Ruskin

Quality Management -Wikipedia

Basic Quality Function

The term quality management has a specific meaning

within many business sectors. This specific definition,
which does not aim to assure 'good quality' by the
more general definition, but rather to ensure that an
organization or product is consistent, can be
considered to have four main components: quality
planning, quality control, quality assurance and quality
improvement.[1] Quality management is focused not
only on product/service quality, but also the means to
achieve it. Quality management therefore uses quality
assurance and control of processes as well as
products to achieve more consistent quality.

1. DEFECTS / REJECTS
2.

COMPLAINTS

CONSISTENCY

PRECISION

ACCURACY

VARIATION

Quality Evolution in Japan

Quality Management -Japan

In the 1950s and 1960s, Japanese goods were synonymous
with cheapness and low quality, but over time their quality
initiatives began to be successful, with Japan achieving very
high levels of quality in products from the 1970s onward.
For example, Japanese cars regularly top the J.D. Power
customer satisfaction ratings.
In the 1980s Deming was asked by Ford Motor Company to start
a quality initiative after they realized that they were falling behind
Japanese manufacturers.
A number of highly successful quality initiatives have been
invented by the Japanese (for example : Genichi Taguchi, QFD,
Toyota Production System. Many of the methods not only
provide techniques but also have associated quality culture (i.e.
people factors). These methods are now adopted by the same
western countries that decades earlier derided Japanese
methods.

Determining the customers

needs before the customer
becomes aware of them

Fitness to Latent
Requirements

Fitness to
Cost
To build a product that
meets the needs of
customer.

Fitness to
Use

Obtain high quality & low cost by

effective designing of both the
product & processes.

Fitness to
Standards
To build a product that meets the
specifications set by the designer.

Courtesy Ali Sajid : Quality in Project Management

Quality Management Cycle

http://perspectives.avalution.com/2009/what-is-management-system/

Quality Management Cycle

Quality Management
All activities of the overall management
function that determine the quality
policy, objectives and responsibilities
and implement planning, quality control,
quality
assurance
and
quality
improvement within the quality system
(ISO 840)

http://www.mamk.fi/instancedata/prime_product_julkaisu/mamk/embeds/mamkwwwstructure/eb245bc19a2177d0e943c128d91b7e2607c60110.jpg

Quality Management Plan

Quality Management Plan document sets out the specific

quality practices, resources and sequence of activities
relevant to a particular product, service, contract or
project. (ISO-8402)

In ISO 9000 terminology, it should describe the project

quality system: the organizational structure, responsibilities,
procedures, processes, and resources needed to implement
quality management.

The Quality Management Plan is an integral part of any

project management plan. The purpose of the Quality
Management Plan is to describe how quality will be
managed throughout the lifecycle of the project. It also
includes the processes and procedures for ensuring quality
planning, assurance, and control are all conducted. All
stakeholders should be familiar with how quality will be
planned, assured, and controlled.

Provides input to the overall project plan and must address

quality control, quality assurance, and quality improvement
for the project.
May be formal or informal, highly detailed or broadly framed,
depending on the requirements of the project.

Quality Management Plan

Quality Management Plan -Template

Achieving quality takes planning and hard work, but once

achieved it's something you can be proud of and others will
appreciate.

TABLE OF CONTENTS

Following Quality Management Plan Document will get you

off on the right track.
Project Managers, Sponsors, customers and stakeholders
will praise you if your projects deliver quality products.
By starting out with a plan to manage quality, and the
fortitude to practice good quality management throughout
the project, delivering exceptional quality will come naturally.
13

INTRODUCTION
QUALITY MANAGEMENT APPROACH
QUALITY REQUIREMENTS / STANDARDS
QUALITY ASSURANCE
QUALITY CONTROL
QUALITY CONTROL MEASUREMENTS

http://www.projectmanagementdocs.com/project-planning-templates/quality-management-plan.html 14

Focusing on customers is not just

a quality issue in any project;
it is sound business practice.
Customer Satisfaction translates
directly into increased profits.

Lecture #9
Project Quality Management
Quality ProcessesQuality Assurance and Quality Control
Ghazala Amin

WHY IS IT IMPORTANT TO MEET

CUSTOMER EXPECTATIONS?

Quality Assurance

Needs of customers have to be met

Understanding of ones customers leads to
customer satisfaction
Japanese relate quality to customer satisfaction

Inadequate internal facilities

Poorly designed processes

The process of evaluating overall

project performance on a regular
basis to provide confidence that the
project will satisfy the relevant
quality standards.

Poor
Quality
Project
3

Quality Control

QUALITY ASSURANCE

Quality Control is the process of monitoring

specific project results to determine if they comply
with relevant quality standards

THERE ARE NO FACTS ONLY INTERPRETATIONS

-FRIEDRICH NIETZSCHE

Any action directed towards providing

consumers with products (goods & services) of
appropriate quality

The organizational unit that is assigned

responsibility for quality control.

Quality Assurance

Quality Assurance vs Quality Control

The organizational unit Quality Assurance team that is

assigned the responsibility for assuring quality.
Internal quality assurance:
assurance is provided to the project management
team and to the management team of the performing
organization.
External quality assurance:
assurance is provided to the customer and others not
actively involved in the work of the project.
Reference:

Dr. Harold Kerzners PROJECT MANAGEMENT A SYSTEMS APPROACH TO PLANNING, SCHEDULING, AND CONTROLLING
Page 988 and 989: QUALITY ASSURANCE AND QUALITY CONTROL

Quality Assurance

Quality Assurance - Inputs

Quality assurance is the planned and systematic

activities implemented within the quality system to
provide confidence that the project will satisfy
relevant quality standards

Some mandatory inputs to quality assurance

should be;
Quality management plan
Quality management plan should be used as a road
map to guide the QA team with enforcing processes
and procedures.

Project Manager can have greatest impact on the

quality of his project by establishing process and
procedures to assure that scope statement
conforms to the actual requirement of the customer.

Results of quality control measurements

records of quality control testing and measurement in
a format for comparison and analysis.
9

Quality Audit

The method most commonly employed for enforcing the

Quality Assurance process is;

The objective of a quality audit is to identify

lessons learned that can improve performance of
this project or of other projects within the
performing organization.

Quality audits
A structured review of all quality management
activities.

May be scheduled or random; may be carried out

by trained in-house auditors or by third parties
such as quality system registration agencies.

Table 8-1. Table of Contents for a

Quality Assurance Plan*

Quality Assurance - Output

Quality Assurance Audits results in;

1.0 Draft Quality Assurance Plan

1.1 Introduction
1.2 Purpose
1.3 Policy Statement
1.4 Scope
2.0 Management
2.1 Organizational Structure
2.2 Roles and Responsibilities
2.2.1 Technical Monitor/Senior
Management
2.2.2 Task Leader
2.2.3 Quality Assurance Team
2.2.4 Technical Staff
3.0 Required Documentation

Quality improvement
Includes taking action to increase the effectiveness
and efficiency of the project to provide added benefits
to the project stakeholders.
In most cases will require preparation of change
requests or taking corrective action and will be
handled according to the procedures for integrated
change control.

4.0 Quality Assurance Procedures

4.1 Walkthrough Procedure
4.2 Review Process
4.2.1 Review Procedures
4.3 Audit Process
4.3.1 Audit Procedures
4.4 Evaluation Process
4.5 Process Improvement
5.0 Problem Reporting Procedures
5.1 Noncompliance Reporting Procedures
6.0 Quality Assurance Metrics
Appendix
Quality Assurance Checklist Forms

*U.S. Department of Energy

Quality Control

Quality Control is the process of monitoring

specific project results to determine if they comply
with relevant quality standards

Technique to Control &

Check Quality

The organizational unit that is assigned

responsibility for quality control.

Quality Control

Quality control involves monitoring specific project

results to determine if they comply with relevant
standards and identifying ways to eliminate causes of
unsatisfactory results

Some Inputs to the Quality Control Process

are;

Project Team members with specific technical expertise

setup process and procedures to ensure each step of
project provides quality output from design and
development through implementation and maintenance.

Work results
Quality management plan
Operational definitions
Checklists

Quality Control

Quality Control
Inspection:

Some Tools & Techniques used are;

Includes activities such as measuring, examining,

and testing undertaken to determine whether
results conform to requirements.
May be conducted at any level (e.g., the results
of a single activity may be inspected or the final
project product).
May be called reviews, product reviews,
audits, and walkthroughs.

Inspection
Control charts
Pareto diagram
Statistical sampling
Flowcharting
Trend analysis

Quality Control - Outputs

Results in;

What is Rework?

Quality improvement
Acceptance decisions

Rework
Action taken to bring a defective or nonconforming
item into
compliance with requirements or specifications.
Rework, especially
unanticipated, is a frequent cause of project overruns
in most application areas.
The project team should make every reasonable effort
to minimize rework.

Decisions to either accept or reject the inspected

items.
Rejected items may require rework.

Rework

Quality Control Outputs

Scope Verification vs Quality

Control
Scope Verification

Process adjustments

Scope verification is primarily concerned with the

acceptance of work results

Immediate corrective or preventive action

as a result of
quality control measurements. In some
cases, the process adjustment may
need to be handled according to
procedures for integrated change control.

Quality control
Quality Control is primarily concerned with the
correctness of work results.

The Seven QC Tools

Identification

Analysis

Project Quality Management

Cause
and
Effect
Analysis

Data
Tables

QA and QC Tools & Techniques

Pareto
Analysis

Lec#10

Histograms
Scatter
Diagrams

Trend
Analysis

Control
Charts

Ghazala Amin
1

Data Table

Tools of TQM
Tools for generating ideas

Defects

Check sheet/Data Table

Scatter diagram
Cause and effect diagram

Tools to organize data

Pareto charts
Process charts (Flow diagrams)

Tools for identifying problems

Proces Proces
sA
sB

Proces Proces
sC
sD

Total

Incorrect Invoice

Incorrect Inventory

Damaged Material

Incorrect Test doc.

Total

Histograms
Statistical process control chart
3

Cause and Effect - Fishbone

Chart
Cause

Time

Machine Method

Sample Fishbone or Ishikawa Diagram

Effect
Material
Major
Defect

Energy

Measure

People

Environ.

Identify major and minor causes for the defect

Classify in related groups
Visualize the group with the most causes

Pareto Analysis - Definition

Scatter Diagram
Y

X
Plot the results of two variables. Used to determine the
relationship between two or more pieces of corresponding
data. The data are plotted on an X-Y chart to determine correlation
Show distribution around Central tendency
Highlight Exceptions (out of tolerance condition)
Source of data for the Pareto Chart
7

Pareto Diagram - A histogram ordered by

frequency of occurrence that shows how
many results were generated by each
identified cause.
Pareto Law - A supposition that states that a
relatively small number of causes will
typically produce a large majority of the
problems or defects.
Commonly referred to as the 80/20 principle
in which 80% of the problems can be
attributed to 20% of the causes.

Pareto Analysis

Pareto Diagram

Pareto analysis involves identifying the vital

few contributors that account for the most
quality problems in a system.

Primary Purpose:
Focus improvement efforts on the most important causes
15
10

Also called the 80-20 rule, meaning that 80

percent of problems are often due to 20
percent of the causes.

5
0
Noise

Pareto diagrams are histograms, or column

charts representing a frequency distribution,
that help identify and prioritize problem areas.

Wobble

Pressure

Other

Pareto's rule:
A large number of defects are the result of a small number of causes. Fix the problems
that are causing the greatest number of defects first. Does not account for severity

of the defects
9

Acceptance Sampling

Sample Pareto Diagram

Used when expensive and time-consuming to test 100%.

Random sampling may be used to check the characteristics and attributes of a
given lot of goods.
Determines whether or not the lot conforms to the specifications or standards
necessary to support the overall project requirements.
Inspection and test standards must be established to ensure that procedures are
adequate to determine whether a lot is conforming or nonconforming to
specifications.
Important to select a sample size that will provide sufficient information about the
larger lot of goods without costing a great deal of money.
Must determine in advance the number of allowable defects before the lot is
rejected.
11

Ranks defects in order of frequency of occurrence to depict 100% of the defects.

Statistical Sampling
Statistical sampling involves choosing part of a
population of interest for inspection.

Statistical Sampling
Prevention
Keep Errors out of production
Keep defects from reaching customers

The size of a sample depends on how

representative you want the sample to be.
Be sure to consult with an expert when using
statistical analysis.
Example: QA team randomly selected 8 drawings from
80 engineering drawings generated during the planning
and design phase for inspection. This exercise of

Attribute Sampling
Conformance or non-conformance

random selection is Statistical sampling.

Statistical Sampling

Quality Control Charts

Control Charts - A graphic display of the
results, over time and against established
control limits, of a process.
The charts are used to determine if the
process is in control or in need of
adjustment.

Common Vs. Special Causes

Common -- Normal process variation
Special -- Unusual events
Tolerances
Acceptance range (product is acceptable or not)
Control limits (process is in or out of control)

Quality Control Charts

Control Chart

A control chart is a graphic display of data that

illustrates the results of a process over time.
The main use of control charts is to prevent defects,
rather than to detect or reject them.
Quality control charts allow you to determine whether a
process is in control or out of control.
When a process is in control, any variations in the results of the
process are created by random events; processes that are in
control do not need to be adjusted.
When a process is out of control, variations in the results of the
process are caused by non-random events; you need to
identify the causes of those non-random events and adjust the
17
process to correct or eliminate them.

Number of defects - Process A

Upper Specification Limit
Upper Control Limit
Mean
Lower Control Limit
Lower Specification Limit

10
8
6
4
2
0
-2
-4
-6
-8
-10

Time
Process results over time
Process is in control when the number of defects fall within
upper and lower control limits.
Process adjustments are immediate corrective actions based on
QC measure.
Process can be improved to meet tighter control limits:
Processes in control should not be adjusted.
18

Sample Quality Control Chart

Quality Control Charts and the Seven Run Rule

The seven run rule states that if seven data points
in a row are all below the mean, above the mean,
or are all increasing or decreasing, then the
process needs to be examined for non-random
problems.
You can use quality control charts and the seven
run rule to look for patterns in data.
A control chart helps prevent defects and allows you to determine whether a process is in control or out
of control
19

Out of Control States

Visual patterns indicating out-of-control state or a condition that requires

attention:

Visual patterns indicating out-of-control state or a condition that requires

attention:

Outliers: a sample point outside the control limits (also referred to as

out-of-control)

Trend: A series of consecutive points which reflect a steadily increasing

or decreasing pattern.
Rule of Thumb: Considered abnormal when seven or more
consecutive data points reflect a steadily increasing or decreasing
pattern.

Hugging control limit: a series (run) of points that are close to a control
limit. Requires correction to prevent data points from going outside the
control limit.
Rule of Thumb: Considered abnormal if two of three, three of seven,
or four of ten data points fall within the outer one-third of the chart.

Run: A series of 7 or more consecutive points (observations) fall on the

same side of the average (mean)
Rule of Thumb: Considered abnormal if seven consecutive points,
ten of eleven, or twelve of fourteen data points are above or below
the process average.

Cycle: A repeating pattern of points.

Testing Tasks in the Software Development Life Cycle

Quality Testing in IT World

Many IT professionals think of testing as a stage
that comes near the end of IT product
development.
Testing should be done during almost every
phase of the IT product development life cycle.

Figure. Gantt Chart for Building Testing into a

Systems Development Project Plan

Types of Tests
Unit testing tests each individual component (often a
program) to ensure it is as defect-free as possible.
Integration testing occurs between unit and system
testing to test functionally grouped components.
System testing tests the entire system as one entity.
User acceptance testing is an independent test
performed by end users prior to accepting the
delivered system.
25

Testing Alone Is Not Enough

Watts S. Humphrey, a renowned expert on software quality,
defines a software defect as anything that must be changed
before delivery of the program.
Testing does not sufficiently prevent software defects because:
The number of ways to test a complex system is huge.
Users will continue to invent new ways to use a system that its developers
never considered.

Humphrey suggests that people rethink the software development

process to provide no potential defects when you enter system
testing; developers must be responsible for providing error-free
code at each stage of testing.
27

MPM Internal
QUALITY ASSURANCE
DOCUMENT

Methodical Process Management

Prepared (also subject responsible if other)

No.

Muhammad Sajjad Tanoli

Approved

1 (8)

MPM/Doc-12Error! Unknown
Date
Rev
Reference
document property
name.
A

Checked

Mrs. Ghazala Amin

1
Quality Assurance Plan Template
Items that are intended to stay in as part of your document are in bold;
explanatory comments are in Italic text, describing the intent of each section.

Quality Assurance Plan

for
<Name of Project>
<Author>
<Date>
<Data security notice>
<Instructions to reviewers, if appropriate>
[Note this is a sample list of approvers intended to illustrate the format of this
section.]
Signature

Organizational responsibility

Date

Methodical Process Management

Prepared (also subject responsible if other)

Mrs. Ghazala Amin

2 (8)

No.

Muhammad Sajjad Tanoli

Approved

MPM Internal
QUALITY ASSURANCE
DOCUMENT

Checked

MPM/Doc-12Error! Unknown
Date
Rev
Reference
document property
name.
A

Table of Contents
1 INTRODUCTION.. 3
2 REFERENCE DOCUMENTS............................................................................................ 3
3 MANAGEMENT..ORGANIZATION.....................................................

3.1 ORGANIZATION................................................................................................................. 3
3.2 ROLES AND RESPONSIBILITIES............................................................................................ 3
4 STANDARDS TO BE USED............................................................................................. 4
4.1 PRODUCT STANDARDS...................................................................................................... 4
4.2 PROCESS STANDARDS....................................................................................................... 4
5 COACHING AND MENTORING ACTIVITIES .................................................................. 4
6 REVIEWS AND AUDITS....................................................................................................5
6.1 W ORK PRODUCT REVIEWS.................................................................................................5
6.2 PROCESS REVIEWS ...........................................................................................................5
6.3 QUALITY ASSURANCE PROGRESS REVIEWS ....................................................................... .6
6.4 QUALITY ASSURANCE LESSONS LEARNED REVIEW...............................................................6
6.5 INDEPENDENT REVIEW OF QUALITY ASSURANCE..................................................................6
6.6 SCHEDULE OF QUALITY ASSURANCE ACTIVITIES..................................................................6
7 FEEDBACK AND REPORTS .............................................................................................6
8 PROBLEM REPORTING AND CORRECTIVE ACTION ....................................................7
9 TOOLS, TECHNIQUES, AND METHODS...........................................................................7
10 QUALITY ASSURANCE MEASURES...............................................................................7
11 SUPPLIER CONTROL.......................................................................................................8
12 RECORDS COLLECTION, MAINTENANCE AND RETENTION.......................................8
13 TRAINING...........................................................................................................................8
14 RISK MANAGEMENT.........................................................................................................8

MPM Internal
QUALITY ASSURANCE
DOCUMENT

Methodical Process Management

Prepared (also subject responsible if other)

No.

Muhammad Sajjad Tanoli

Approved

3 (8)

MPM/Doc-12Error! Unknown
Date
Rev
Reference
document property
name.
A

Checked

Mrs. Ghazala Amin

1. INTRODUCTION
Describe the scope of this Quality Assurance Plan, identifying which project(s),
Product, and/or the portion of the project life cycle are covered by the plan.
Describe the quality objectives for this project, with any measures being used to
quantify the objectives.

2. REFERENCE DOCUMENTS
Provide a complete list of documents that provided input to this plan or that must
be read to understand this plan.

3 MANAGEMENT ORGANIZATION
Describe the organization, tasks, and responsibilities of the people who will
contribute to the quality assurance efforts for this project. Also describe the
organization of the project overall, or provide a reference to where that
information can be found.
3.1 ORGANIZATION
Depict the organizational structure for the group that performs the quality
assurance function for this project. Show how the quality assurance staff relates
to the project development staff, and discuss the level of independence of the
quality assurance staff from those responsible for development.
3.2 ROLES AND RESPONSIBILITIES
Describe the primary roles and responsibilities of the quality assurance staff.
Indicate activities such as mentoring or coaching the project, auditing work
products, auditing processes, participating in project reviews, etc. Often a table of
roles and responsibilities is a useful way to depict the information; extend as
needed.
Name

Role

Responsibilities

Methodical Process Management

Prepared (also subject responsible if other)

4 (8)

No.

Muhammad Sajjad Tanoli

Approved

MPM Internal
QUALITY ASSURANCE
DOCUMENT

Checked

Mrs. Ghazala Amin

MPM/Doc-12Error! Unknown
Date
Rev
Reference
document property
name.
A

4 STANDARDS TO BE USED
4.1 PRODUCT STANDARDS
Identify any product standards that must be followed by the project, as well as
any other product conventions and measures that will be applied. Describe how
compliance with these items is to be monitored and assured.
4.2 PROCESS STANDARDS
Identify process standards to be followed by the project, as well as any other
process related conventions and measures that will be applied. Describe how
compliance with these items is to be monitored and assured. Include the basic
design, development, testing, and deployment considerations, including
standards such as the following:
a) Documentation standards
b) Enterprise, process, technical, and or data rchitecture standards
c) Coding and naming standards
d) Testing standards and practices
e) Organization or project product and process measures

5 COACHING AND MENTORING ACTIVITIES

Describe how the quality assurance staff will engage with the project manager
and/or the project team to provide process-related mentoring or coaching.

Methodical Process Management

Prepared (also subject responsible if other)

Mrs. Ghazala Amin

5 (8)

No.

Muhammad Sajjad Tanoli

Approved

MPM Internal
QUALITY ASSURANCE
DOCUMENT

Checked

MPM/Doc-12Error! Unknown
Date
Rev
Reference
document property
name.
A

6 REVIEWS AND AUDITS

6.1 WORK PRODUCT REVIEWS
Identify which work products are to be reviewed by quality assurance staff, when
they will be reviewed (that is, what criteria indicate readiness for a review by
quality assurance), and using what checklists or other standards. Consider the
following work products as candidates for review: requirements specifications,
design documentation, code, test plans, test results, project plan, configuration
management plan, user documentation, release and installation documentation.
A table may be a useful way to convey this information; extend the example
below as needed. [Note: work products and project processes may be reviewed
and/or audited together. If so, indicate that approach in this section.]
Work Product

When Reviewed by
Quality Assurance
(Status or Criteria)

How Reviewed by
Quality Assurance
(Standards or Method)

6.2 PROCESS REVIEWS

Describe which project processes are to be reviewed and how they will be
reviewed; include both development and testing processes. Indicate when the
quality assurance review should occur, in terms of the status of the project or
other criteria, if appropriate. In some cases, processes are selected at random
intervals for review, or they may be examined as part of the organizations
ongoing process compliance or process improvement effort. A table may be a
useful way to convey this information; extend the example below as needed.
Process to Review

When Reviewed by
Quality Assurance
(Status or Criteria)

How Reviewed by
Quality Assurance

Methodical Process Management

Prepared (also subject responsible if other)

6 (8)

No.

Muhammad Sajjad Tanoli

Approved

MPM Internal
QUALITY ASSURANCE
DOCUMENT

Checked

Mrs. Ghazala Amin

MPM/Doc-12Error! Unknown
Date
Rev
Reference
document property
name.
A

6.3 QUALITY ASSURANCE PROGRESS REVIEWS

Describe the reviews of the quality assurance efforts that are to be held
periodically to monitor the execution of this plan. These reviews may be part of
the project review cycle or they may be separately done by the quality assurance
group.
6.4 QUALITY ASSURANCE LESSONS LEARNED REVIEW
Describe how and when lessons learned about quality assurance will be
gathered. This may be done as part of the projects lessons learned activities,
and/or there may be separate gathering by the quality assurance group.
6.5 INDEPENDENT REVIEW OF QUALITY ASSURANCE
If appropriate, describe how independent review will be done for the quality
assurance activities. In general, this is specified in the operating plan for the
quality assurance group. For a large project, though, it may be necessary to have
independent review of the quality assurance function.
6.6 SCHEDULE OF QUALITY ASSURANCE ACTIVITIES
Provide a schedule of the quality assurance activities for this project, or indicate
where that schedule can be found external to this document. It may be included
as part of the overall project schedule or it may be maintained separately.

7 FEEDBACK AND REPORTS

Describe the records and/or reports that quality assurance staff will produce.
Identify
The method and frequency of providing feedback to the project team and other
related groups on quality assurance activities
The quality records that will be maintained on the reviews and audits for the
Project
A table may be a useful way to organize this information; extend or modify as
needed.

Methodical Process Management

Prepared (also subject responsible if other)

7 (8)

No.

Muhammad Sajjad Tanoli

Approved

MPM Internal
QUALITY ASSURANCE
DOCUMENT

Checked

Mrs. Ghazala Amin

MPM/Doc-12Error! Unknown
Date
Rev
Reference
document property
name.
A

Reports and Quality

Provided to

Provided

Records

Whom

When

How

8 PROBLEM REPORTING AND CORRECTIVE ACTION

Describe, or reference, the procedures or activities used to report, track
and resolve problems and defects identified in the project work products
and in the project processes. Identify the specific organizations or
individuals responsible for their implementation. Identify the criteria and
process for escalating unresolved issues. Describe the process to be used
to detect and eliminate potential causes of problems or defects. This
section typically specifies that:
Deviations from the project plan and the designated standards and
procedures are documented and resolved with the appropriate project task
leaders, line managers, and project manager, where possible.
Deviations from the project plan and the designated project standards
and procedures not resolvable with the project team, line managers, or
project manager are documented and presented to the senior manager
designated to receive noncompliance issues.
Noncompliance items presented to the senior manager are periodically
reviewed until they are resolved.
The documentation of noncompliance items is managed and controlled.

9 TOOLS, TECHNIQUES, AND METHODS

Identify the special software tools, techniques, and methods employed to support
quality assurance, state their purposes, and describe their use.

10 QUALITY ASSURANCE MEASURES

Define the quality assurance measures that are to be collected during the project
and describe how they will be used. Examples of such measures include:

Methodical Process Management

Prepared (also subject responsible if other)

Mrs. Ghazala Amin

8 (8)

No.

Muhammad Sajjad Tanoli

Approved

MPM Internal
QUALITY ASSURANCE
DOCUMENT

Checked

MPM/Doc-12Error! Unknown
Date
Rev
Reference
document property
name.
A

Measures of completion of milestones related to the quality assurance plan

Quality assurance effort expended compared to plan
Number of product audits and activity reviews compared to the plan
Number of deviations noted by quality assurance reviews and audits

11 SUPPLIER CONTROL
Describe the approach for monitoring the quality assurance activities of any
supplier who is providing software components for the project. At a minimum the
supplier should prepare and implement a Quality Assurance Plan in accordance
with this template.

12 RECORDS COLLECTION, MAINTENANCE AND RETENTION

Identify the quality assurance documentation and quality records to be retained;
the methods and facilities to be used to assemble, safeguard and maintain this
documentation; and designate the retention period.

13 TRAINING
Identify the training activities necessary to ensure that the quality assurance staff
meet the needs of this plan.

14 RISK MANAGEMENT
Describe how risks to the quality assurance will be identified, prioritized, and
managed during the execution of this plan.

CRITICAL QUALITY
ISSUES IN
PAKISTAN

Project Quality Management

Assignment
Lec#11
Ghazala Amin
1

Quality Management Assignment

Education in Pakistan: The Key Issues, Problems and The New Challenges
Ghulam Rasool Memon,
Department of Education, University of Karachi

Select any one of the following case studies.

Create Quality Assurance Plan document.
List key issues and suggestions for improvement in
quality.
Draw a cause and effect diagram.
Come up with a quality policy statement for the
company dealing with issues in your selected case
study.

The Education Sector in Pakistan suffers from insufficient financial input, low
levels of efficiency for implementation of programs, and poor quality of
management, monitoring, supervision and teaching. As a result, Pakistan has
one of the lowest rates of literacy in the world, and the lowest among
countries of comparative resources and social/economic situations.
With a per capita income of over $450 Pakistan has an adult literacy rate of
49%, while both Vietnam and India with less per capita income have literacy
rates of 94% and 52%, respectively (Human Development Centre, 1998).
An educational system of poor quality may be one of the most important
reasons why poor countries do not grow.

CITRUS EXPORT SYSTEM IN PAKISTAN

M. Athar Mahmood (Scientific Officer), and A. D. Sheikh (Director,
Technology Transfer Institute (PARC), Ayub Agricultural Research Institute, Faisalabad, Pakistan

Lack of storage facilities:

Very few factories have their own storage facility and their capacity is very limited.
Generally, exporters and traders store their consignments in traditional cold stores
available near fruit markets. When there is glut in the market, Kinnows are even
thrown on the roads which indicate the fact of poor storage facilities. The other
problems related to cold storage facilities are high rent and poor quality of storage.
Non-availability of quality packing:
Packing material available is of low quality with high prices. The cardboard boxes
cannot sustain the pressure of weight in the containers, so the packing gets loose
affecting the fruit quality. Poor quality packing fetches low price in international
market.

Effects of Poor Quality of Ground Water on Carrot Production: A Comparative Study,

KHUDA BAKHSH, MUHAMMAD ASHFAQ AND MUHAMMAD WAQAS ALAM
Department of Environmental and Resource Economics, and Agricultural Economics, Faculty of Agricultural
Economics and Rural Sociology, University of Agriculture, Faisalabad38040, Pakistan

Poor Carrot Production in Toba Tek Singh Cross-sectional data were used to determine the effects of ground water on carrot
production. Results of production function analysis indicated that poor quality of
ground water in Toba Tek Singh was significantly decreasing the carrot production.
The consistent use of poor quality water not only deteriorates chemical and physical
properties of soil (World Bank, 1994) but also results in loss of agriculture production
of the order of 14000 million rupees per annum (Pato, 1998)
The result indicates that one percent increase in application of poor quality of the
ground water could further decline carrot yield by 0.153%. Carrot crop is sensitive to
poor quality of the ground water and application of this type of water results in
substantial losses in carrot production.

Cause and Effect - Fishbone

Chart

The Seven QC Tools

Identification

Cause

Analysis
Time

Data
Tables
Pareto
Analysis

Cause
and
Effect
Analysis
Trend
Analysis

Machine Method

Effect
Material
Major
Defect

Histograms

Energy

Scatter
Diagrams

Measure

People

Environ.

Identify major and minor causes for the defect

Classify in related groups
Visualize the group with the most causes

Control
Charts

Quality Assurance (QA) Document

Sample Fishbone or Ishikawa Diagram

Doing a good job of quality assurance can have

the greatest impact on the quality of the project.
Quality Assurance Document is a very
comprehensive document.

OVERVIEW OF QA PLAN

OVERVIEW OF QA PLAN
1.
2.
3.
4.
5.
6.
7.
8.

10. Tools Techniques & Methods

11. Supplier Control
12. Records Collection , Maintenance & Retention
13. Training
14. Risk Management

Introduction
Reference Documents
Management Organization
Standards to be Used
Coaching & Mentoring Activities
Reviews & Audits
Feed Back & Reports
Problems Reporting & Corrective Actions
11

Quality Processes

Project Quality Management

Lec#12
Project Quality Processes

Process is a logical organization of people,

material, equipment and procedures into work
activities designed to produce a specified end
result.

Ghazala Amin

From Pall, Gabriel A. Quality Process

Management
1

Quality Nodes

Quality Processes
The quality of a system is highly influenced by the quality
of the process used to acquire, develop and maintain it.

Requirements

This statement focuses on processes as well as the

product.
Established strongly in manufacturing industries.
Quality movement visible in not only manufacturing but
now common in service industries e.g. ISO standards,
CMMI etc.
It is now widely implemented and enforced in IT
development.
3

People

Quality

Quality
Schedule

Cost

Process

Technology

Process-People-Technology triad for product

development.
Process, people and technology are the major determinants
of any products cost, schedule, and quality.
4

When Quality process is

immature

Quality Nodes

Schedule

Requirements

People

Quality

Quality
Cost

Process

Technology

It is important to have motivated, quality work

force but even our finest people cannot
perform at their best when process is not
understood or is not operating at its best.
5

When Quality process is

immature
Immature processes result in fighting fires

No time to improve
Constantly in reactive mode rather than proactive
Firefighters get burned easily !!!!
Embers may rekindle later.

A professional is a man who can do his best at a time when he

doesnt particularly feel like it.
- Alistair Cooke
7

Ad hoc processes are improvised by

practitioners and their management.
Processes are not followed or enforced
Performance is dependent on a particular
practitioner
Understanding the current status of project is
limited.
Heroes are accidental but not professional practitioners
What about your surgeon??

When Quality process is mature

Process descriptions are consistent with the
way work actually gets done.
They are defined, documented and continuously
improved.
Processes are supported visibly by
management.
Well controlled processes are enforced and
evaluated
Constructive use of process measurement
Technology is introduced in a disciplined
manner.
8

When Quality processes is

implemented

Benefits of mature Project

Quality processes
Process improvements are made not processes from
scratch.
Causes less stress for human resources when they move
to different projects and work with different project
managers.
Project status for sponsors and teams are predictable.
Project control techniques are predictable.
Technology, tools and techniques can be introduced
systematically.
Project resources have more chance to develop their
potential and focus on professional growth and training.

Thats the way we do things around here.

Organization contains effective, usable and
consistently applied processes.
Management nurtures the culture.
Culture is conveyed through role model and
recognition.
Processes stay well after the originators (people
who defined the processes) are gone.
Mature processes = Fire Prevention
9

Probability of success

Benefits of predicting
Project performance

Early Process Improvement

a. Process is measured and controlled

b. Process is institutionalized for projects
a.

but is sometimes reactive.

c. Process is poorly controlled, reactive and

unpredictable.

c.
Time/Rs.$/
11

The theories of quality process management are

synthesis of concepts of Deming, Crosby, Juran
and others.
Over the past decades, these theories have been
used to address problems common to many
organizations.
Solutions to some problems have been addressed
many still remain, some hidden and some untold!!
Many of these solutions have been used to build
process improvement models.
12

Improving Project Quality

Several suggestions for improving quality for projects
include:

Organizational Influences

Establish leadership that promotes quality.

Understand the cost of quality.
Focus on organizational influences and workplace
factors that affect quality.
Follow maturity models.
13

Expectations and Cultural

Differences in Quality

Organizational Influences,
Workplace Factors, and Quality
Study by DeMarco and Lister showed that organizational
issues had a much greater influence on programmer
productivity than the technical environment or
programming languages.
Programmer productivity varied by a factor of one to ten
across organizations, but only by 21 percent within the
same organization.
Study found no correlation between productivity and
programming language, years of experience, or salary.
A dedicated workspace and a quiet work environment
were key factors to improving programmer productivity.

Project managers must understand and

manage stakeholder expectations.
Expectations also vary by:
Organizations culture
Geographic regions
15

What is a Quality Process

Model?

Quality Process and Maturity

Model

A process model is a structured collection of

practices that describe the characteristics of
effective processes.
Practices that are included in a process
model have been proven by experience to
be effective.
17

How is a Quality Process Model

used?

Why is a Quality Process Model

important?

A process model is used

A process model provides

To help set process improvement objectives

and priorities of the organization
Helps ensure capable and mature processes
Guide for improving upon existing processes
Use an appraisal method to diagnose state of
an organizational current practices.

A place to start improving

Common language and shared vision
Template for prioritizing actions
Benefit of prior experiences
What improvement means for the organization

Maturity Models

CMMI-Capability Maturity Model

Maturity models are frameworks for helping organizations

improve their processes and systems.
The Software Quality Function Deployment Model
focuses on defining user requirements and planning
software projects.
The Software Engineering Institutes Capability Maturity
Model is a five-level model laying out a generic path to
process improvement for software development in
organizations.

Capability Maturity Model Integration (CMMI)

is a process improvement approach that provides
organizations with the essential elements of effective
processes that ultimately improve their performance.
CMMI can be used to guide process improvement across a
project, a division, or an entire organization
CMMI according to the SEI (Software Engineering
Institute), helps "integrate traditionally separate
organizational functions, set process improvement goals
and priorities, provide guidance for quality processes, and
provide a point of reference for appraising current
processes.

CMMI-Capability Maturity Model

Levels are used in CMMI to describe the path for an
organization that wants to improve the processes it uses to
develop and maintain its products and services.
CMMI supports two improvement approaches;
Continuous-enabling an organization to incrementally
improve processes within a process area selected by the
organization.
Staged enabling the organization to improve a set of
related processes by addressing successive predefined
sets of process areas.
23

PMIs Maturity Model

Project Management Maturity Model

PMI released the Organizational Project Management

Maturity Model (OPM3) in December 2003.
Model is based on market research surveys sent to more
than 30,000 project management professionals and
incorporates 180 best practices and more than 2,400
capabilities, outcomes, and key performance indicators.
Addresses standards for excellence in project, program,
and portfolio management best practices and explains
the capabilities necessary to achieve those best
practices.
25

26
Reference:

Dr. Harold Kerzners PROJECT MANAGEMENT A SYSTEMS APPROACH TO PLANNING, SCHEDULING, AND CONTROLLING
Page 929: Project Management Maturity Model

Continuous Improvement
Bottom Line
Process improvement should be done to help the business
not for its own sake.

In God we trust, all others bring data.

-W. Edwards Deming

27
Reference:

Dr. Harold Kerzners PROJECT MANAGEMENT A SYSTEMS APPROACH TO PLANNING, SCHEDULING, AND CONTROLLING
Page 941: Continuous Improvement

Quality as an organizational goal

Project Quality Management

Creating
Customer
Value

Lec#13
Project Quality Processes
Ghazala Amin

Exceeding
customer
expectations

Employee
Empowerment

Not just doing

it well but
learning to do
it better

Courtesy: Ali Sajid-Cost of Quality in projects

Leadership
As Joseph M. Juran said in 1945, It is
most important that top management be
quality-minded. In the absence of sincere
manifestation of interest at the top, little
will happen below.

Role of Management and

Leadership

A large percentage of quality problems are

associated with management, not
technical issues.
3

*American Society for Quality (ASQ),

(www.asqc.org/about/history/juran.html).

What is Cost of Quality?

Cost Of Quality

Quality is measured by the cost of

quality which is the expense of non
conformance the cost of
doing things wrong.

Courtesy: Ali Sajid-Cost of Quality in projects

The Cost of Quality

Media Snapshot*

Costs of poor quality are huge, but

the amounts are not known with
precision. In most companies, the
accounting system provides only a
minority of the information needed
to quantify this cost of poor quality

A 2004 study by Nucleus Research Inc. estimates that spam

will cost large companies nearly $2,000 per employee in lost
productivity in 2004 alone, despite investments in software to
block spam. Spam currently accounts for more than 70
percent of total e-mail volume worldwide.
In just one month (August 2003), at least 50 new Internet
viruses surfaced, and losses related to computer viruses cost
North American companies about $3.5 billion. Businesses
have suffered at least $65 billion in lost productivity because
of computer viruses since 1997.

Juran on Quality by Design, The Free

Press (1992), p. 119

*McGuire, David, Report: Spam Costs Are Rising at Work, Washington Post (June 7, 2004).
7

Poor Quality Cost

Quality is Free

1964, IBM published its first report included poor-quality cost for internal
component mfg, subassembly, final
assembly, final machine test, system test,
& first 12 months at customer location for
1620 system. called
Q-100 Report

For average company, the cost

of quality is about 25% of total
sales
cost of prevention is a fraction
of cost of fixing mistakes after
they made

During following months, report- expanded to

cover many other IBM systems.

Cost of Quality-Wikipedia

The cost of Quality

Investments in prevention
can drastically reduce total
cost of quality

In process improvement efforts, quality costs or cost of quality is

a means to quantify the total cost of quality-related efforts and
deficiencies.
It was first described by Armand V. Feigenbaum in a 1956 Harvard
Business Review article.
Prior to its introduction, the general perception was that higher
quality requires higher costs, either by buying better materials or
machines or by hiring more labor.
Furthermore, while cost accounting had evolved to categorize
financial transactions into revenues, expenses, and changes in
shareholder equity, it had not attempted to categorize costs
relevant to quality, which is especially important given that most
people involved in manufacturing never set hands on the product.
By classifying quality-related entries from a company's general
ledger, management and quality practitioners can evaluate
investments in quality based on cost improvement and profit
enhancement.

Feigenbaums quality cost areas

Cost of Conformance- Wikipedia

Cost Areas

Description

Cost of Non-Conformance-Wikipedia
Examples

Cost Areas

Prevention Costs

Arise from efforts to keep defects

from occurring at all

Quality Planning
Investment in quality-related
information
Quality training and workforce
Systems development and
management
Product design verification

Appraisal Cost

Arise from detecting defects via

inspection, test, audit

Test and inspection of purchased

materials
Acceptance testing
Inspection
Testing
Checking labor
Setup for test or inspection
Test and inspection equipment
Quality audits
Field testing

Description

Examples

Internal failure costs

Arise from defects

caught internally and
dealt with by discarding
or repairing the
defective items

Scrap
Rework
Material procurement
costs

External failure costs

Arise from defects that

actually reach
customers

Complaints in warranty
Complaints out of
warranty
Product service
Product liability
Product recall
Loss of reputation

The Cost of Quality

Cost of quality is the total price of all efforts to achieve

product or service quality.
It includes work that conforms to the requirements as
well as the work resulting from nonconformance to
the requirements.
Quality programs also have costs which includes
Training programs
SPC (Statistical Process Control) Costs
Cost to build it right the first time etc.

Types of Quality Costs:

Internal Failure cost incurred to correct an identified defect
prior to shipment to the customer
External Failure - cost incurred due to errors detected by the
customer.
Appraisal - cost incurred to determine the condition of the
product
Prevention - costs incurred to reduce failure and appraisal cost
Measurement and Test Equipment capital cost of equipment
used to perform prevention and appraisal activities.
16

The Cost of Non Quality

Conformance Vs. Non-Conformance

Conformance (Quality)

Cost of non-quality is estimated to be 12-20% of sales

versus the should cost of 3-5% of sales for a quality
program.
Waste of time and material
Rework of poor quality products and additional material
for rework
Delays in schedule
Product and service image
Corporate image

Planning
Training and
indoctrination
Product
Design/Validation
Process Validation
Test and Evaluation
Quality Audits
Maint./Calibration
Field Testing

Non-Conformance
Scrap
Rework
Material cost
(additional)
Warranty repairs
Complaint handling
Liability Judgments
Product recall
Field Service
Expediting

These Two Main Areas Can Be Split Further As Shown Below:

Types of Quality Costs

Cost of Compliance
Preventive costs - prevent product defects
Appraisal costs - monitor & compensate
when prevention fails

Cost of Non-compliance
Failure costs
Internal losses - scrap, rework
External losses - warranty work, customer
complaint departments, litigation, product recalls
19

Total Failure Cost

Three Areas to Improve Quality

Quality of design

Profit lost by selling units as defects

Rework cost
Cost of processing customer returns
Cost of warranty work
Cost of product recalls
Cost of litigation related to products
Opportunity cost of lost customers

meet the customers needs

design for manufacturability
build quality in

Quality of conformance
minimize and control process variation to
satisfy the design specifications every time

Quality of service
The customer must come first
21

Project Quality Management

Lecture # 14
Six Sigma

References

Ghazala Amin

http://www.ge.com/sixsigma/SixSigma.
pdf

Six Sigma

Six Sigma is a comprehensive and flexible

system for achieving, sustaining, and maximizing
business success. Six Sigma is uniquely driven
by close understanding of customer needs,
disciplined use of facts, data, and statistical
analysis, and diligent attention to managing,
improving, and reinventing business processes.*

Six Sigma is a rigorous management discipline

that systematically reduces variations, eliminates
errors, improves processes and reduces cost.*

*Pande, Peter S., Robert P. Neuman, and Roland R. Cavanagh, The

Six Sigma Way, New York: McGraw-Hill, 2000, p. xi.

* Quality training classes advertisement for six sigma training.

It is driven by close understanding of customer

needs, disciplined use of facts, statistical
analysis, and diligent attention to managing
improving and reinventing of business processes.
4

DMAIC

Basic Information on Six Sigma

DMAIC is a systematic, closed-loop process

for continued improvement that is scientific
and fact based.
DMAIC stands for:

The target for perfection is the achievement of

no more than 3.4 defects per million
opportunities.

Define
Measure
Analyze
Improve
Control

The principles can apply to a wide variety of

processes.
Six Sigma projects normally follow a five-phase
improvement process called DMAIC.
5

DMAIC

How is Six Sigma Quality Control Unique?

DMAIC stands for:

Define: Define the problem/opportunity, process, and
customer requirements.
Measure: Define measures, then collect, compile, and
display data.
Analyze: Scrutinize process details to find improvement
opportunities.
Improve: Generate solutions and ideas for improving the
problem.
Control: Track and verify the stability of the improvements
and the predictability of the solution.
7

It requires an organization-wide commitment.

Six Sigma organizations have the ability and
willingness to adopt contrary objectives, such as
reducing errors and getting things done faster.
It is an operating philosophy that is customer
focused and strives to drive out waste, raise
levels of quality, and improve financial
performance at breakthrough levels.
8

Examples of Six Sigma Organizations

Motorola, Inc. pioneered the adoption of Six
Sigma in the 1980s and saved about $14
billion.*
Allied Signal/Honeywell saved more than
$600 million a year by reducing the costs of
reworking defects and improving aircraft
engine design processes.**
General Electric uses Six Sigma to focus on
achieving customer satisfaction.
*Pande, Peter S., Robert P. Neuman, and Roland R. Cavanagh, The Six Sigma Way. New York: McGraw-Hill, 2000,
9

p. 7.
**Ibid. p. 9.

Reference: http://media.techtarget.com/searchSoftwareQuality/downloads/SixSigmaContImprove.pdf

Six Sigma and Project Management

Joseph M. Juran stated, All improvement takes place,
project by project, and in no other way.*
Its important to select projects carefully and apply higher
quality where it makes sense; companies that use Six
Sigma do not always boost their stock values.
As Mikel Harry puts it, I could genetically engineer a Six
Sigma goat, but if a rodeo is the marketplace, people are
still going to buy a Four Sigma horse.**
Six Sigma projects must focus on a quality problem or
gap between the current and desired performance and
not have a clearly understood problem or a
predetermined solution.
*What You Need to Know About Six Sigma, Productivity Digest (December 2001), p. 38.
11
**Clifford, Lee, Why You Can Safely Ignore Six Sigma, Fortune (January 22, 2001), p. 140.

Six Sigma Projects Use Project Management

The training for Six Sigma includes many project
management concepts, tools, and techniques.
For example, Six Sigma projects often use
business cases, project charters, schedules,
budgets, and so on.
Six Sigma projects are done in teams; the project
manager is often called the team leader, and the
sponsor is called the champion.
12

Six Sigma and Statistics

Six Sigma Uses a Conversion Table

The term sigma means standard deviation.

Using a normal curve, if a process is at six sigma, there

would be no more than two defective units per billion
produced.

Standard deviation measures how much

variation exists in a distribution of data.

Six Sigma uses a scoring system that accounts for time, an

important factor in determining process variations.

Standard deviation is a key factor in

determining the acceptable number of
defective units found in a population.

Yield represents the number of units handled correctly

through the process steps.

Six Sigma projects strive for no more than 3.4

defects per million opportunities, yet this
number is confusing to many statisticians.
13

Figure. Normal Distribution and

Standard Deviation

A defect is any instance where the product or service fails to

meet customer requirements.
There can be several opportunities to have a defect.
14

Table. Sigma and Defective Units

Specification Range
(in +/- Sigmas)

Percent of
Population

Defective Units
Per Billion

Within Range

68.27

317,300,000

95.45

45,400,000

99.73

2,700,000

99.9937

63,000

99.999943

99.9999998

Six Sigma Conversion Table

The Six Sigma convention for determining defects is based on the above
conversion table. It accounts for a 1.5 sigma shift to measure the number of
defects per million opportunities instead of the number of defects
per unit.
17

We bring good things to life

What Is Six Sigma?

The Roadmap
to Customer

Impact

Making Customers Feel Six Sigma Quality

Globalization and instant access to information, products and services have changed the way
our customers conduct business old business models no longer work. Todays competitive
environment leaves no room for error. We must delight our customers and relentlessly look for
new ways to exceed their expectations. This is why Six Sigma Quality has become a part
of our culture.
What is Six Sigma?
First, what it is not. It is not a secret society, a slogan or a clich. Six Sigma is a highly
disciplined process that helps us focus on developing and delivering near-perfect products
and services. Why Sigma? The word is a statistical term that measures how far a given
process deviates from perfection. The central idea behind Six Sigma is that if you can
measure how many defects you have in a process, you can systematically figure out how
to eliminate them and get as close to zero defects as possible. Six Sigma has changed
the DNA of GE it is now the way we work in everything we do and in every product we design.

GEs Evolution Towards Quality

GE began moving towards a focus on quality in the late 80s. Work-Out, the start of our
journey, opened our culture to ideas from everyone, everywhere, decimated the bureaucracy
and made boundaryless behavior a reflexive, natural part of our culture, thereby creating
the learning environment that led to Six Sigma. Now, Six Sigma, in turn, is embedding
quality thinking process thinking across every level and in every operation of our
Company around the globe.
Work-Out in the 1980s defined how we behave. Today, Six Sigma is defining how we
work and has set the stage for making our customers feel Six Sigma.

GEs Evolution Towards Quality

Six Sigma Quality:
The Road to Customer Impact

High

Key Strategy Initiatives:

QMI, NPI, OTR, SM, Productivity, Globalization

INTENSITY

Change Acceleration Process:

Increase Success and Acceleration Change
Process Improvement:
Continuous Improvement, Reengineering
Productivity/Best Practices:
Looking Outside GE
Work-Out/Town Meetings:
Empowerment, Bureaucracy Busting

Low

1990

TIME

Key Elements of Quality...Customer, Process and Employee

There are three key elements of quality: customer, process and employee. Everything we do to remain a world-class
quality company focuses on these three essential elements.

...the Customer
Delighting Customers
Customers are the center of GEs universe: they define quality. They expect
performance, reliability, competitive prices, on-time delivery, service, clear and correct
transaction processing and more. In every attribute that influences customer perception,
we know that just being good is not enough. Delighting our customers is a necessity.
Because if we dont do it, someone else will!

...the Process
Outside-In Thinking
Quality requires us to look at our business from the customers perspective, not ours. In other
words, we must look at our processes from the outside-in. By understanding the transaction
lifecycle from the customers needs Customers
View of GEs
and processes, we can discover
Contribution
what they are seeing and feeling.
A
B
C
With this knowledge, we can
Customer
Process
identify areas where we can add
GE Process
significant value or improvement
from their perspective.
GEs View

...the Employee

of Its
Contribution

Leadership Commitment
People create results. Involving all employees is essential to GEs quality approach. GE is
committed to providing opportunities and incentives for employees to focus their talents and
energies on satisfying customers.
All GE employees are trained in the strategy, statistical tools and techniques of Six Sigma
quality. Training courses are offered at various levels:

Quality Overview Seminars: basic Six Sigma awareness.

Team Training: basic tool introduction to equip employees to participate on

Six Sigma teams.

Master Black Belt, Black Belt and Green Belt Training: in-depth quality training
that includes high-level statistical tools, basic quality control tools, Change Acceleration
Process and Flow technology tools.

Design for Six Sigma (DFSS) Training: prepares teams for the use of
statistical tools to design it right the first time.

Quality is the responsibility of every employee. Every employee must be involved, motivated
and knowledgeable if we are to succeed.

The Six Sigma Strategy

To achieve Six Sigma quality, a process must produce no more than 3.4 defects per million opportunities. An opportunity
is defined as a chance for nonconformance, or not meeting the required specifications. This means we need to be nearly
flawless in executing our key processes. Six Sigma is a vision we strive toward and a philosophy that is part of our
business culture.

Key Concepts of Six Sigma

At its core, Six Sigma revolves around a few key concepts.
Critical to Quality:

Attributes most important to the customer

Defect:

Failing to deliver what the customer wants

Process Capability:

What your process can deliver

Variation:

What the customer sees and feels

Stable Operations:

Ensuring consistent, predictable processes to improve

what the customer sees and feels

Design for Six Sigma: Designing to meet customer needs and process capability

Our Customers Feel the Variance, Not the Mean

Often, our inside-out view of the business is based on average or mean-based measures of our recent past. Customers
dont judge us on averages, they feel the variance in each transaction, each product we ship. Six Sigma focuses first on
reducing process variation and then on improving the process capability.
Customers value consistent, predictable business processes that deliver world-class levels of quality. This is what Six
Sigma strives to produce.

GEs Commitment to Quality

GEs success with Six Sigma has exceeded our most optimistic predictions. Across the Company, GE associates
embrace Six Sigmas customer-focused, data-driven philosophy and apply it to everything we do. We are building
on these successes by sharing best practices across all of our businesses, putting the full power of GE behind our
quest for better, faster customer solutions.

Glossary of Terms and Definitions

Quality Approaches and Models
DFSS (Design for Six Sigma) is a systematic methodology utilizing tools, training and measurements to
enable us to design products and processes that meet
customer expectations and can be produced at Six Sigma
quality levels.
DMAIC (Define, Measure, Analyze, Improve and
Control) is a process for continued improvement. It is
systematic, scientific and fact based. This closed-loop
process eliminates unproductive steps, often focuses
on new measurements, and applies technology for
improvement.
Six Sigma A vision of quality which equates with only
3.4 defects per million opportunities for each product or
service transaction. Strives for perfection.
Quality Tools

Tree Diagram Graphically shows any broad goal broken into different levels of detailed actions. It encourages
team members to expand their thinking when creating
solutions.
Quality Terms
Black Belt Leaders of team responsible for measuring, analyzing, improving and controlling key processes
that influence customer satisfaction and/or productivity
growth. Black Belts are full-time positions.
Control The state of stability, normal variation and predictability. Process of regulating and guiding operations
and processes using quantitative data.
CTQ: Critical to Quality (Critical Y) Element of
a process or practice which has a direct impact on its
perceived quality.

Associates are exposed to various tools and terms

related to quality. Below are just a few of them.

Customer Needs, Expectations Needs, as defined

by customers, which meet their basic requirements and
standards.

Control Chart Monitors variance in a process over

time and alerts the business to unexpected variance
which may cause defects.

Defects Sources of customer irritation. Defects are

costly to both customers and to manufacturers or service
providers. Eliminating defects provides cost benefits.

Defect Measurement Accounting for the number

or frequency of defects that cause lapses in product or
service quality.

Green Belt Similar to Black Belt but not a full-time

position.

Pareto Diagram Focuses on efforts or the problems

that have the greatest potential for improvement by
showing relative frequency and/or size in a descending
bar graph. Based on the proven Pareto principle: 20% of
the sources cause 80% of any problems.
Process Mapping Illustrated description of how
things get done, which enables participants to visualize
an entire process and identify areas of strength and
weaknesses. It helps reduce cycle time and defects while
recognizing the value of individual contributions.
Root Cause Analysis Study of original reason for
nonconformance with a process. When the root cause
is removed or corrected, the nonconformance will be
eliminated.
Statistical Process Control The application of statistical methods to analyze data, study and monitor process
capability and performance.

Master Black Belt First and foremost teachers. They

also review and mentor Black Belts. Selection criteria for
Master Black Belts are quantitative skills and the ability
to teach and mentor. Master Black Belts are full-time
postions.
Variance A change in a process or business practice
that may alter its expected outcome.

We bring good things to life

19991438-1

PROJECT QUALITY
MANAGEMENT

STUDY NOTES
PMBOK 2000 based, Version 6

In Preparation For
PMP Certification Exam

IBM Education and Training

Worldwide Certified Material

Publishing Information
This publication has been produced using Lotus Word Pro 96.

Trademarks
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both: IBM
Lotus, Lotus Notes, Lotus Word Pro, and Notes are trademarks of Lotus Development
Corporation in the United States, or other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation of the United States, or other countries, or both.
The following are certification, service, and/or trademarks of the Project Management Institute,
Inc. which is registered in the United States and other nations: PMI is a service and
trademark, PMI Logo and "PMBOK", are trademarks, PMP and the PMP logo are
certification marks.
Other company, product, and service names may be trademarks or service marks of others.
Disclaimer
PMI makes no warranty, guarantee, or representation, express or implied, that the successful
completion of any activity or program, or the use of any product or publication, designed to prepare
candidates for the PMP Certification Examination, will result in the completion or satisfaction of any
PMP Certification eligibility requirement or standard., service, activity, and has not contributed any
financial resources.
Initially Prepared By: Kim Ulmer
Edited By: Peter Dapremont

April 2002 Edition

The information contained in this document has not been submitted to any formal IBM test and is
distributed on an as is basis without any warranty either express or implied. The use of this information
or the implementation of any of these techniques is a customer responsibility and depends on the
customers ability to evaluate and integrate them into the customers operational environment. While
each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that
the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their
own environments do so at their own risk.
Copyright International Business Machines Corporation 2002. All rights reserved. IBM and its
logo are trademarks of IBM Corporation. This document may not be reproduced in whole or in
part without the prior written permission of IBM.
Note to U.S. Government Users--Documentation related to restricted rights--Use, duplication or
disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Project Quality Management

Quality Management
Study Notes

Reference Material to study:

A Guide to the Project Management Body of Knowledge (PMBOK), Chapter 8 (2000
edition)
Quality Management for Projects and Programs, Ireland, Lewis R., 1991
PMP Exam Practice Test and Study Guide, 4th Edition, by Ward, J. LeRoy, PMP ,
2001
PMP Exam Prep, 3rd Edition, by Mulcahy, Rita, PMP, 2001
ESI PMP Challenge!, 3rd Edition, Quality Section, Ward, J. LeRoy, 2001
What to Study?
The PMBOK phases of Project Quality Management: Quality Planning, Quality
Assurance, and Quality Control (Be familiar with Inputs, Tools and Techniques, and
Outputs for each phase)
Know the difference between quality and grade.
Know the difference between Quality Control and Quality Assurance
Project characteristics and attributes (the bilities) (Ireland, Chapter II)
Cost of Quality (Ireland, Chapter IV)
Statistical Concepts and Quality Tools (Ireland, Chapter V)
Cost Trade-offs
Know the difference between the ISO 9001 Certification and the Malcom Baldrige
Award.
Know the difference between the Deming, Juran, and Crosby Management approaches
Pareto and fishbone diagrams

"PMBOK" is a trademark of the Project Management Institute, Inc. which is registered in the United States and other nations.
PMI is a service and trademark of the Project Management Institute, Inc. which is registered in the United States and other nations.
PMP and the PMP logo are certification marks of the Project Management Institute which are registered in the United States and other
nations.

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-3

Project Quality Management

Key Definitions
Control

Control Charts

Corrective Action
Cost of Conformance
Cost of
Nonconformance
Cost of Quality
Grade

Monitoring
Monte Carlo Analysis
Pareto Diagram
Paretos Law

Performance Reporting

Project Quality
Management

Quality
Quality Assurance (QA)

The process of comparing actual performance with planned

performance, analyzing variances, evaluating possible
alternatives, and taking appropriate corrective action as needed.
A graphic display of the results, over time and against
established control limits, of a process. The charts are used to
determine if the process is in control or in need of adjustment.
Changes made to bring expected future performance of the
project in line with the plan.
The cost of conforming to Specifications, Planning, Training,
Control, Validation, Test, and Audits.
The cost of not conforming is Scrap, Rework, Additional Work,
Warranty, Complaint Handling, Product Recall, Expediting.
The cost incurred to ensure quality. Includes quality planning,
quality control, quality assurance, and rework.
A category or rank used to distinguish items that have the same
functional use (e.g., hammer), but do not share the same
requirements for quality (e.g., different hammers may be built to
withstand varying degrees of force)
The capture, analysis, and reporting of project performance,
usually as compared to plan.
A technique that performs a project simulation many times to
calculate a distribution of likely results.
A histogram ordered by frequency of occurrence that shows how
many results were generated by each identified cause.
A supposition that states that a relatively small number of causes
will typically produce a large majority of the problems or defects.
Commonly referred to as the 80/20 principle in which 80% of the
problems can be attributed to 20% of the causes.
Collecting and disseminating information about project
performance to help access project progress. Includes status
reporting, progress measurement, and forecasting.
The processes required to ensure that the project will satisfy the
needs for which it was undertaken. Modern quality management
complements modern project management in that both recognize
the importance of customer satisfaction and prevention over
inspection.
The totality of characteristics of an entity that bear on its ability to
satisfy stated or implied needs.
1) The process of evaluating overall project performance on a
regular basis to provide confidence that the project will satisfy the
relevant quality standards. 2) The organizational unit that is
assigned responsibility for quality assurance.

5-4 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

Project Quality Management

Key Definitions, continued

Quality Control (QC)

Quality Plan

Quality Policy

Quality Planning
Rework
Total Quality
Management (TQM)

Copyright IBM Corp. 2002

1)The process of monitoring specific project results to determine

if they comply with relevant quality standards and identifying
ways to eliminate causes of unsatisfactory performance. 2) The
organizational unit that is assigned responsibility for quality
control.
A document setting out the specific quality practices, resources
and sequence of activities relevant to a particular product,
service, contract or project. (ISO-8402)
The overall quality intentions and direction of an organization as
regards quality, as formally expressed by top management.
(ISO-8402)
Identifying which quality standards are relevant to the project and
determining how to satisfy them.
Action taken to bring a defective or nonconforming item into
compliance with requirements or specifications.
A common approach to implementing a quality improvement
program within an organization.

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-5

Project Quality Management

Project Quality Management Concepts

Project Quality Management:

Includes the processes required to ensure that the project will satisfy the needs for
which it was undertaken.
Includes all activities of the overall management function that determine the quality
policy, objectives, and responsibilities and implements these by means such as quality
planning, quality assurance, quality control, and quality improvement within the quality
system.
Must address both the management of the project and the product or service of the
project.
Failure to meet quality requirements in either dimension can have serious negative
consequences for the project stakeholders. For example:
Meeting customer requirements by overworking the project team may produce
negative consequences in the form of increased employee attrition.
Meeting project schedule objectives by rushing planned quality inspections may
produce negative consequences when errors go undetected.
Modern quality management complements project management. For example, both
disciplines recognize the importance of:
Customer satisfaction:
Understanding, managing, and influencing needs so that customer
expectations are met.
Requires a combination of conformance to requirements and fitness for
use. (the product/service must satisfy real needs)
Prevention over inspection: the cost of preventing mistakes is always much
less than the cost of correcting the mistakes, as revealed by inspection.
Management responsibility: success requires the participation of all members
of the team, but it remains the responsibility of management to provide the
resources needed to succeed.
Processes within phases: the repeated plan-do-check-act cycle described by
Deming and others is highly similar to the Project Management Processes.
(described in Chapter 3 of the PMBOK Guide.)

Quality:

Is the totality of characteristics of an entity that bear on its ability to satisfy stated or
implied needs. Stated and implied needs are the inputs to developing project
requirements.
Should not be confused with grade. Grade is a category or rank given to entities having
the same functional use but different technical characteristics. Low quality is always a
problem; low grade may not be. For example:
A software product may be of high quality (very few defects, a readable users
manual) but of low grade meaning it has a limited number of features.
Or, a software product may be of low quality but of high grade meaning it has
many defects but lots of customer features.

5-6 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

output variable. Examples: cost and schedule variances, volume and

frequency of scope changes, errors in project documents, etc.

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-11

Project Quality Management

Project Quality Management Processes, cont.

Pareto diagrams:
Histograms ordered by frequency of occurrence that display how many
results were generated by type or category of an identifiable cause.
Rank ordering is used to guide corrective action with the assumption
that the project team should take action to fix the problems that are
causing the greatest number of defects, first.
Are conceptually related to Paretos Law which holds that a relatively
small number of causes will typically produce a large majority of the
problems or defects. This is commonly referred to as the 80/20
principle where 80% of the problems are due to 20% of the causes.
Statistical sampling:
Involves choosing a population of interest for inspection. (e.g.,
selecting ten engineering drawings at random from a list of
seventy-five).
Appropriate sampling can often reduce the cost of quality control.
In some application areas, the project management team must be
familiar with a variety of sampling techniques.
Trend analysis:
Uses mathematical techniques to forecast future outcomes based on
historical results.
Often used to monitor technical performance (how many errors or
defects have been identified, how many remain uncorrected) as well
as cost and schedule performance (how many activities per period
were completed with significant variances.)
Outputs include: quality improvement, acceptance decisions, rework, completed
checklists, and process adjustments.
Acceptance decisions: Decisions to either accept or reject the inspected items.
Rejected items may require rework.
Rework: Action taken to bring a defective or nonconforming item into
compliance with requirements or specifications. Rework, especially
unanticipated, is a frequent cause of project overruns in most application areas.
The project team should make every reasonable effort to minimize rework.
Process adjustments: Immediate corrective or preventive action as a result of
quality control measurements. In some cases, the process adjustment may
need to be handled according to procedures for integrated change control.

5-12 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

Project Quality Management

Project Quality Management Concepts

Definition of Quality: (from Ireland book)

Quality is the totality of features and characteristics of a product or service that bear on
its ability to satisfy stated or implied needs.
Some goals of quality programs include:
Fitness for use. (Is the product or service capable of being used?)
Fitness for purpose. (Does the product or service meet its intended purpose?)
Customer satisfaction. (Does the product or service meet the customers
expectations?)
Conformance to the requirements. (Does the product or service conform to the
requirements?)

Quality Movements:

ISO (International Organization for Standardization)

A worldwide federation of national standard bodies.
The work of preparing international standards is done by ISO technical
committees.
ISO 9001 and ISO 9004 are a set of complementary standards with a focus on
quality.
ISO 9001 specifies requirements for a quality management system that
can be used for internal application, ISO certification, or for contractual
purposes.
ISO 9004 provides guidance on a wider range of objectives of a quality
management system than ISO 9001. It emphasizes the continual
improvement of an organizations overall performance, efficiency, and
effectiveness. Used in organizations whose top management wishes to
move beyond the requirements of ISO 9001 in pursuit of continual
improvement. ISO 9004 is not used for ISO certification or contractual
purposes.
Requirements are centered around a methodology called Plan, Do, Check, Act
(PDCA)
Plan: Establish the objectives and processes necessary to deliver results
in accordance with customer requirements and the organizations policies.
Do: Implement the processes.
Check: Monitor and measure processes and product against policies,
objectives, and requirements for the product and report the results.
Act: Take actions to continually improve process performance.

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-13

Project Quality Management

Project Quality Management Concepts, cont.

Quality Movements, cont.

Deming Prize (Overseas)

Administered by the Union of Japanese Scientists and Engineers (JUSE)
Awarded to overseas companies that demonstrate a superior quality program
Checklist includes: organizations policy, structure, education, collection,
dissemination, and use of information, analysis of problems, establishment and
use of standards, management system, quality assurance, effects, and future
plans. (See Ireland, Appendix A)
Demings 4 step cycle for improvement: Plan, Do, Check, Act
Demings major points for implementing quality
1. Participative approach
2. Adopt new philosophy
3. Cease mass inspection
4. End awards based on price
5. Improve production and service
6. Institute leadership
7. Eliminate numerical quotas
8. Education and training
9. Encourage craftsmanship

Malcolm Baldrige
The Malcolm Baldrige National Quality Improvement Act was established in
Aug. 20, 1987.
Purpose of the act was to promote quality awareness; to recognize quality
achievements of U.S. companies, and to publicize successful quality strategies.
Covers the following seven categories: (See Ireland, Appendix B)
1. Leadership
2. Information and Analysis
3. Strategic Quality Planning
4. Human Resources
5. Quality Assurance
6. Results
7. Customer Satisfaction

Department of Defense: Total Quality Management (TQM)

Quality is key to maintain level of readiness
Quality is vital to our defense, requires a commitment by all personnel
Quality is a key element of competition

5-14 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

Project Quality Management

Project Quality Management Concepts, cont.

Quality Movements, cont.

Juran

Attitude breakthrough
Identify vital new projects
Knowledge breakthrough
Conduct the analysis
Institute change
Overcome resistance and institute controls

Philip Crosby (ITT): Quality is Free

Four absolutes of quality management:
1. Quality is conformance to requirements.
2. The system of quality is prevention.
3. The performance standard is zero defects
4. The measurement of quality is the price of nonconformance.
14 steps to improving quality.
1. Management commitment
2. Quality improvement team
3. Measurement
4. Cost of quality
5. Quality awareness
6. Corrective action
7. Zero defects planning
8. Employee education
9. Zero defects day
10. Goal setting
11. Error cause removal
12. Recognition
13. Quality councils
14. Do it over again

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Affordability (Return for quality required)

The ability to develop, acquire, operate, maintain, and dispose of a product over
its life. The cost of each phase of ownership has a different value based on
such items as design, manufacture, maintainability, reliability, and use. There
must be a balance between the initial cost of a product and the operation and
maintenance costs. For example: a $30,000 automobile with maintenance
costs of 20 cents per mile may be considered more affordable than a $100,000
automobile with maintenance costs of 1 cent per mile or a $5,000 automobile
with maintenance costs of $2 per mile.

Cost of Quality: (from Quality Management by Ireland)

Cost of quality is the total price of all efforts to achieve product or service quality. This
includes all work to build a product or service that conforms to the requirements as
well as all work resulting from nonconformance to the requirements.
Quality programs also have costs that are not apparent. The general categories of
additional direct costs include:
Cost to build right the first time
Training programs
Statistical Process Control (SPC) Costs
Cost of a quality system is often viewed as a negative cost because errors in work have
been traditionally accepted as a cost of doing business.

Cost of Conformance:

Planning
Training and indoctrination
Process control
Field testing
Product design validation
Process validation
Test and evaluation
Inspection/Quality audits
Maintenance and calibration

Cost of Nonconformance

Scrap
Rework
Expediting
Additional material or inventory
Warranty repairs or service
Complaint handling
Liability judgments
Product recalls
Product corrective actions

5-18 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

Project Quality Management

Project Quality Management Concepts, Continued

Cost of Non-Quality:

Cost of non-quality is estimated to be 12-20% of sales versus the should cost of 3-5%
of sales for a quality program.
Waste of time and materials
Rework of poor quality products and additional material for rework
Delays in schedule
Product and service image
Corporate image

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-19

Project Quality Management

Project Quality Management Concepts, Continued

Major Cost Categories of Quality:

Prevention Cost - cost to plan and execute a project so that it will be error-free
Appraisal Cost - cost of evaluating the processes and the outputs of the processes to
ensure the product is error-free
Internal Failure Cost - cost incurred to correct an identified defect before the customer
receives the product
External Failure Cost - cost incurred due to errors detected by the customer. This
includes warranty cost, field service personnel training cost, complaint handling, and
future business losses.
Measurement and Test Equipment - capital cost of equipment used to perform
prevention and appraisal activities.

Opportunities for Reducing Cost:

Just-in-Time - concept of zero inventory in a manufacturing plant. Reduces cost of

storing and moving parts; cost of inventory; cost of parts damaged through handling,
etc.
Product Life Cycle Cost - concept of reducing overall product life cycle cost by linking
the cost areas of the product life cycle (R&D, acquisition, and operations and
maintenance) and considering each ones cost implications for the other.
Product Maturity - Identifying, documenting, and correcting failures early helps products
achieve stability earlier in the life cycle. (see Ireland, IV-9)
Areas of Waste in Projects
Waste in rejects of completed work
Waste in design flaws
Waste in work-in-process
Waste in motion for manpower (under-trained employee)
Waste in management (Improper direction of work)
Waste in manpower (Misplaced or waiting workers)
Waste in facilities (Ordering excess material)
Waste in expenses (Unnecessary meetings, travel)

5-20 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

Project Quality Management

Statistical Concepts and Quality Tools

Statistical Quality Control:

Method used to measure variability in a product for evaluation and corrective actions
Normal Distribution Curve or Bell Curve
Six standard deviations (+/- 3 Sigma) encompass 99.73% of area
Four standard deviations (+/- 2 Sigma) encompass 95.46% of area
Two standard deviations (+/- 1 Sigma) encompass 68.26% of area
Sigma () = Standard Deviation

Quality Control Systems:

Process Control Charts

Statistical techniques used for monitoring and evaluating variations in a process.
Identifies the allowable range of variation for a particular product characteristic
by specifying the upper and lower bounds for the allowable variation.
Upper Control Limit (UCL), Lower Control Limit (LCL), process average: the
mean of the averages for the samples taken over a long period of time. (see
Ireland V-2 through V-7. Also see PMBOK Guide 2000 Figure 8-4.)
Visual patterns indicating out-of-control state or a condition that requires
attention:
1. Outliers: a sample point outside the control limits (also referred to as
out-of-control)
2. Hugging control limit: a series (run) of points that are close to a control
limit. Requires correction to prevent data points from going outside the
control limit. Rule of Thumb: Considered abnormal if two of three, three
of seven, or four of ten data points fall within the outer one-third of the
chart.
3. Cycle: A repeating pattern of points.
4. Trend: A series of consecutive points which reflect a steadily increasing
or decreasing pattern. Rule of Thumb: Considered abnormal when
seven or more consecutive data points reflect a steadily increasing or
decreasing pattern.
5. Run: A series of 7 or more consecutive points (observations) fall on the
same side of the average (mean) (Ireland V-6, V-7) Rule of Thumb:
Considered abnormal if seven consecutive points, ten of eleven, or
twelve of fourteen data points are above or below the process average.

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-21

Project Quality Management

Acceptance Sampling
Used when expensive and time-consuming to test 100%. Random sampling
may be used to check the characteristics and attributes of a given lot of goods.
Determines whether or not the lot conforms to the specifications or standards
necessary to support the overall project requirements.
Inspection and test standards must be established to ensure that procedures are
adequate to determine whether a lot is conforming or nonconforming to
specifications.
Standards must also be set for qualification of the sampled lot.
Important to select a sample size that will provide sufficient information about the
larger lot of goods without costing a great deal of money.
Must determine in advance the number of allowable defects before the lot is
rejected. (see Ireland V-8)

Quality Management Tools:

Histograms
Shows frequency of occurrence of items within a range of activity.
Can be used to organize data collected for measurements done on a product or
process.
Pareto Diagram
Ranks defects in order of frequency of occurrence to depict 100% of the defects.
(Displayed as a histogram)
Defects with most frequent occurrence should be targeted for corrective action.
80-20 rule: 80% of problems are found in 20% of the work.
Does not account for severity of the defects
Cause and Effect Diagrams (fishbone diagrams or Ishikawa diagrams)
Analyzes the inputs to a process to identify the causes of errors.
Generally consists of 8 major inputs to a quality process to permit the
characterization of each input. (See Ireland, V-13)
Scatter diagrams
Used to determine the relationship between two or more pieces of corresponding
data.
The data are plotted on an X-Y chart to determine correlation (highly positive,
positive, no correlation, negative, and highly negative) (See Ireland, V-14)
Other Tools
Graphs
Check sheets (tic sheets) and check lists
Flowcharts

5-22 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

Project Quality Management

Project Quality Management Concepts, continued

Quality and People in Project Management:

Management defines type and amount of work

Management is 85% responsible for quality
The employee can only assume responsibility for meeting the requirements of
completing the work when the employee:
Knows whats expected to meet the specifications
Knows how to perform the functions to meet the specifications
Has adequate tools to perform the function
Is able to measure the performance during the process
Is able to adjust the process to match the desired outcome
Project quality team consists of:
Senior Management
Project Manager
Project Staff
Customer
Vendors, suppliers, and contractors
Regulatory Agencies
Project Manager has the ultimate responsibility for Quality Control and Quality
Assurance.
Customer sets the requirement for acceptable quality level.
Reviews & Audits
Management reviews determine the status, progress made, problems, and
solutions
Peer reviews determine whether proposed or completed work meets the
requirements
Competency center reviews are used to validate documentation, studies, and
proposed technical solutions to problems.
Fitness reviews and audits determine the fitness of a product or part of a project.
(addresses specific issues)
The collection of quantitative data for statistical analysis is the basis for proactive
management by FACT rather than by EXCEPTION. Management by exception lets
errors and defects happen before management intervention.

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-23

Project Quality Management

Sample Questions
1.

The process of evaluating overall project performance on a regular basis to provide

confidence that the project will satisfy the relevant quality standards is called:
A. Quality Assurance
B. Quality Control
C. Quality Planning
D. Quality Review

21. Design of experiments is a statistical technique that helps:
A. Determine how various elements of a system interrelate
B. Anticipate what and where quality problems might occur
C. Identify which factors might influence specific variables
D. Establish a standard by which to measure performance
22. Which of the following statements about the cost of quality is/are true?
A. The costs of quality are mostly the direct responsibility of workers who are
manufacturing the product.
B. The cost of quality is the cost of conformance and non conformance to the
requirements and specifications.
C. Quality control programs should only be implemented when the costs of quality are
deemed affordable by management.
D. All are true.
23. Quality control charts are used for the:
A. Monitoring and subsequent evaluation of process variations
B. Determination of which projects to kill
C. Activity known as curve fitting or least squares
D. Lot rejection ratio
24. A Pareto diagram is most useful for:
A. Identifying nonconformity types
B. Providing an evaluation of data at a single point in time
C. Determining where to focus corrective action
D. Accepting or rejecting a production lot
25. In ISO 9001 terminology, the quality management plan should do which of the following?
(choose best answer)
A. Describe the expected grade of the project product
B. Describe the terms and conditions of the contract
C. Describe the project quality system
D. Describe the degree of acceptable nonconformance to quality
26. Quality Planning is:
A. Identifying which quality standards are relevant to the project and determining how to
satisfy them
B. Preparing the design to the customers specifications
C. Monitoring the project results to decide if the outputs fulfill the requirements
D. Determining the necessary quality sampling techniques

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-27

Project Quality Management

Sample Questions, continued

27. The continuous quality improvement process is a concept that states: (choose the best
answer)
A. The customer is the most important aspect of a quality product
B. The work is continuously changing and that any procedure or process that is
satisfactory today, will more than likely become unsatisfactory in the near future
C. To succeed in business; it is important to retain customers and for them to have a
willingness to repurchase
D. The customer is driving the need to improve quality
28. The rule of seven:
A. States that a batch should be rejected if there are seven consecutive rejects
B. States that seven consecutive observations on one side of the mean indicates a batch
should be rejected
C. Means that a minimum sample size of seven should be taken
D. States that seven consecutive observations on one side of the mean is highly
improbable
29. Which of the following is a tool and technique used in quality assurance process?
A. Design of experiments
B. Continuous improvement
C. Quality audits
D. Inspections
30. Process Adjustments:
A. Are actions taken to bring a conforming item into compliance
B. Involve immediate corrective or preventive action as a result of quality control
measurements
C. Are reviews used to validate documentation, studies, and proposed technical
solutions to problems
D. Are acceptance plans and processes for making decisions

5-28 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

Project Quality Management

Answer Sheet

16.

17.

18.

19.

20.

21.

22.

23.

24.

10.

25.

11.

26.

12.

27.

13.

28.

14.

29.

15.

30.

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-29

Project Quality Management

Answers
1
2
3
4
5
6
7
8

A
B
D
D
C
B
A
D

9
10
11
12
13

A
C
B
D
C

14 B
15
16
17
18
19
20
21
22
23
24
25
26
27
28

A
D
D
B
A
C
C
B
A
C
C
A
B
D

29 C
30 B

PMBOK Guide, pg. 95

PMBOK Guide, pg. 95
PMBOK Guide Glossary
PMBOK Guide, pg. 96 Quality audits are used during Quality Assurance
Ireland, pg. C-8
Ireland, pg. I-6
Class notes
Ireland, pgs. IV-1 thru IV-2 The cost of quality includes all work to build a
product or service that conforms to the requirements as well as all work resulting
from nonconformance to the requirements.
Ireland, pg. I-6
Ireland, pg. I-5
Ireland, pg. II-4
Ireland, pg. IV-2, Process Control is a conformance cost.
Ireland, pgs. IV-2 and IV-11. Having an allowable defect rate is an example of
the cost of non-quality. Any system or process that will accept defects adds
cost to the product or service.
PMBOK Guide, pg. 96 Low quality is always a problem; however, low grade in
itself is not necessarily a problem.
Ireland, pg. V-7
Ireland, pgs. V-7 thru V-8
Ireland, pg. C-6
Class notes
Ireland, pg. V-11
Ireland, pg. IV-7
PMBOK Guide, pg. 99
Ireland pg. C-2
Ireland pg. V-3
PMBOK Guide, pg. 103
PMBOK Guide, pg. 99
PMBOK Guide, pg. 95
Ireland pg. I-6
Ireland pg. V-6 The probability of seven consecutive observations falling on one
side of the mean is (0.5) ** 7 = .78%.
PMBOK Guide, pg. 96
PMBOK Guide, pg. 104

5-30 Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Copyright IBM Corp. 2002

Project Quality Management

PMP Certification Exam Preparation

What did I do wrong ?

I would have answered a larger number of questions

correctly if I had ___________.

Number

Total

_________

Copyright IBM Corp. 2002

Project Quality Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

5-31

Lecture # 17
PRM 702
Project Risk Management
Ghazala Amin

Project Risk Management

Risk management should be a systematic
process to identify, analyze, treat and
monitor all possible risks.
There are many different descriptions of
this systematic process, but they all have
these fundamental steps:
1. Identify
2. Analyze/Assess
3. Plan
4. Track & control

Risk Definition
Project Risk:
An uncertain event or condition that, if it
occurs, has a positive or a negative effect on
a project objective.
It includes both threats to the project
objectives and opportunities to improve on
those objectives.
PMBOK Guide, 2000

Project Risk Management

1. Identify making a list of all possible
risks that could happen.
2. Analyze/Assess give each risk
identified a probability and impact it could
have.
3. Plan create risk management plan.
4. Track & control continuously monitor
the risk and respond when it actually
happens.

Risk Management Processes

Risk Management Planning
Risk Identification
Qualitative Risk Analysis
Quantitative Risk Analysis
Risk Response Planning
Risk Monitoring and Control
Guide to the Project Management Body of Knowledge, 2000

Risk Management Plan

The risk Management Plan describes:
the process which will be used to identify, analyze and
manage risks both initially and throughout the life of the
project;
how often risks will be reviewed, the process for review
and who will be involved;
who will be responsible for which aspects of risk
management;
how Risk Status will be reported and to whom; and
the initial snapshot of the major risks, current grading,
planned strategies for reducing occurrence and Severity
of each risk (mitigation strategies) and who will be
responsible for implementing them

Risk Management Plan

A Risk Management Plan summarizes the
proposed risk management approach for the
project and is usually included as a section in
the business plan.
The Risk Management Plan is dependant
upon the identification of the projects risks,
their criticality, status, strategy and status.

Table. Topics Addressed in a Risk

Management Plan
Methodology
Roles and responsibilities
Budget and schedule
Risk categories
Risk probability and impact
Risk documentation
8

Risk Management Plan Contents

1.0 Introduction
1.1 Scope and purpose of document
1.2 Overview of major risks
1.3 Responsibilities
2.0 Project Risk Table
2.1 Risk Identification
2.2 Description of all risks above cutoff
2.3 Factors influencing probability and impact
3.0 Risk mitigation, monitoring and management
3.1 Risk item #n
1.
Mitigation
2.
Monitoring
3.
Management
4.0 RM Plan Iteration Schedule
5.0 Summary

Risk Identification-Category
Category is the risk category based on:

Product size (PS)

Business impact (BU)

Customer characteristics (CU)

Process definition (PR)

Development environment (DE)

Technology (TE)

Staff size and experience (ST)

Risk Identification
Typical Risk Categories
deliverable, project management,
organizational, external
schedule, cost, quality, scope
management, external, technology
high, medium, low
technical, market

Risk Identification-I & L or P

Impact (I) indicates the likely effect on the
project and the resulting product:

catastrophic (show-stopper) 1

critical (delay, extra cost) 2

marginal (extra effort) 3

negligible (internal effort) 4

Probability is the current estimate of the
likelihood of occurrence

Risk Identification-Risk Register

While the risk register will become the comprehensive
output, Risk Identification process results in four entries in
the Risk Register:

The Risk Register illustrates all identified

risks, including description, category, cause,
probability of occurring, impact(s) on
objectives, proposed responses, owners,
and current status.

1. Lists of identified risks Identified Risks with their root

causes and risk assumptions are listed.
2. List of potential responses Potential responses
identified here will serve as inputs to the Risk Response
Planning process.
3. Root causes of risk - Root causes of risk are
fundamental conditions which cause the identified risk.
4. Updated risk categories - The process of identifying
risks can lead to new risk categories being added.

Calculating severity

Table. Sample Risk Register

Risk

Description

Late delivery of hardware

Communication and Networks

problem

Project severity = expectation (1-10) * impact (1-10)

When should risk analysis be formed?
Is not a time activity
Periodic update and reviewed

Expectation
6
5
5

Impact
5
8
5

Severity
30
40
25

Project severity = expectation (1-10) * impact (1-10)

Risk Breakdown Structure

(RBS)
A source-oriented grouping of project
risks that organizes and defines the
total risk exposure of the project. Each
descending level represents an
increasingly detailed definition of
sources of risk to the project.
Dr. David Hillson, The Risk Breakdown Structure as an Aid to Effective
Risk Management, PMI Europe, 2002

Risk Identification Guidelines

Assemble SME s (Subject Matter
Experts)
Identify endemic risks
Create an environment that
encourages honest discussion

Risk Breakdown Structure

(RBS)
provides organization and structure
helps identify blind spots
facilitates understanding of types of risks
and risk sources
indicates correlation of risks
allows for generic risk management plans to
address multiple risks
allows cross-project (portfolio) risk
management
allows project ranking on basis of risk

Risk Assessment Guidelines

Use descriptors for Probability and Impact
Qualitative Risk Assessment is useful when
you do not have accurate numbers for
Impact and Probability
Analysis is often unconscious rationalization
of decisions
already made
Risk Scatter Diagram communicates the
general risk profile for a project or phase
Decision Trees can assess multiple
probabilities

Risk Management Tools

Risk Identification

RBS

Risk Map
Risk Assessment

Qualification model

Decision Tree Analysis

Monte Carlo Analysis

Risk Communication

Monte Carlo histograms

RBS, Risk Map, Risk Scatter Diagram

Critical Path Analysis, Sensitivity Analysis

Spring 2007

MST 512

Project Management

Risk Management
Organizations have been practicing risk assessment and risk management since the 17th
century, and since the beginning of recorded history, gambling the very essence of risk-taking
has been a popular pastime and often an addition (Bernstein 1998). Yet, most companies do
not formalize their risk management plan. Risk management should be a systematic process to
identify, analyze, treat and monitor all possible risks. There are many different descriptions of
this systematic process, but they all have these fundamental steps:
1. Identify making a list of all possible risks that could happen.
2. Analyze/Assess give each risk identified a probability and impact it could have.
3. Plan create risk management plan.
4. Track & control continuously monitor the risk and respond when it actually happens.
Identify
There are many commonly used techniques for risk identification.

Such as

documentation review, information-gathering techniques (brainstorming, Delphi technique,

interviewing, SWOT), checklists, assumptions analysis, and diagramming techniques (causeand-effect diagrams, process flow charts, influence diagrams) (PMBOK 2000).

These

techniques will produce a long list of risks that will have to be processed. This unorganized
laundry list of risks does not provide the big picture view of the project risks.
The Risk Breakdown Structure (RBS) is similar to the Work Breakdown Structure
(WBS) commonly used in estimating the work required to get a project done. Its a top-down
breakdown of the risks faced by a project. A RBS is a source-oriented grouping of project risks
that organizes and defines the total risk exposure of the project.

Each descending level

represents an increasingly detailed definition of sources of risk to the project (Hillson 2002).
Just as in WBS where we have a big picture of work needed but can also dig down to see the
details of each item, RBS does exactly the same thing for risk identification. This creates a more
organized list of risks to aid in their comprehension and interpretation (see Figure 1). Since not
all projects are the same, organizations wanting to use the RBS should develop their own
specialized RBS, either one generic one covering all the projects or specialized ones depending
on the project types.

Page 1 of 5

D. Kurniawan

Spring 2007

MST 512

Project Management

RBS is used in risk identification phase, brainstorming process where project members
try to identify all the risks at the first and second levels of the RBS. Once this is done, you can
convert it to a risk checklist by taking the lowest level risks of the RBS this is equivalent with
the risk list that you would gather if you used the previously mentioned common techniques.
Working in reverse, you could also take a risk list gathered by other methods, and put it in the
RBS structure. This could reveal some holes or duplications in your original risk list.
By using the RBS structure when identifying risks, it will give you perspective of where
are the risks coming from, concentrated at, and also dependencies between risks.

This

information should help in focusing risk response efforts in the high risk areas.

Figure 1 Sample of RBS (Hillson 2002)

Page 2 of 5

D. Kurniawan

Spring 2007

MST 512

Project Management

Analyze
To identify the risk concentration areas, the number of risks identified is not enough of an
indicator. There could be a lot of minor risks in one area that is still not as important as a single
major risk that could halt the project entirely. A common method of giving a risk score to
each risk is the Probability Impact scoring. Each risk identified in the previous step is assessed
by giving it a probability of it happening and the amount of impact to the project. A ProbabilityImpact Matrix (see Figure 2) should be used to help you prioritize the risks and spend the
appropriate amount of time depending on the severity of the risk.

Figure 2 Probability-Impact Matrix (Stout 2003)

At first glance, one might think that all risks are random, but the reality is, there are
random and non-random (learnable) risks. Random risks are risks that no matter how much you
try, you wont be able to gain any more insight of that risk. The free market is an example of
random risk no one can consistently predict where the stock market will go. Non-random risks
are risks that can be learned or understood to reduce its uncertainty. One novel idea is the
concept of Risk Intelligence (Apgar 2006) its the measure of our ability compared to
competitors to assess the risk.

Page 3 of 5

D. Kurniawan

Spring 2007

MST 512

Project Management

These are the 4 rules of risk intelligence:

1. Recognize which risks are learnable dont waste your time on random risks.
2. Identify risks you can learn about fastest this is how you get an edge over competition.
3. Sequence risky projects in a learning pipeline dont try to take on too many risks you
need to learn, but keep yourself challenged by trying to learn new risks too.
4. Keep networks of partners to manage all risks distribute risk to whoever can best
absorb it.
We need to realize what were good at, and what were not-so-good at to be able to apply our
efforts more efficiently.
Plan
A plan needs to be developed for each of the high risks, some of the medium risks and
keep an eye out for the low risks.
There are 5 classic strategies that can be done for each negative risk:
1. Avoid change the project plan to avoid the risk (ex: risk of earth quake in California,
move plant to Kansas).
2. Transfer transfer the threat to another party, usually involving a fee (ex: hiring
consultant/insurance premium).
3. Mitigate take positive action to reduce the risk (ex: train a second person as backup).
4. Accept dont do anything to prevent it, accept the consequences when it happens.
5. Monitor design a fallback plan when risk happens.
Less talked about are positive risks (opportunities). A plan should be developed for capturing
these opportunities too (Elyse 2007):
1. Share the responsibility and accountability to seize the opportunity.
2. Enhance the chances by focusing on the trigger conditions.
3. Exploit the opportunity by assuring youll get it (ie. Hiring expert).
Track & Control
Once the plan is in place, we need to constantly monitor the situation to see if any of the
risk came true. If it does, respond to it with the plan of action determined earlier. Keep
monitoring the risk and keep track of the progress with a risk log. Risk management is a
systematic process because its a continuous task (see Figure 3) that runs throughout the lifetime

Page 4 of 5

D. Kurniawan

Spring 2007

MST 512

Project Management

of the project. As you reach big milestones within the project, plan to repeat these four steps
again. Situations changed that might introduce new risks and eliminate ones weve prepared for.
To be successful, risks needs to be managed proactively.

Figure 3 Continuous process (Rosenberg et. al. 1999)

As risks occur or not, the risk plan needs to be updated; a risk database should be kept
and risk checklists should be updated for future projects.

The key to a successful risk

management plan is to continuously go through the process throughout the life of your project.

References
Apgar, David. Risk Intelligence: learning to manage what we don't know. Boston: Harvard
Business School Publishing, 2006.
Bernstein, Peter. Against the gods: The remarkable story of risk. Canada: John Wiley & Sons,
1998.
Elyse. Risk Response Planning. http://www.anticlue.net/archives/000820.htm. Anticlue, 2007.
Hillson, David. Using a Risk Breakdown Structure (RBS) to Understand Your Risks.
Proceedings of the Project Management Institute Annual Seminars & Symposium, Oct. 2002.
Project Management Institute. A Guide to the Project Management Body of Knowledge
(PMBOK Guide), 2000 Edition. Newton Square: Project Management Institute, 2000.
Rosenberg, L., Hammer, T. and Gallo, R. Continuous Risk Management at NASA. Applied
Software Measurement conference, 1999.
Stout, Pen. Increase Your Rewards: Guidelines for Project Risk Management Part III. CHIPS
magazine, Fall 2003.
Thomsett, Rob. Radical project management. Upper Saddle River: Prentice Hall PTR, 2002.
Verzuh, Eric. The Fast Forward MBA in Project Management. Hoboken: John Wiley & Sons,
2005.
Wikipedia, "Risk Management," Wikipedia, http://en.wikipedia.org/wiki/Risk_management

Page 5 of 5

D. Kurniawan

MBT Step 7 Risk Management

Developing a Risk Management Plan
There will always be risks associated with projects resulting from the architecture
analysis or Modernization Blueprint. The purpose of risk management is to ensure levels
of risk and uncertainty are properly managed so that the project is successfully
completed. It enables those involved to identify possible risks, the manner in which they
can be contained and the likely cost of countermeasures.
What is a Risk Management Plan?
A Risk Management Plan summarizes the proposed risk management approach for the
project and is usually included as a section in the business plan. The Risk Management
Plan is dependant upon the identification of the projects risks, their criticality, status,
strategy and status. The risk Management Plan describes:

the process which will be used to identify, analyze and manage risks both initially
and throughout the life of the project;

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

who will be responsible for which aspects of risk management;

how Risk Status will be reported and to whom; and

the initial snapshot of the major risks, current grading, planned strategies for
reducing occurrence and Severity of each risk (mitigation strategies) and who will
be responsible for implementing them

What is a Risk Management Table?

The Risk Management Table is derived from the Exhibit 300 Capital Planning guidance
to ensure the project will conform with the required information to generate quality
capital planning documents. The Risk Management Table records the details of all the
risks identified at the beginning and during the life of the project, their grading in terms
of occurrence of occurring and Severity of impact on the project, initial plans for
mitigating each high level risk and subsequent results.
It usually includes:

a unique identifier for each risk;

a description of each risk and how it will affect the project;

an assessment of the occurrence it will occur and the possible Severity/impact if it

does occur (low, medium, high);

a grading of each risk according to a risk assessment table

who is responsible for managing the risk; and

an outline of proposed mitigation actions (preventative and contingency.

This Register should be kept throughout the project, and will change regularly as existing
risks are re-graded in the light of the effectiveness of the mitigation strategy and new
risks are identified. In smaller projects the Risk Management Table is often used as the
Risk Management Plan.
Why would you develop a Risk Management Plan and Risk Management Table?
A Risk Management Plan and Risk Management Table are developed to:

provide a useful tool for managing and reducing the risks identified before and
during the project;

document risk mitigation strategies being pursued in response to the identified

risks and their grading in terms of occurrence and Severity;

provide the Executive Sponsor, Steering Committee/senior management with a

documented framework from which risk status can be reported upon;

ensure the communication of risk management issues to key stakeholders;

provide a mechanism for seeking and acting on feedback to encourage the

involvement of the key stakeholders; and

identify the mitigation actions required for implementation.

When would you develop a Risk Management Plan?

Initial risks must be identified and graded according to occurrence and Severity very
early in the project. The risks will need to be communicated to the CMIT and the
executive sponsors of the implementation. Once the project is approved the Risk
Management Plan and Risk Management Table should be fully developed. In the case of
smaller projects the Risk Management Table may serve both purposes.
What you need before you start:

Knowledge and understanding of the project. (Blueprint Recommendations)

Knowledge and understanding of the Key Stakeholders. (From MBT Step 2)

Knowledge and understanding of appropriate types of risk management activities,

or where to obtain them.

Other MBT supporting documentation from IRB, and the Blueprint Development
team (CMBT)

Optional:

Departmental Project Management Guidelines. (Note: This document has cross

referenced the DOI Capital Planning Guide and the E-CPIC Exhibit 300 formats
to ensure that the minimum requirements will be satisfied.)

How do you develop a Risk Management Plan?

The following is one way to develop your plan. It consists of a series of steps that become
iterative throughout the life of your project. Firstly:
Step 1: Identify the risks
Before risks can be properly managed, they need to be identified. One useful way of
doing this is defining categories under which risks might be identified. For example,
categories might include Corporate Risks, Business Risks, Project Risks and System
Risks. These can be broken down even further into categories such as environmental,
economic, human, etc. Another way is to categorize in terms of risks external to the
project and those that are internal.
For a medium to large project, start by conducting a number of meetings or brainstorming
sessions involving (as a minimum) the Project Manager, Project Team members, Steering
Committee members, external key stakeholders. It is often advisable to use an outside
facilitator for this. Preparation may include an environmental scan, seeking views of key
stakeholders etc. One of the most difficult things is ensuring that all major risks are
identified. For a small project, the Project Manager may develop the Risk Management
Table perhaps with input from the Executive Sponsor/Senior Manager and colleagues, or
a small group of key stakeholders.
The results of this exercise should be documented in a Risk Management Table for the
project. For larger projects, if an outside facilitator is used, it would be expected that they
would develop the initial documentation.
Step 2: Analyze and evaluate the Risks
Once you have identified your risks you should analyze them by determining how they
might affect the success of your project.
Risks can result in four types of consequences:

benefits are delayed or reduced;

timeframes are extended;

outlays are advanced or increased; and/or

output quality (fitness for purpose) is reduced.

Risks should be analyzed and evaluated in terms of occurrence of occurring and Severity
of impact if they do occur. Firstly, assess the occurrence of the risk occurring and give
this a rating of Low (L), Medium (M) or High (H) occurrence. Once you have rated the
occurrence, assess the Severity of the impact of the risk if it did occur and rate at Low
(L), Medium (M) or High (H) Severity.
Using your ratings for occurrence and Severity you can then determine a current grading
for each risk that in turn provides a measure of the project risk exposure at the time of the
evaluation.
Table 1 provides a standard method for calculating a grading for each risk based upon the
combination of the occurrence and Severity ratings.
Severity
Occurrence

low

medium

high

low

medium

high

Table 1: Risk matrix for grading risks

So what this means in practice is:
Identifier Description of Risk

Occurrence

Severity

Grade

Status

1.1

Inadequate funding to
complete the project

medium

INCREASING

1.2

Lack of technical skills

in Client Business Unit

high

NEW

Key:
Change to Grade since last assessment

NEW New risk

Grading decreased

No change to Grade

Grading increased

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 Severity.
Severity
low

medium

high

EXTREME

low

medium

high

Occurrence

Depending upon the size and nature of the project, some choose to use numerical scales
for this analysis and evaluation.
The resulting grades of risk help the project team to focus on treating the most important
risks, once evaluated and prioritized, and to mitigate them before the project progresses
much further into the MANAGE Phase.
Step 3: How will you manage or 'treat' the Risks?
Using the Grading Table in Step 3, for your entire Grade A and B risks and those rated
Extreme it is really important to have identified mitigation strategies very early in your
project. Risk mitigation strategies reduce the chance that a risk will be realized
and/or reduce the Severity of a risk if it is realized. Grade C Risks should be
continually monitored and have planned mitigation strategies ready to be implemented if
appropriate. These plans need to be recorded on your Risk Management Table.
There are three broad types of risk mitigation strategies:

Avoidthespecificthreat,usuallybyeliminatingthecause.(e.g.;conductastudyor
developaprototype)

Mitigatethespecificthreatbyreducingtheexpectedmonetaryorscheduleimpactof
therisk,orbyreducingtheprobabilityofitsoccurrence.

Manage(accept)theconsequencesoftherisk.

Once a risk has occurred, recovery actions to allow you to move on should be built into
the WBS for your project. In other words, what should you do when?
For each action in the Risk Management Table, it is necessary to specify:

Who will be responsible for implementing each action?

When the action must be implemented?

What are the costs associated with each action (for larger projects in particular)?

Your Risk Management Table may now look something like this:
Id Description
of Risk

L S G Change Date

1.1 Inadequate
funding to
complete the
project

M M C

1.2 Lack of
H H A NEW
technical skills
in Client
Business Unit

Action
Re-scope project
focusing on time
and resourcing
Develop training
plan

Who
PM

Cost WBS
$$$

Consultant $$$

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.

Step 4: Monitor and review risks

The Risk Management Table should be visited fortnightly with re-evaluation of the risks
occurring on a monthly basis. If your prevention strategies are being effective, some of
your Grade A and B Risks should be able to be downgraded fairly soon into the project.
Risk Status should be reported to the Steering Committee or Executive Sponsor/Senior
Manager on an agreed regular basis and form part of the Project Status reporting
processes.
Remember - Risk Management is an iterative process that should be built into the
management processes for your project. It is closely linked with your Issues Management
processes, as untreated issues may become significant risks.
Also remember: Communicate and Consult
Even though you may have done this really well at the beginning and involved your key
stakeholders in the identification, analysis and evaluation of risks, it is important to
remember to keep the communication going. The communication strategy for your
project should build this into the activities.
Who is responsible?
Many people involved in a project will have some responsibility for project risk
management, including the project team members, Steering Committee, Executive

Sponsor, potential business owners and working groups. It is important that they know
what they are watching out for, and reporting potential risks is a significant part of their
role.
The Project Manager is responsible for monitoring and managing all aspects of the risk
management process, such as:

the development of the Risk Management Plan and n Risk Management Plan

the continual monitoring of the project to identify any new or changing risks;

continual monitoring of the effectiveness of the risk management strategies; and

regular reports to the Executive Sponsor and Steering Committee.

In large 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.
Who has ultimate accountability?
While the Project Manager is responsible for the management of risks, the Executive
Sponsor/Senior Manager has ultimate responsibility to ensure that an effective Risk
Management Plan for the project is in place.
Who approves the Risk Management Plan?
Generally, the Risk Management Plan would be approved or endorsed by the Steering
Committee/Executive Sponsor or Senior Manager, depending upon the size of the
project.
Once the Risk Management Plan has been approved, it is important to:

add the actions into the Project Plan with the appropriately assigned resource(s);
and

add the costs for the actions into the Project Budget.

Reference: http://www.projectmanagement.tas.gov.au/ - Risk Management Plan (fsv1.0)

OAKS Risk Management Plan

Prepared

for

The State of Ohio

OAKS Project
Prepared By

Accenture

September 26, 2005

This page intentionally left blank

Document Information
Edition Information:

Type of Document:

Project Plan Risk

Status of Document:

Final

Effective Date:

9/26/2005

Document File Name:

Title of Document:

PM129 OAKS Risk Management

Plan.doc
In BI Designer at:
OAKS\Cabinets\Project
Management\Working
Deliverables\Deliverable 9
OAKS Risk Management Plan

Program Name:

OAKS

Originator:

Andrew W. Gordon

Document File
Location:
Document Control:

Contact Information: Author:

Andrew W. Gordon

Phone:

614-387-3001

E-mail Address:

[email protected]

Record of Review and Changes

Person
Andrew Gordon
Andrew Gordon
Andrew Gordon

Date
Version
8/5/2005
1.0
9/9/2005
1.1
9/22/2005 1.2

Description of Change
Document Created
Incorporated updates from Shirley Whaley
Incorporated updates resulting from official state
review

Embedded Deliverable Tracking Form:

1. Keep this embedded form updated as the deliverable winds its way through the
deliverable process.
2. This form is to be updated every time this deliverable is submitted for a review (peer
review, management review, quality team lead review, etc.)
3. To update this form, double click on the embedded file below, make your updates, click
the save button, then close the file.

"Document
Deliverable Tracking

Table of Contents
1

INTRODUCTION ...................................................................................................................1
1.1
1.2
1.3
1.4
1.5
1.6
1.7

PROCESS RESPONSIBILITY ROLES AND RESPONSIBILITIES...................................2

2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10

DOCUMENT OVERVIEW .....................................................................................................1

SCOPE .............................................................................................................................1
OBJECTIVES .....................................................................................................................1
GUIDING PRINCIPLES ........................................................................................................2
RESPONSIBILITY FOR THE PLAN ........................................................................................2
PLAN AND/OR PROCESS DEPENDENCIES ...........................................................................2
REFERENCED DOCUMENTS...............................................................................................2
RISK MANAGER/DATABASE ADMINISTRATOR .....................................................................3
RISK ORIGINATOR ............................................................................................................3
RISK OWNER ....................................................................................................................4
RISK POINT OF CONTACT ..................................................................................................4
PROJECT TEAM LEADS .....................................................................................................4
EXECUTIVE PROGRAM MANAGERS ....................................................................................5
OAKS PROJECT TEAM MEMBERS .....................................................................................5
BUSINESS AND TECHNICAL ADVISORY GROUP ...................................................................5
OAKS PROGRAM MANAGEMENT OFFICE (PMO) ...............................................................6
RISK MANAGEMENT WORKING GROUP ..............................................................................6

RISK MANAGEMENT PROCESS ........................................................................................7

3.1
RISK MANAGEMENT OVERVIEW .........................................................................................9
3.1.1
Risk Initial Planning and Identification .....................................................................9
3.1.2
Continual Risk Identification ..................................................................................10
3.1.3
Risk Assessment and Categorization of Risks ......................................................11
3.1.4
Risk Data...............................................................................................................12
3.1.5
Process Steps .......................................................................................................16
3.2
RISK ESCALATION PROCEDURES ....................................................................................24
3.3
RISK MANAGEMENT WORKING GROUP MEETINGS (QUARTERLY OR AS NEEDED) ..............24
3.4
RISK MEETING AND REPORTING PROCESSES (WEEKLY AND DAILY) .................................25
3.5
RISK MEETING REPORT ..................................................................................................26
3.6
RISK MAILING LIST .........................................................................................................26

RISK MANAGEMENT TOOL ..............................................................................................26

4.1
4.2
4.3
4.4

RISK SECTION OF BI DESIGNER AVAILABLE TO ALL OAKS TEAM MEMBERS .....................26

USING THE RISK ENTRY FORM TO CREATE NEW RISKS ...................................................26
VIEWING RISKS ..............................................................................................................27
UPDATING RISKS ............................................................................................................27

OAKS RISK MANAGEMENT METRICS ............................................................................27

RISK IDENTIFICATION QUESTIONNAIRE .......................................................................27

Table of Figures

Figure 1 - Risk Management Overview.........................................................................................3

Figure 2 - Risk Management Process...........................................................................................7
Figure 3 - Risk Assessment Color Matrix......................................................................................8
Figure 4 - Risk Initial Evaluation and Planning .............................................................................9
Figure 5 - Risk Rating .................................................................................................................17
Figure 6 - Risk Response and Control........................................................................................20
Figure 7 - Risk Mitigation Approval Matrixes ..............................................................................22

Table of Tables
Table 1 - Risk Data Captured in Risk Management Tool............................................................12
Table 2 - Standard Risk Notices and Reports.............................................................................25

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

1 Introduction
1.1

Document Overview

The OAKS Risk Management Plan (RMP) is a living document providing the OAKS Program a
method for managing risks to ensure program success. A risk is defined as any concern that
could impact the ability of the OAKS Program to meet its schedule, and cost objectives. Risk
has two components:

The probability of failing to achieve a particular outcome

The consequences of failing to meet that outcome

Risks are measured in terms of severity as determined by probability of occurring and affecting
the program. Unlike issues (which are problems involving a significant choice between two or
more alternative for an event that is happening now), risks relate to events that could occur and
may affect the programs schedule, or cost objectives.
The risk management process will enable the OAKS Program to create strategies that
effectively address potential barriers to program success. The risk management process
involves identifying, assessing, mitigating, and managing the program's risks. Actions taken to
address risk may lead to decisions that affect reporting or the development of the business
capability or affect the management of the program. The RMP serves as a guide to all team
members in managing program-wide and Integrated Project Team (IPT)-level risks.

1.2

Scope

Risk management is executed at all levels within the program and IPT. The risk management
process ensures that risks are mitigated at the appropriate level and communicated as
appropriate. This plan provides guidance on managing all levels of risks. These processes are
implemented within the individual teams and IPTs that comprise the program.

1.3

Objectives

Successful management of the OAKS Program requires informed, proactive, and timely
management of risks. The specific objectives of the OAKS RMP and approach are listed below:

Ensure critical risks impacting schedule, cost, and/or performance are identified to
communicate, escalate, and mitigate risks in a timely manner.
Ensure the probability and impact of risks is reduced to an acceptable level through an
effective mitigation process.
Focus attention on key risks affecting the program versus individual teams or IPTs.
Provide risk information for milestone decisions.
Produce meaningful information that allows program management to focus efforts on the
right risks (e.g., very high and high probability or impact) with an effective coordination
of effort to mitigate the risk.
Ensure that appropriate stakeholders are informed and, if applicable, participate in the
mitigation.

Page 1 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

1.4

Transforming the Way Ohio Does Business

Ensure that the stakeholders understand the implication of accepting certain risks and
are comfortable with accepting these risks.
Provide an audit trail of discussions and mitigation of program risks.

Guiding Principles

To be successful, the principles listed below guide the use and implementation of the risk
management process:

1.5

The risk management process emphasis will be placed on effectiveness and simplicity.
A single owner will be assigned responsibility for each risk even if several people work to
mitigate it.
Effort and communication will be focused on the most severe risks.
Realistic due dates for mitigation steps will be set to meet these dates.
Risks will be mitigated at the appropriate organizational level (e.g., program, IPT).
Risk owners will evaluate the initial risk severity and impact levels of risks they are
assigned.
Planned risk mitigation history and actual mitigation of each risk will be documented.
This documentation can serve as key input to root cause analysis, key learning, metrics,
and risk analysis.

Responsibility For the Plan

The RMP was prepared by the OAKS Risk Management Leads, who are also responsible for
updating it with any significant changes, and making sure that all project members adhere to all
risk management processes. The risk management plan will be updated at least once per
quarter and submitted to the client for reviews at that time.

1.6

Plan and/or Process Dependencies

The information contained in the OAKS Risk Management Plan both affects, and is affected by
the following project plans and processes.

1.7

Project Plans (OAKS Work Plan)

WBS
Project Measurement Plan

Referenced Documents

OAKS Quality Management Plan

OAKS Risk Owners Guide

2 Process Responsibility Roles and Responsibilities

An overview of the risk management process is depicted in figure 1. Key roles and
responsibilities are then defined in the following sections.
Page 2 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS
Identify
Risks

Validate
Risks

Assign
Risks

Mitigate
Risks

Manage
Risks

Figure 1 - Risk Management Overview

2.1

Risk Manager/Database Administrator

To maintain the integrity of the risk database, the risk database administrator will be responsible
for entering and updating data into the database, as well as doing regular maintenance to the
Risk Management tool. Regular maintenance includes:

Updating field values as they become available

Ranking the risks on a regular basis
Validate that risk mitigation steps include the corresponding decrease to probability
and/or impact
Report when required contingency plans are missing
Report when risk milestones are not entered into the OAKS Work Breakdown Structure
(WBS)
Validate that risks have been closed in accordance with risk closure guidelines

These individuals are also responsible for creating reports for the team lead project status
meetings, setting schedules for the Risk Management (RM) Working Group meetings, and
producing custom reports as required. The Risk Database Administrators are Shirley Whaley
([email protected]) and Andrew Gordon ([email protected]).
The risk managers are also responsible for:

2.2

Writing and maintaining the Risk Management Plan

Defining and implementing the risk management process
Train all OAKS team members on the risk management process
Maintain and update the risk section of the BI Designer web page
Hold quarterly (or as needed) risk working group workshops

Risk Originator

The Risk Originator is any person in the OAKS Program who identifies an OAKS Program risk.
The Risk Originator will submit the risk to his or her risk administrator by filling out the new risk
entry form located on the risk section of the BI Designer website (OAKS\Cabinets\Project
Management\Risk Management\Risk Job Aids\OAKS Risk Entry Form.xls). Members of the
following groups may recommend new risks:

OAKS PMO
OAKS State Team Members
OAKS Contractor Team Members (Lead contractor and subs)

Specific responsibilities of the risk originator include the following:

Page 3 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

2.3

Transforming the Way Ohio Does Business

Identify any significant risk to the OAKS Program

Enter the risk, including initial severity assessment, into the risk entry form
Clarify risk information for the Risk Management (RM) Working Group, as requested
After initial risk entry, communicate significant newly discovered information regarding
the risk to the RM Working Group or Project Team Leads, as necessary

Risk Owner

The Risk Owner is the person to whom the responsibility for mitigating the risk is assigned. Risk
Owners should be the people who will be most affected if the risk occurs (becomes realized).
The Risk Owner has the following responsibilities:

2.4

Create a risk mitigation plan, as required and a contingency plan, as directed, in the
event the risk occurs
Update risk information, as necessary
Ensure the risk is being mitigated
Execute the Contingency Plan, as required
Recommend risk closure to the appropriate group
Present risk status as required

Risk Point of Contact

A Risk POC has responsibility for answering risk-related questions his or her team members
may have about the Risk Management Process, along with compiling recommendations for the
risk management working group meetings. The OAKS POCs are as follows:

2.5

OAKS State Risk Manager Shirley Whaley

OAKS Accenture Risk Manager Andrew Gordon

Project Team Leads

The Project Team Leads have overall responsibility for the risk management process. Each
Project Team Lead will be responsible for all risks that fall within his or her release. Basic
responsibilities of Project Team Leads include:

Discuss risk status during weekly project status meetings

Ensuring no risk mitigation steps are past due
Validating new risks
Establishing initial priority, owner, and target due dates
Approving initial risk mitigation plans
Reviewing and updating Risk Owners, as necessary
Approving risk mitigation plan updates
Reviewing probability, impact, impact date, and completeness of risks, as necessary
Approving changes on impact date, new probability, new impact, etc.
Retiring risks
Reviewing status of risks

Page 4 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

2.6

Transforming the Way Ohio Does Business

Re-opening retired risks

Ensuring contingency plans are executed for appropriate realized risks
Ensure that Risk Owners update their risk information prior to Risk Workshops
Identifying risks for escalation to the OAKS Executive Leadership (EL).
Note: Risks that get escalated to the EL are risks that are categorized as Very High risks
and have major problems that the Project Team Leads, RM Working Group, and OAKS
management are not capable of resolving; these risks can include:
o Problems that involve outside parties essential to the problem and/or solution
o Risks where the solution requires significant changes to baseline costs and/or
schedule
Ensuring all risks that fall within their Release are being managed
Representing their Release and ensure that key risk owners attend Risk Working Group
Meetings
Working with Integrated Project Teams (IPTs), subject matter experts, and EL to mitigate
risks

Executive Program Managers

The executive program managers are also referred to as the Executive Leadership (EL) and
include:

OAKS Executive Program Manager

OAKS Deputy Program Manager
Accenture Program Manager
Accenture Deputy Program Manager

The responsibilities of the OAKS EL in the risk management process include the following:

2.7

Assisting in cross-organization and controversial risk mitigation

Supporting mitigation implementation as necessary

OAKS Project Team Members

The OAKS project team members have been assigned to the OAKS project on a full time basis
and responsibilities would include the following:

2.8

Perform any risk management tasks as assigned by the Team Leads

Identify risks in a facilitated risk evaluation, as assigned by Team Leads
Identify new risks to the Team Leads, as soon as each risk is perceived
Review the Risk Management Plan for correctness and adequacy, as well as, provide
feedback for improvement

Business and Technical Advisory Group

The Business and Technical Advisory Group members include EL, project managers, team
leads, IPT leads, and part time module business owners, and responsibilities would include the
following:
Page 5 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

2.9

Transforming the Way Ohio Does Business

Maintain awareness of risks and their potential impact

Provide assistance and support to the Team Leads
Identify risks & their impacts

OAKS Program Management Office (PMO)

Risks will be communicated to the PMO through the weekly status meeting. Slides will be
created that identify new risks, summarize red risks, and summarize all risks (by color). The
OAKS PMO responsibilities in the risk management process include the following:

Assisting in cross-organization and controversial risk mitigation

Supporting mitigation implementation as necessary
Identifying risks for escalation to the Business Owners Advisory (BOA) Group

2.10 Risk Management Working Group

The RM Working Groups schedule will be dependent on the Program Management review of
the OAKS Program or on an as-needed basis. The Group should meet quarterly (or as needed)
and its goal is to bring together all people who are involved in the risk process and discuss
strategy, evaluate existing risks, and create new risks. Basic responsibilities of the RM Working
Group include:

Beginning risk identification by holding initial Risk Brainstorming session.

Acting as liaison to stakeholder groups regarding:
Risk Identification
Risk Analysis
Assigning Risk Mitigation and Contingency Planning Actions
Monitoring status of assigned actions
Communicating status to risk originators, risk owners, and risk stakeholders
Identifying new risks
Reopening retired risks
Establishing severity of risks and define target dates
Establishing owner of risk and confirm target dates
Reviewing status, severity, owner, and completeness of risks
Approving changes on impact date, new probability, new impact, etc.
Identifying risks for escalation to the EL
Note: Risks that get escalated to the EL are risks that are categorized as Very High risks
and have major problems which the Project Team Leads, RM Working Group, and
OAKS management are not capable of resolving; these risks can include:
o Problems that involve outside parties which are essential to the problem and/or
solution
o Risks where the solution requires significant changes to baseline costs and/or
schedule
o Working with IPTs, subject matter experts, and EL to facilitate solutions to risks.

Recommended members of the RM Working Group includes:

OAKS Risk Managers
Page 6 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS

Risk Originator, as required

Risk Owner, as required

3 Risk Management Process

This section describes the risk management process from risk identification to risk completion.
The risk management process is a continuous cycle performed initially during program planning
and thereafter following identification of new risks. New risks may arise from a variety of
sources:

Risks previously missed or unforeseen

Risks arising from an approved change request, where cost, schedule, or scope may be
amended, impacting the critical path
Risks arising from major issues
Risks arising from the investigation of current risks
Risks arising from the outcome or consequence of a separate risk occurrence

Figure 2 depicts the high level risk management process steps in direct relation to the risk
management overview shown in Figure 1. Subsequent sections detail each process step,
describe the data elements tracked for each risk, the escalation procedure, the current RM
Working Group meeting schedule, and an overview of the feedback and reporting process is
provided.

No
High Medium
Im
pa
Low
ct Medium
Low Very Low
Low

High

Very High

Medium

High

Low

Medium

High

Risk
Mitigated?

Yes

Risk
Retired
(Reporting)

Execute Response
Actions (Mitigation and
Reporting)

Probability

Identified Risk
(Planning/
Identification)

Determine Risk
Category and Risk
Level (Assessment)

Risk
Yes
Level Medium
or High?

Develop
Mitigating Actions
(Analysis)

No
Risk Put on Watch
List (Reporting)

Figure 2 - Risk Management Process

Difference Between Risks and Issues

An Issue refers to a problem involving a significant choice between two or more alternatives for
an event that is happening now. Risk describes situations that could occur. If it does occur, it
would have a significant impact on the project. Issues are handled separately. For information
on issue management, please refer to the Issues Management Plan. The two major variables
used in classifying a risk are 1) probability of the risk occurring and 2) the impact or
Page 7 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS

consequence if that risk occurs. The two variables are combined to assess the risk as shown in
Figure 2.

Impact
5 Very High
3

4 High
2

3 Medium

2 Low
1 Very Low

Very Low Low

Medium
High Very High
0 20% 21 40% 41 60% 61 80%81 100%
Probability

Figure 3 - Risk Assessment Color Matrix

Risks that fall into area 1 (green) can be categorized as Low and should be monitored. Risks
that fall into area 2 (yellow) can be categorized, as Medium and a mitigation plan should be
prepared for implementation in case the risk increases in probability or impact. Risks that fall
into area 3 (red) are categorized as High and active steps should be taken to prevent them
(create mitigation and contingency plan).

Page 8 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS

3.1
3.1.1

Risk Management Overview

Risk Initial Planning and Identification

S cope
S tatem ent

S taffing
M anagem ent
P lan

W BS &
A ctivity List

R isk
E valuation &
P lanning
Tem plates

P rocurem ent
P rocess

D eterm ine R isk M anagem ent P rocess for the P roject

Tailor to type &

size of P roject

A ssign Facilitator
for R isk E valuation

D eterm ine
P articipants

R isk S tatus
R eporting

E stim ate R esource

R equirem ents for
E valuation

Identify &
D ocum ent P roject
R isks

R ate R isk by
P robability &
S everity

A ssign O w nership
of R isk

E valuate need
for action plan

P lace R isk in
"w atch" status

Y es
D evelop S trategies
to reduce
P robability &
S everity

C reate A ction P lan

T ailored
P robablity/
O utcom e Table

R isk M anagem ent

P roject P lan

R isk M anagem ent

S um m ary sheet(s)

R isk D atabase

Identified A ction
Item s

Q uality A ssurance
R eview
(see Q uality P lan)

Figure 4 - Risk Initial Evaluation and Planning

Page 9 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

Figure 4 outlines the detailed flow of initial risk evaluation and planning. During the startup of
the Risk Management Process, existing risks must be identified quickly to begin timely
mitigation. Three alternatives to identify existing risks initially are:

Risk Workshops
Risk POCs working within their groups to identify risks
Combination of Risk Workshop and Risk POC Group meetings

The selected approach is the combination.

3.1.1.1 Risk Workshops

A Risk Workshop is a brainstorming session used to identify initial risks. The meeting
participants are the members of the entire RM Working Group and representatives from OAKS
Program stakeholders. RM Working Group members discuss and identify potential and/or
existing risks. At the workshops end, a list is compiled of all the initial risks and then entered
into the Risk Management tool.

3.1.1.2 Risk POC Groups

Another method of first identifying risks is to have both the Risk POCs gather risks from within
their respective teams, consolidate them, and submit them to the RM Working Teams. The Risk
POCs will compile a composite risk list and enter them into the Risk Management tool.

3.1.1.3 Combination: Risk Workshops and Risk POC Groups

All OAKS team members are expected to identify risks and communicate them to their OAKS
Risk POC for both initial and ongoing risks gathering efforts. The representatives of each OAKS
stakeholder group will participate in the Risk gathering workshop. The OAKS RM Working
Group, with program managements approval, will determine and recommend these Teams.
The selected approach to determining initial risks is to have a combination of a Risk Workshop
and Risk POC Group meetings. First, the Risk POCs gather risks from within their own teams.
That list is then consolidated and taken to the Risk Workshop. The POCs then participate in a
one-time Risk Workshop, starting with their Teams consolidated risk lists. During the risk
workshop a final list of risks will be produced and submitted to the Risk Administrator for entry
into the Risk Management tool. With this combination approach, a greater number of people
have input into determining the initial risks. Also, the Risk Workshop is much shorter and much
more efficient.
3.1.2

Continual Risk Identification

Once initial risks are identified, an ongoing process for timely capture and management of risks
will be established in several ways:

The Project Team Leads will hold regular meetings where risks will be constantly
submitted and reviewed.

Page 10 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

3.1.3

Transforming the Way Ohio Does Business

A risk entry form (Excel spreadsheet) will be available for users to enter data. This form
is located on BI Designer at OAKS\Cabinets\Project Management\Risk
Management\Risk Job Aids. The data will be sent via e-mail to the Risk Administrator
where they will then be entered into the Risk Management tool.
Risk Assessment and Categorization of Risks

Risk categorization is achieved by defining characteristic sources of risks. These sources

describe the generic areas where specific risks are likely to occur, and formalize the
categorization initially performed during Risk Management Planning. Risks can be assessed
into five categories: cost, schedule, technological, and external.

3.1.3.1 Cost
Cost-based risks outline the non-achievement of the financial benefits of the project detailed in
the project objectives or key success factors (such as the Cost Performance Index (CPI).
Typical cost risks include external contractor overspend, additional costs in changing/solving
design, or application project problems.

3.1.3.2 Schedule
Schedule-based risks focus on the non-achievement of the project's products or benefits within
the specified time frame. Typical schedule-based risks arise from extensions from scope
changes, resource unavailability, market opportunities missed, and additional schedule
extensions from solving those risks outlined in 'Cost' above.

3.1.3.3 Technological
Technology-based risks consider the non-achievement of the application specifications and
benefits expected. Typical risks include new/non-standard platform technology, integration
problems with existing other systems, migration problems, performance expectations not
achieved, environment complexity and functionality, and system operability.

3.1.3.4 External
External-based risks consider the 'environmental' factors largely outside of the control of the
Project Management, which can directly/indirectly affect the successful delivery of the Project.
Typically, risks arising from legislative regulations, legal requirements, communication to the
State, lack of market sophistication, and the strategic direction and priority conflicts of a
controlling body, are profiled under this category.
The Cost and Schedule risk sources are known as the risk 'indicators', as they are often the
most tangible measure of overall progress towards Project objectives or goals. The
Technological, and External risk sources are referred to as risk 'drivers', as these are the
sources of all Project risks, which additionally drive the Cost and Schedule risks.
The recognition that the management of the sources of Technological, and External risk is interrelated to the management of Cost and Schedule risks is an important link in effectively
responding and reporting risk-reducing activities.
Page 11 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS
3.1.4

Risk Data

Data necessary to create and track the risk in the Risk Management tool is identified in the table
below. The data fields are defined along with the list of values, if applicable. This data maps
directly to the fields in the risk management tool, Risk Radar (see Section 4).
Table 1 - Risk Data Captured in Risk Management Tool

FIELD NAME

DEFINITION

LIST OF VALUES

Risk Title

Identifies the title of the

risk.

Unique for each risk.

Risk ID

Uniquely identifies
each risk.

001, 002, etc. This number is assigned by the Risk

Management tool.

Rank

Shows the rank of the

risk based on Impact
Date, Probability, and
Severity

Integer value (1, 2, 3, etc.)

Risk
Statement/
Description

Description of what the

risk consists of

Unique for each risk.

Date
Identified

The date the risk was

identified and entered
into the risk tracking
system

Date risk was identified.

Status

Indicates risks position

in the Risk
Management process.

Status Name

Definition

New

A newly identified risk.

Assigned

A risk that has been assigned an owner

and is waiting for necessary data
(mitigation plan, etc.).

Mitigated

This status means that the risk has been

successfully mitigated (resolved). At this
point, the risk probability and/or impact
should be lowered so that the risk color
code is Green.

Page 12 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS
FIELD NAME

DEFINITION

Critical Path

This specifies that the

risk involve an activity
that is on the projects
critical path.

Impact Time
Frame

The period when the

risk is expected to have
impact.

Probability of
Occurrence

Indicates the probability

of the risk occurring.

LIST OF VALUES
Retired

The completed risk no longer has impact,

has been fully mitigated, or has occurred
and the contingency plan has been
successfully executed. Tracking of the
risk is no longer required and the issue is
archived by the risk-tracking tool.

Monitor

The risk is being watched in anticipation

of certain events or activities that might
trigger the need to execute risk
mitigation, or retire/closing of the risk.

Realized

This represents a risk that has been

realized and has become an issue that is
being tracked in the issues tracking
database.

Check Box (check/uncheck)

Date

Definition

Beginning Impact
Date

Earliest assessed date the risk may

begin to have impact.

Ending Impact
Date

Latest assessed date the risk may have

impact.

Probability

Definition

Very High

81-99%

Data or judgment indicates

very high likelihood of
occurrence.

High

61-80%

Data or judgment indicates

high likelihood of occurrence.

Medium

41-60%

Data or judgment indicates

moderate likelihood of
occurrence.

Low

21-40%

Data or judgment indicates

small likelihood of occurrence.

Very Low

1-20%

Data or judgment indicates

very small likelihood of
occurrence.

Page 13 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS
FIELD NAME

DEFINITION

Impact
(specified for
Cost,
Schedule,
Technical,
and Other)

Indicates the estimate

of the impact, should
the risk occur.

Program
Areas

Indicates the OAKS

Project Release in
which the risk would
have the earliest
impact.

LIST OF VALUES

Impact
Severity
Level

Level

Definition

Very High

Cost Increased cost > 10% and/or

Schedule > 25% increase in overall
schedule, cannot achieve goal.

High

Cost Increased cost between 710% and/or Schedule Major

increase in overall schedule, critical
path affected.

Medium

Cost Increased cost between 5-7%

and/or Schedule Increase in team
schedule affects ability to meet major
milestones

Low

Cost Low cost impact, < 5% and/or

Schedule Additional resources
required, but overall schedule not
affected.

Very Low

Cost No/Minimal cost impact and/or

Schedule No/Minimal schedule
impact

Releases

Definition

Program Wide

Risks that would affect all

OAKS releases

Change Management

Risks that affect Change

Management

Financials 1

Risks that affect Financials 1

Financials 2a

Risks that affect Financials 2a

Financials 2b

Risks that affect Financials 2b

HCM 1

Risks that affect HCM 1

HCM 2

Risks that affect HCM 2

Technology

Risks that affect the planned

technological infrastructure of
OAKS

Page 14 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS
FIELD NAME

DEFINITION

LIST OF VALUES

Affected
Phase

This specifies the

software lifecycle
phase the risk might
affect

Responsible
Person

This specifies the risk

owner

Valid values for include:

Requirements Analysis
Functional Design
Technical Design
Build/Configure
Testing
Deployment
Sustainment
The name of the Risk Owner

Risk Area

This specifies the

programmatic areas
affected by the risk

Control

This specifies is this

risk is internal or
external (on the
assumption that OAKS
leadership has no
control over external
risks)

Risk
Mitigation
Description

This describes the plan

to mitigate the risk.

Risk mitigation text.

Risk
Mitigation
Step

There are no limits to

the number of steps for
a mitigation plan. Each
step has the following
fields:

Step Number

Mitigation step number

Risk Description

Mitigation step description

Person

Person responsible for

executing the mitigation step

Due Date

Due date for mitigation step

Complete

Check box indicating step is

complete

Contingency
Plan

This specifies what to

do in case the risk is
realized

Valid values include:

Data
Deployment
Integration
Management
Methodology
Performance
Requirements
Resources
Security
Testing
Valid values include
External
Internal
Internal/External

Contingency plan description.

Page 15 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS
FIELD NAME

DEFINITION

History Event
Log

This is a history log

used to track all
updates made to the
risk from risk
identification to closure

LIST OF VALUES
Date

Person

Event

3.1.5

Date the update to the risk

was made
The person who made the
update to the risk. This field
should be limited to only the
risk administrators who have
sole read/write access to the
risk database
A description of the updates
made to the risk record

Process Steps

This section describes each step in the risk management process as depicted in Figure 2.

3.1.5.1 Identify and Submit Risk

The Risk Originator identifies and submits a new risk using the Risk Entry form, which can be
obtained from BI Designer. Note: Every risk identified is automatically identified as a "New" risk.
The risk remains in its "New" status until the RM Working Group or a Project Team Lead
evaluates and modifies the risk. Once the risk has been approved as a valid risk, its status is
changed from New to Assigned.

3.1.5.2 Risk Assessment

The Risk Originator is responsible for the initial risk assessment. The Project Team Lead or RM
Working Group will work with the Risk Originator, as necessary, to assist in the completion of
the risk entry form. After the risk is entered into Risk Radar, the appropriate party will evaluate
the assessment of the initial values entered and will make necessary adjustments to the
assessment . The risk assessment activity includes filling in the following data elements, and
using the values listed in Table 1 as appropriate:

Title
Description
Probability
Impact
Status (defaults to New)
Earliest Impact Date
Latest Impact Date
Source Person
Point of Contact
Program Areas
Affected Phase
Risk Category

Page 16 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS

Control
Risk Source

In assessing the risk, the Risk Originator first assesses the Probability of Occurrence using
Figure 5 as a reference. The Risk Originator assesses the Severity of Impact in each of the
three impact areas noted in Table 1.
Once the Risk Originator determines the initial Probability of Occurrence and the Severity of
Impact, the Risk tool will calculate the overall Risk Exposure Level. Then the Risk Exposure
Level will fall into one of the following three Risk Rating categories:

Green for Low/Very Low level risks

Yellow for Medium level risks
Red for Very High/High level risks

The Risk Rating is determined as depicted in the following two tables:

Very
High

81%-99%

0.81 0.99

1.62 - 1.98

2.43 - 2.97

3.24 - 3.96

4.05 - 4.95

High

61%-80%

0.61 0.80

1.22 - 1.60

1.83 - 2.40

2.44 - 3.20

3.05 - 4.00

41%-60%

0.41 0.60

0.82 - 1.20

1.23 - 1.80

1.64 - 2.40

2.05 - 3.00

Low

21%-40%

0.21 0.40

0.42 - 0.80

0.63 - 1.20

0.84 - 1.60

1.05 - 2.00

Very Low

1%-20%

0.01 0.20

0.02 - 0.40

0.03 - 0.60

0.04 - 0.80

0.05 - 1.00

Very Low

Low

Medium

High

Very High

Medium
Probability of
Occurrence

Severity of Impact

Probability of
Occurrence

Very
High

81%-99%

Low

Medium

High

Very High

High

61%-80%

Low

Medium

High

Medium

41%-60%

Low

Medium

High

Low

21%-40%

Low

Medium

Very Low

1%-20%

Very
Low

Low

Medium

Very
Low

Low

Medium

High

Very High

Severity of Impact

Figure 5 - Risk Rating

Page 17 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

For example, a risk has been identified and assessed with a Probability of Occurrence of
medium and a Severity of Impact of high. The overall Risk Severity Level is medium.
Using this same example to show how the Risk Exposure Level is calculated, Risk Exposure
uses Probability of Occurrence and Severity of Impact to compute the overall impact of the risk.
The Risk Exposure Level also is used to rank risks in the risk management tool. For example,
the Probability of Occurrence is 60% and the Severity of Impact is Level 4. The following
formula is applied:
Risk Exposure Level = Prob. Of Occurrence * Severity of Impact

The Probability of Occurence 60% and the Severity of Impact 4 are multiplied making the
overall Risk Exposure Level of 2.4 (4 *0.60 = 2.4). Figure 5 shows that a risk with a Risk
Exposure level of 2.4 falls approximately in the Yellow Risk Rating category.
Note that the conversion from Risk Exposure Level to Risk Rating is not an exact process; some
cells in Figure 5 have the same value but are given a different Assessment (different color). For
instance, using Figure 5, the risk exposure value of 2.4 can be located in the Yellow/Medium
Risk Rating and the Red/High Risk Rating; it depends on the value of the Probability of
Occurence.
Risk Ratings are used to determine what actions must be executed. Generally, three actions will
be taken, as determined by each risks Risk Rating:

If the Risk Rating is Green (Very Low/Low level risks), the risk should be monitored and
maintained in the risk watch list; for Green Risks, mitigation plans are not required;
If the Risk Rating is Yellow (Medium level risks), the risk requires a Risk Mitigation Plan
with implications that the mitigation actions will be able to complete the tasks within
current costs and schedule constraints. It should be documented how each mitigation
step will affect the risks probablity and impact (a successful mitigation should reduce risk
exposure).
If the Risk Rating is Red (High/Very High level risks), the risk requires a Risk Mitigation
Plan (Document how each mitigation step will affect the risks probability and impact [a
successful mitigation should reduce risk exposure]) and also a Contingency Plan
because there is a higher probability that the mitigation actions will not be sufficient
enough to maintain cost and schedule constraints, and therefore a Contingency Plan is
required.

Milestones
Risk Milestones are the trigger points or drop dead dates when a Contingency Plan execution
is triggered unless the risk has been successfully mitigated. The trigger points must be
incorporated in the WBS so they can be tracked. All of the risks containing a Risk Rating of Red
potentially have risk milestones. The client and the RM Working Group will work together to
determine which risks in the Red Risk Rating category will have risk milestones.

Page 18 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

Once the Risk Originator identifies and assesses the risk, the Project Team Lead or RM
Working Group evaluates the risk to ensure it fits the RMP definition of a risk. If the risk does
not meet the risk definition or duplicates another risk, the RM Working Group deletes it and
notifies the Risk Originator. If the risk is judged valid, but the analysis is incomplete, the Project
Team Lead or RM Working group will work with the Risk Originator and others to complete the
analysis and recommendations. Should the Project Team Lead or RM Working Group have any
questions or need further clarification, they will contact the Risk Originator to obtain the
necessary information.

3.1.5.3 Evaluate Risk

The Project Team Lead or RM Working Group recommends a Risk Owner and, as appropriate,
works with that person to set a risk mitigation plan due date, contingency plan due date, and a
risk milestone date. Upon approval, the Project Team Lead or RM Working Group changes the
risk status to the appropriate open status and notifies the Risk Owner of actions required. The
Risk Owner will then validate the risk analysis and develop any required Mitigation and
Contingency plans.
Should the assigned Risk Owner disagree with the ownership assignment or the Project Team
Lead or RM Working Group risk analysis, the Risk Owner will inform the appropriate parties and
provide justification for this conclusion and recommended changes to the risk analysis and
ownerhip assignment as appropriate. Should the Risk Owner have any questions or need
further clarification, the Risk Owner will work with the Risk Originator and the Project Team
Lead or RM Working Group to obtain needed information. The Risk Owner will update the risk
information by sending an e-mail to a Risk Administrator with the necessary updates. If the Risk
Owner needs help developing a Risk Mitigation or Contingency Plan, the Risk Owner can use
the Risk Owner Guide for reference which can also be obtained through the Risk section of the
BI Designer Website, the Risk Administrators, and/or a RM Working Group POC; or he or she
can contact the Risk Administrators and/or a RM Working Group POC for further assistance.
After updates have been made, the Risk Entry Form should be e-mailed to a Risk Administrator.
Risk Response and Control

Page 19 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS
Risk
Evaluation &
Planning
Process

Scope
Statement

Communication
Plan

WBS &
Activity Lists

Procurement
Process

Monitor Identified
Risks

Track Triggers of
"Watch" Risks

Follow-up on
"Elevated" Risks

o
o
o

Track & Update all

Risks in database

Control Risks
Review Status
Communication with Project Team
Re-Planning, as required

Risk
Triggered?

Yes

Execute Mitigating
Action Plan

o
o
o

Risk Reporting
Update Risk Summary
Status Updates with Project Team
Update Risk Database

o
o

Post Project Review

Final Status Updates
Update Project Files

Quality Assurance Review

(see Quality Plan)

Figure 6 - Risk Response and Control

Figure 6 depicts the typical flow of activities for risk response and control. The initial steps in
the Risk Analysis Process consider the analysis of detailed risk responses to those risks which:
May occur soonest in the development lifecycle, irrespective of probability
Are high impact, high level of probability

This is intended to cover any short-term exposure first, before considering overall project risk
reduction. Overall, project risk response analysis covers five characteristic responses:
Page 20 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

Avoidance
Avoidance-based responses are employed at any point in the development lifecycle where
future-planning work is performed. Typically, most risk avoidance occurs during the project
definition and planning phases of a project, where objectives, scope, key success factors, work
breakdown, and project outputs or deliverables are defined. An example of risk avoidance is
the use of a stable, established technical solution in preference to an untried, or complex new
technology. However, risk avoidance solutions may limit the ability to achieve high-level project
objectives, by unnecessarily constraining a desirable solution.
Transfer
Transfer-based responses target the party who are best placed to analyze and implement the
response to the risk, based on their expertise, experience, and suitability. Typical transfer
responses include the sub-contracting to external suppliers who are able to reduce the overall
risk exposure.
Control
Control-based responses occur at all points throughout the development lifecycle, and are
typically the most common response. They identify an action or product that becomes part of
the development effort, and which are monitored and reported as part of the regular
performance analysis and progress reporting of the project.
Acceptance/Assumption of Risk
These describe the factors that may directly affect the success of the project, but are outside of
the sphere of influence of the Project Management, and can therefore only be 'accepted'. In
addition, acceptance of risks as a response may be based on the cost-ineffectiveness of any
available response or solution. An example: acceptance response could be created from a
legislative or legal risk, over which no control could be leveraged.
Investigation/Research
Investigation-based responses do not define any mitigation for reducing an individual risk. They
are responses to risks where no clear solution is identified, and further research is required.
However, investigative responses will not be ignored, as they immediately and directly lead to a
greater aggregated project risk. This is because the probability quantifier for each risk includes
the effect of the applied response, for which there is none, and the level of control quantifier
indicates the level of influence to apply that response, which is low.

3.1.5.4 Develop Mitigating Actions

Once the Risk Owner has agreed to ownership and the Risk Mitigation Plan has been approved,
the Risk Owner is responsible for timely risk mitigation. The Risk Mitigation Plan will provide the
action items (with due dates) needed to mitigate the risk successfully. The Risk Owner will
involve all parties affected by the risk and will provide mitigation progress reports on a regular
basis.
Page 21 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

No Mitigation Plan Required

Lo Med Med Med Hi

V.Hi
Hi

Lo Med Med Med Hi

V.Lo Lo

Lo Med Med
Lo

Med

Figure 7 - Risk Mitigation Approval Matrixes

Page 22 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

Performing The Risk Mitigation and Contingency Actions

Upon approval of the risk mitigation or contingency plan, the Risk Owner begins the risk
mitigation or contingency actions (if the entry criteria have been met). If the Risk Owner cannot
execute the risk mitigation or contingency plan, he or she should contact the Project Team Lead
immediately and give the reason for not resolving the risk. The Project Team Lead may do the
following:

Work with the Risk Owner to enable execution of the plan

Notify project manager of the reason the plan cannot be executed
Recommend re-assignment of the risk to another Risk Owner who is capable of
resolving the risk

The Risk Owner provides status updates as they occur to the Project Team Lead and before the
RM Working Group Meetings. The updates include:

Any research of alternatives or background

Any mitigation or contingency schedule slippage
Adequate detail to describe the results where mitigation has been achieved or
contingency plans have been completed
When the risk has a recommended mitigation and indicates the risk is Ready-toComplete for RM Working Group review
Updated Mitigation Plans
Recommended changes in status as appropriate

When the Risk Owner has mitigated the risk or completed contingency actions, the Risk Owner
informs the Project Team Lead and recommends that the risk either be retired or remain open
but be put on a watch list until a date specified in the future.

3.1.5.5 Complete Risk

When all steps in a risk mitigation plan are complete, steps need to be taken to re-evaluate the
risk. If the impact date has passed (risk has occurred and been realized), the Project Team
Lead must evaluate it and he or she must notify the Risk Radar Administrator if the Risk has in
fact been realized, needs to be retired, or both. Provided that the risk is Green or Yellow at the
time of realization, the risk can be retired at the Release or Risk Management Working Group
meetings without any additional actions. If the risk is a Red Risk and becomes realized, this fact
usually will trigger the Contingency Plan.
The criteria for determining if a risk is complete:

The risk has been completely mitigated

The risk has occurred and the contingency plan has been successfully executed
The impact period for the risk has passed and the RM Working Group, with the
agreement of the decision authority for the appropriate risk severity level, determines
that the risk is no longer valid

Page 23 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

If the Project Team Lead or RM Working Group decides the risk mitigation is not satisfactory,
the risk remains open and the Risk Owner must re-apply mitigation to the risk. This process
includes reviewing the mitigation strategies/techniques and the Risk Mitigation Plan to
determine what additional steps must be taken to mitigate the risk to its targeted severity level.
Once a risk is completed but remains open, the risk remains in the "Monitoring" status until a
later date at which time the status will be reassessed. This status does not mean the risk is
"closed," "not applicable anymore," "unimportant," or "inactive." Rather, it means the risk is still
valid and could still affect program cost or schedule.
In the event a mitigated risk has been retired but is later reassessed as a valid risk, any Team
Lead or RM Working Group participant can recommend the risk be re-opened at the next
meeting. Once the risk is re-opened, it will be treated as all other risks and will require a new
mitigation plan depending on color.

3.2

Risk Escalation Procedures

Escalation decisions can be made at the Project Lead level and higher to escalate decisions to
the PMO or EL. Risks with Very High severity levels are elevated to the OAKS BOA Group
through the Weekly Status Meeting. Additionally, the Project Team Leads and RM Working
Group escalate to the EL, through the PMO, those issues determined to need crossorganization involvement, are controversial, or require OAKS EL decisions.

3.3

Risk Management Working Group Meetings (Quarterly or as needed)

The RM Working Group meetings are conducted on a quarterly basis, and are facilitated by the
State or Contractor Risk Manager. Meeting schedules may vary with the need for them. The
OAKS RM Working Group roles are considered part-time roles. For meeting attendees unable
to attend in person, a dial-up telephone number will be available. Regular meeting attendees
include:

OAKS Risk Managers

Risk Originator, as required
Risk Owner, as required

During the RM Working Group meeting, the Group will discuss all the new and past due risks.
New or modified Mitigation and Contingency plans will be reviewed for concurrence. The risk
originators will provide or present (as requested) new risks to the RM Working Group and
provide necessary details. The risk owners will provide updates for all other risks, either in
person or through the appropriate Risk POC. Any additional action items or updates to their
status will be communicated to the action item owner. Upon completion of the meeting, the RM
Working Group will generate a Risk Report to be provided to OAKS management with updated
metrics and what changes occurred during the meeting.
In addition to the RM Working Group meeting, the Risk Managers will brief the OAKS Program
Manager on a regular basis, as determined by the Program Manager.

Page 24 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

Transforming the Way Ohio Does Business

OAKS

3.4

Risk Meeting and Reporting Processes (Weekly and Daily)

The Risk Database Administrators generate standard reports as part of the day-to-day risk
management process. Risks (and issues) are discussed in the projects team lead weekly
meetings. In preparation for these meetings, the Risk Administrators prepare a Risk Watch List
(see Table 3) listing the risks for review (i.e., new, past-due, mitigation steps past due). After
such meetings, the Project Team Leads notifies the Risk Administrators of the results of the
meetings (i.e., status of new risks submitted, new risk assignments, etc.) so that he or she can
make the appropriate updates to the risk database. These reports, RM Work Group meeting
minutes, and risk listings will be placed in the BI Designer risk folders for accessibility. A
summary of standard notices and reports is listed below.
These reports are an initial draft of recommended risk reports. This list is subject to change
based on the project team leads, and project managers risk reporting requirements.
REPORT

SENDER

AUDIENCE

TIMING

New Risks

Risk Radar
Administrator

Administrator, and as needed
by team members.

Risks Past Due

Table 2 - Standard Risk Notices and Reports

Page 25 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

3.5

Transforming the Way Ohio Does Business

Risk Meeting Report

Within two business days of the meeting, the RM Working Group publishes via email, a Risk
Meeting report summarizing all action items taking place at the RM Working Group meeting.

3.6

Risk Mailing List

The OAKS Program Risk Administrators maintains an e-mail distribution list used to mail risk
reports to the individuals applicable for each release. The mailing list is located at:
OAKS\Cabinets\Project Management\Risks\Risk Mailing List.

4 Risk Management Tool

The Risk management tool is Risk Radar Version 2.0.2. Risk Radar is developed and
maintained by Integrated Computer Engineering Inc
(http://www.iceincusa.com/products_tolls.htm). It is a customized risk management system built
using Microsoft Access with proprietary VBA code running in the background. Risk Radar was
selected because it is built by project managers for project managers for one purpose only:
effective risk management.
Risk Radar comes fully loaded out of the box with pre-configured canned reports and queries.
However, since the Risk Radar data model is available to users, we have the ability to
customize existing reports, or create new ones. Additionally, the data managed in Risk Radar
can be readily exported to other Microsoft applications, such as Excel, or Word, allowing for
maximum flexibility regarding how we can use data stored in Risk Radar.
Since the Risk Radar database is a Microsoft Access file, it will be managed under configuration
control in BI Designer. Only the OAKS Risk Administrators will have Write access to the Risk
Radar Database in BI Designer (this means, only the administrators will be able to check out
and update the Risk Radar database). Everyone else will be able to browse the database, or
download/export a copy to his or her desktop for local use.

4.1

Risk Section of BI Designer Available to All OAKS Team Members

While the Risk Radar is the primary repository for the Risk data, the risk management folder is
available for all risk reports and risk related resources, including a read-only copy of the Risk
Radar database. The path to the risk section of BI Designer is OAKS\Cabinets\Project
Management\Risk Management. This website allows all the team members to submit risks as
well as review risk information. The Risk Administrators regularly reviews and updates data on
this website, by publishing new reports and posting the latest version of the Risk Radar for readonly access.

4.2

Using The Risk Entry Form to Create New Risks

The risk entry form allows users to enter the risk data into a spreadsheet. They must then email
the spreadsheet to a Risk Database Administrator to be entered into the Risk database. The
Risk Entry Form can be found on the Risk Management Section of BI Designer. New risks must
first be validated before they are active in the system. Please consult with your co-workers or
Page 26 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

supervisor before submitting a new risk request. Furthermore, new risks are reviewed in weekly
and daily status meetings. Be sure your immediate reporting official is aware of the new risks
so that he or she can discuss the risk when it is brought up at the status meeting. Or, if you
routinely attend such status meetings, be prepared to discuss your rationale for creating the
new risk.

4.3

Viewing Risks

Risks can be viewed on the Risk section of the BI Designer website, by downloading the
appropriate risk report. Only the Risk Administrators will have Read/Write access to risk
information. Everyone else will have read-only access, and can create their own reports by
running queries using the Risk Radar Database.

4.4

Updating Risks

In order to update risk information, risk owners should simply e-mail a risk administrator with the
required update information, since only Risk Administrators can update the Risk Radar
database.

5 OAKS Risk Management Metrics

Reference the OAKS Program Project Measurement Plan in BI Designer for risk measurement
information: OAKS\Cabinets\Project Management\Quality\Metrics\Project Measurement Plan.

6 Risk Identification Questionnaire

The following list of questions can be used to help identify project risks.

Risk Area of
Concern

MANAGEMENT APPROACH

PROJECT MANAGEMENT

Risk Questions
Is the project managed according to the plan?
Do people routinely get pulled away to fight fires?
Is re-planning (change control) done when disruptions occur?
Are people at all levels included in planning their own work?
Are there contingency plans for known risks?
Is there a mechanism in place to determine when to activate the
contingencies?
Are long-term issues being adequately addressed?
Are project members at all levels aware of their status versus plan?
Do people feel it is important to keep to the plan?
Does management feel it's important to keep to the plan?
Does management consult with people before making decisions that
affect their work?
Is the quality assurance function adequately staffed on this project?
Do you have defined mechanisms for assuring quality?

Y/N

Page 27 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

ROLES/SKILLS
RESOURCES
SCHEDULE

PROJECT MANAGEMENT

CO
ST

Do all areas and phases have quality procedures?

Are people used to working with quality procedures?
Do you have an adequate configuration management system?
Is the configuration management function adequately staffed?
Is coordination required with an installed system?
Does the configuration management system synchronize your work with
site changes?
Is the project organization effective?
Do we have adequate support from Executive Sponsors and Executive
Advisory Committee?
Do we have adequate support from the Governor's Office?
Do people understand their own and others' roles in the project?
Do people know who has authority for what?
Does the project have experienced managers or leads?
Do people get trained in the skills required for this project?
Is this part of the project plan?
Do people get assigned to the project who do not match the experience
profile for your work area?
Is it easy for project members at all levels to get management action?
Are there any areas in which the required technical skills are lacking
(e.g., software engineering and requirements analysis methods,
programming languages, integration and test methods, reliability,
maintainability, availability, human factors, configuration management)?
Do you have adequate personnel to staff the project?
Is the staffing stable?
Do you have access to the right people when you need them?
Does the staff have previous project experience?
Have the project members implemented systems of this type?
Is the program reliant on a few key people?
Is there a problem with getting people cleared (security)?
Is there any problem keeping the people you need?
Is the team geographically dispersed?
Will resources be unavailabe during certain times (tax season, Christmas
& other holidays and end of fiscal year, etc.)?
Could work delays / stoppage occur due to program's impact to union
workforce (i.e., changing of job duties)?
Are the development facilities adequate?
Has the schedule been stable?
Is the schedule realistic?
Is the estimation method based on historical data?
Has the method worked well in the past?
Is there anything for which adequate schedule was not planned (e.g.,
analysis and studies, quality assurance, training, maintenance courses
and training, equipment, deliverable development system)?
Are there external dependencies which are likely to impact the schedule?
Is the budget stable?

Page 28 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

COMMUNICATION

ENGAGEMENT
MANAGEMENT

CONTRACT

ENGAGEMENT
MANAGEMENT

CULTURE

Is the budget based on a realistic estimate?

Is the estimation method based on historical data?
Has the method worked well in the past?
Have features or functions been deleted as part of a design-to-cost
effort?
Is there anything for which adequate budget was not allocated (e.g.,
analysis and studies, quality assurance, training, maintenance courses
and training, equipment, deliverable development system)?
Do budget changes accompany requirement changes?
Is this a standard part of the change control process?
Does management communicate problems up and down the line?
Are conflicts / issues documented and resolved in a timely manner?
Does management involve appropriate project members in meetings
(e.g. Technical Leaders, Developers, Analysts)?
Does management work to ensure that all factions are represented in
decisions regarding functionality and operation?
Are there periodic structured status reports?
Do people get a response to their status reports?
Does appropriate information get reported to the right organizational
levels?
Do you track progress versus plan?
Does project management communicate problems to senior
management?
Does management present a realistic picture to senior management?
Does management have a clear picture of what is going on?
Does the type of contract you have (e.g., time & materials, cost plus
award, fixed priced, etc.) present any problems?
Is the contract burdensome in any aspect of the project (e.g., statement
of work, specifications, contract sections, excessive client oversight)?
Is the required documentation burdensome (e.g., excessive amount, long
approval cycle)?
Are there any problems with data rights (e.g., packages, developmental
software, non-developmental items)?
Are there external dependencies on external products or services that
may affect the product, budget or schedule (e.g., associate consulting
firms, prime contractor, subcontractor, vendors or suppliers, client
furnished resources?
Are all staff levels oriented toward quality procedures (process
improvement)?
Does schedule get in the way of quality?
Do people work cooperatively across functional boundaries?
Do people work effectively toward common goals?
Is management intervention sometimes required to get people working
together?
Is there good communication among the members of the program (e.g.,
managers, Tech Leads, Developers, Testers, Configuration
management, quality assurance)?

Page 29 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

POLITICS
STATE
USE SUBS

INTERFACES

Are the managers receptive to communication from project staff?

Do you feel free to ask your managers for help?
Does management tend to micro-manage?
Are members of the program able to raise risks without having a solution
in hand?
Do the project members get timely notification of events that may affect
their work?
Is notification informal?
Is morale on the project good?
Are you aware of the main contributors to low morale?
Are politics affecting the project (e.g., agency, subcontractors, prime
contractors, vendors)?
Are politics affecting the State's support of the project?
Are politics affecting technical decisions?
Are politics affecting project communications?
Is adequate support available for the project?
Are politics affecting issue escalation?
Are politics affecting business decisions?
Is it good politics to present an optimistic picture to the State or senior
management?
Is the State approval cycle timely (e.g., documentation, change
proposals, project reviews, formal reviews)?
Do you ever proceed before receiving State approval?
Is this project dependent upon completion of other State projects?
Is the State fractured in their support of the project?
Does the State understand software?
Does the State interfere with process or people?
Does management work with the State to reach mutually agreeable
decisions in a timely manner (e.g., requirements understanding, test
criteria, schedule adjustments, interfaces)?
Are your mechanisms for reaching agreement with the State (e.g.,
working groups, technical interchange meetings, etc.) effective?
Are all State factions involved in reaching agreements?
Is it a formally defined process?
Is there any problem with getting schedules or interface data from user
agencies?
Are they accurate?
Are there any ambiguities in subcontractor task definitions?
Is the subcontractor status reporting and monitoring procedure consistent
with the rest of the project team?
Is the subcontractor administration and technical management done by a
separate organization?
Are you highly dependent on subcontractor expertise in any areas?
Is subcontractor knowledge being transferred to the State?
Is there any problem with getting schedules or interface data from
subcontractors?

Page 30 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

ARE A SUB
VENDORS
SCOPE

REQUIREMENTS

Are your task definitions from the Prime ambiguous?

Do you interface with two separate prime organizations for administration
and technical management?
Are you highly dependent on the Prime for expertise in any areas?
Is there a problem with getting schedules or interface data from the
Prime?
Are you relying on vendors for deliveries of critical components (e.g.,
compilers, hardware, packages)?
Are vendors used in a critical path task?
Is the performance of the vendors currently poor?
Are multiple vendors supporting the project?
Are multiple vendors used on the project?
Is the contract clear on that point?
Are relevant vendor contracts in place for the duration of the project?
Do you have solutions for all of the requirements?
Are the requirements stable?
Is there an effect on the system or project (e.g., quality, functionality,
schedule, integration, design, testing)?
Are the external (human and system) interfaces changing?
Are the interfaces defined, documented, and baselined?
Are there any "To Be Determined"s in the specifications / scope
statement?
Are there requirements (scope / deliverables) you know should be in the
specifications (scope statement) but aren't?
Will you be able to get these requirements (scope / deliverables) into the
project?
Does the State have unwritten requirements / expectations?
Is there a way to capture these requirements / expectations?
Are the external (human and system) interfaces completely defined?
Are you able to understand the requirements (scope / deliverables) as
written?
Are the ambiguities being resolved satisfactorily?
Are there problems with interpretation?
Are there any requirements that may not specify what the State really
wants?
Is this being resolved satisfactorily?
Do you and the State understand the same thing by the requirements
(scope / deliverables)?
Is there a process by which to determine this?
Are you validating the requirements (e.g., by prototyping, analysis or
simulation)?
Are there any requirements that are technically difficult to implement?
Were feasibility studies done for the requirements?
Are you confident in the assumptions made in the studies?
Are there any state-of-the-art requirements (e.g., technologies, methods,
languages, hardware, communications)?

Page 31 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

DEVELOPMENT PROCESS
CHANGE CONTROL

DEVELOPMENT METHODOLOGY

DEVELOP
MENT
ENVIRON
MENT

Are there any technologies, methods, languages, hardware or

communications that are new to you?
Is there a plan for acquiring knowledge in these areas?
Is the project size a concern?
Is the project complexity a concern?
Does the size require a larger organization than usual for Accenture?
Is this a mission critical system?
Will the implementation be difficult to understand or maintain?
Is there more than one development model being used (waterfall,
incremental, evolutionary)?
Is coordination between them a problem?
Are there formal, controlled plans for all development activities (e.g.,
requirements analysis, design, code, integration & test, installation,
quality assurance, configuration management, etc.)?
Do the plans specify the process well?
Are developers familiar with the plans?
Is the development process adequate for this product?
Is the development process supported by a compatible set of
procedures, methods and tools?
Does everyone follow the development process?
Can you measure whether the development process is meeting
productivity and quality goals?
Is there adequate coordination among distributed development sites?
Is there a parallel cutover period with the existing system?
Are people comfortable with the development process?
Is there a requirements traceability mechanism that tracks requirements
from the source specification through test cases?
Is the traceability mechanism used in evaluating requirement (scope)
change impact analyses?
Is there a formal change control process?
Does it cover all changes to baselined requirements, design, code, and
documentation?
Are changes at any level mapped up to the system level and down
through the test level?
Is there adequate analysis when new requirements are added to the
system?
Are the external interfaces changing without adequate notification,
coordination, or formal change procedures?
Do you have a way to track interfaces?
Is there a change control process for internal interfaces?
Is a formal change control process currently used?
Are the test plans and procedures updated as part of the change
process?
Are there enough workstations and processing capacity for all staff?
Is there sufficient capacity for overlapping phases, such as coding,
integration and test?

Page 32 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

DESIGN

DEVELOPMENT METHODOLOGY

Does the development system support all aspects of the project (e.g.,
requirements analysis, performance analysis, design, coding, test,
documentation, configuration management, management tracking,
requirements traceability)?
Do people find the development system easy to use?
Is there good documentation of the development system?
Have people used these tools and methods before?
Is the system considered reliable (e.g., compiler, development tools,
hardware)?
Are the people trained in the use of the development tools?
Do you have access to experts in use of the system?
Do the vendors respond to problems rapidly?
Are you delivering the development system to the State?
Have adequate budget, schedule, and resources been allocated for this
deliverable?
Is the development computer the same as the target computer?
Are there compiler differences between the development and target
computer?
Are there any specified algorithms that may not satisfy the requirements?
Will development of database be difficult to match physical design?
Are any of the algorithms or designs marginal with respect to meeting
requirements?
Do you determine the feasibility of algorithms and designs (e.g., using
prototyping, modeling, analysis or simulation)?
Does any of the design depend on unrealistic assumptions?
Does any of the design depend on optimistic assumptions?
Are there any requirements or functions that are difficult to design?
Will the complexity of functions or databases be a factor?
Are the internal interfaces well defined (software-to-software and
software to hardware)?
Is there a process for defining internal interfaces?
Are there any problems with performance (e.g., throughput; scheduling
asynchronous real-time events; real-time response; recovery timelines;
response time; database response, contention or access)?
Has a performance analysis been done?
Do you have a high level of confidence in the analysis?
Do you have a model to track performance through design and
implementation?
Does the architecture, design or code create any maintenance
difficulties?
Are the maintenance people involved early in the design?
Is the product documentation adequate for maintenance by an outside
organization?
Are reliability requirements allocated to the software?
Are availability requirements allocated to the software?
Are recovery timelines any problems?

Page 33 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

CODING
PACKAGES & REUSE

DEVELOPMENT METHODOLOGY

Are the design specifications adequate to implement the system (e.g.,

internal interfaces)?
Does the hardware limit your ability to meet any requirements (e.g.,
architecture, memory capacity, throughput, real-time response, response
time, recovery timelines, database performance, functionality, reliability,
availability)?
Are there any parts of the product implementation not completely defined
by the design specification?
Are the selected algorithms and designs easy to implement?
Does the design include features to aid testing?
Have coding standards been documented and communicated?
Has the State / end-user signed off on the coding specifications?
Are the design specifications in sufficient detail to write the code?
Is the design changing while coding is being done?
Are there system constraints that makes the code difficult to write (timing,
memory, external storage)?
Is the language suitable for producing software on this project?
Are there multiple languages used on the project?
Is there interface compatibility between the code produced by the
different compilers?
Are there problems with software used in the project but not developed
on the project?
Are you reusing or re-engineering software not developed on the project?
Do you foresee any problems (e.g., documentation, performance,
functionality, timely delivery, customization)?
Are there any problems with using packages such as:
insufficient documentation to determine interfaces, size or
performance
poor performance
requires a large share of memory or database storage
difficult to interface with application software
not thoroughly tested
not bug free
not maintained adequately
slow vendor response
Do you foresee any problem with integrating packaged software updates
or revisions?
For testing, will vendor data be accepted in verification of requirements
allocated to the packaged products?
Has sufficient system integration been specified for integration testing of
packaged products?
Has adequate time been allocated for system integration and test?
Are all contractors part of the integration test team?
Will the product be integrated into an existing system?
Have you made plans to guarantee that the package will work correctly
when integrated?

Page 34 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Ohio Administrative Knowledge System

OAKS

Transforming the Way Ohio Does Business

TESTING
PROTOTYPES

DEVELOPMENT METHODOLOGY

Will system integration occur on State site?

Do the testers get involved in analyzing requirements?
Do you begin unit testing before you verify code with respect to the
design?
Has sufficient unit testing been specified?
Is there sufficient time to perform all the unit testing you think should be
done?
Will compromises be made regarding unit testing if there are schedule
problems?
Will there be sufficient hardware to do adequate integration and testing?
Is there any problem with developing realistic scenarios and test data to
demonstrate any requirements (e.g., specified data traffic, real-time
response, asynchronous event handling, multi-user interaction)?
Is there UAT performed by the end-user without input from IT?
Are you able to verify performance in your facility?
Does hardware and software instrumentation facilitate testing (e.g., line
sniffers, etc.)?
Is it sufficient for all testing?
Will the target hardware be available for testing when needed?
Have acceptance criteria been agreed to for all requirements?
Is there a formal agreement?
Are there any requirements that will be difficult to test?
Has sufficient product integration been specified?
Has adequate time been allocated for product integration and test?
If prototyping, is it a throw-away prototype?
Are you doing evolutionary development?
Are you experienced in this type of development?
Are interim versions deliverable?
Does this complicate change control?
Are the software requirements specifications adequate to design the
system?
Are the hardware specifications adequate to design and implement the
system?
Are the external interface requirements specified?
Are the test specifications adequate to fully test the system?
Is the integration environment adequate?
Is the software going to be easy to test?

Page 35 of 35
State of Ohio OAKS Project
i:\common share\signed accenture deliverables\deliverable 9\pm129 oaks risk management plan.doc
Version Control Number: 1.2 9/26/2005

Multimedia Risk Management Plan

< The risk management plan documents the procedures that will be used to manage
risk throughout the project. In addition to documenting the results of the risk
identification and risk quantification processes, it covers who is responsible for
managing various areas of risk, how the initial identification and quantification
outputs will be maintained, how contingency plans will be implemented, and how
reserves will be allocated.>

Version:
Date:
Status:

24/08/98
<Draft or Approved>

Approved by:
Approvers name:
Approvers title:
Approvers section:

Preface
For more information on this procedure, contact <Name>,
<Title>, <Section/Division>. Tel: (nn) nnnn nnnn, Fax: (nn)
nnnn nnnn.
This document was produced using <Microsoft Word>.

Revision History
Date
<Date>

Ver.

Author

Comments

<Name>

<e.g. Document created, or minor

alterations.>

Contents
1.0 Introduction

1.1 Scope and purpose of document..............................................................2

1.2 Overview of major risks............................................................................2
1.3 Responsibilities..........................................................................................2

2.0 Project Risk Table

2.1 Risk Identification.......................................................................................3

2.2 Description of all risks above cutoff.........................................................3
2.3 Factors influencing probability and impact................................................3

3.0 Risk mitigation, monitoring and management

3.1 Risk item #n................................................................................................4

1 Mitigation...................................................................................................4
2 Monitoring.................................................................................................4
3 Management.............................................................................................4

4.0 RM Plan Iteration Schedule

5.0 Summary

1.0 Introduction
1.1 Scope and purpose of document
<This paragraph shall summarise the purpose and contents of
this document and shall describe any security or privacy
considerations associated with its use.>

1.2 Overview of major risks

1.3 Responsibilities
<This paragraph shall identify the owner of the major risks to
the project. This usually rests with the Project Manager, but
on larger projects, it may be the responsibility of the Sponsor,
or Project Steering Committee.>

2.0 Project Risk Table

Risk Item
size estimates too
low
funding will be lost
technology will not
meet expectations
high staff turnover

Category
PS

Probability
60%

Impact
2

CU
TE

40%
30%

1
1

60%

Where:
Category is the risk category based on:
Product size

Business impact

Customer characteristics

Process definition

Development environment

Reference

Technology

Staff size and experience

Impact indicates the likely effect on the project and the

resulting product:
catastrophic (show-stopper)

critical (delay, extra cost)

marginal (extra effort)

negligible (internal effort)

Probability is the current estimate of the likelihood of

occurrence
Reference indicates the risk item number detailed in this plan.

2.1 Risk Identification

<This paragraph shall describe the inputs, the tools and the
outputs of the risk identification activities.>
Risk Quantification
<This paragraph describes the inputs, tolls and outputs from
the risk quantification process.>
Risk Response Development
<This paragraph describes the inputs, tools and outputs of the
risk response development for mitigation, monitoring and
control.>
Risk Response Control
<This paragraph describes the inputs, tools and outputs to
control risk response as the risk events occur.>

2.2 Description of all risks above cut-off

2.3 Factors influencing probability and impact

3.0 Risk Mitigation, Monitoring and

Management
<This section shall be divided into the following paragraphs.
Provisions corresponding to non-required activities may be

satisfied by the words Not applicable. If different builds or

different multimedia on the project require different planning,
these differences shall be noted in the paragraphs. In addition
to the content specified below, each paragraph shall identify
applicable risks/uncertainties and plans for dealing with
them.>

3.1 Risk item #n

Mitigation
<This paragraph describes the plan for avoiding risk by
effective pro-active mitigation activities. When mitigation
activities have not been implemented, and the project is
expected to manage the risk, a RISK MEMO should be created
to record the fact.>

Monitoring
This paragraph describes the risk monitoring activities to be
used on the project.>

Management
This paragraph describes the risk management and
contingency plan. It assumes that the avoidance or mitigation
strategy has failed, and the risk has become a reality.>

4.0 Risk Management Plan Iteration Schedule

5.0 Summary
<This section will summarise the current status of the Risk
Management Plan.>

Risk Assessment Matrix

For use with the Risk Management guide
This is one example of a number of tools that can assist with your risk assessment process.

What you need to do

1. Consider what can go wrong
2. Determine how bad the outcome would be - Consequences
3. Determine how likely it is to happen - Likelihood
4. Calculate the risk level

CONSEQUENCES
LIKELIHOOD
Almost
certain
Likely

Catastrophic
5

Major
4

Moderate
3

Minor
2

Insignificant
1

5
4

Possible
3
Unlikely
2
Rare
1
Risk Score

What should I do?

9-10
7-8

Extreme
High

5-6

Moderate

2-4

Low

Immediate action required

Action plan required, senior management
attention needed
Specific monitoring or procedures required,
management responsibility must be specified
Manage through routine procedures

CONSEQUENCES:

How severely could it hurt someone/cause damage?

Catastrophic
Major
Moderate
Minor
Insignificant

death or large number of serious injuries, environmental disaster, huge cost

serious injury, extensive injuries, severe environmental damage, major cost
medical treatment required, contained environmental impact, high cost
first aid treatment required, some environmental and/or financial impact
No injuries, low financial/environmental impact

LIKELIHOOD:

How likely is it to happen?

Almost Certain
Likely
Possible
Unlikely
Rare

expected to occur in most circumstances

will probably occur in most circumstances
might possibly occur at some time
could occur at some time
may occur only in exceptional circumstances

RISK ASSESSMENT MATRIX

Determining the Level of Risk
This document can be used to identify the level of risk and help to prioritise any control measures.
Consider the consequences and likelihood for each of the identified hazards and use the table to obtain the risk level.

Likelihood

Consequences

A-

Almost certain to occur in most

circumstances

B-

Likely to occur frequently

C-

Possible and likely to occur at some

time

D-

Unlikely to occur but could happen

E-

May occur but only in rare and

exceptional circumstances

1 Insignificant

2 Minor

3 Moderate

4 Major

5 Catastrophic

Dealt with by in-house first

aid, etc

Medical help needed.

Treatment by medical
professional/hospital
outpatient, etc

Significant non-permanent
injury.
Overnight hospitalisation
(inpatient)

Extensive permanent injury

(eg loss of finger/s)
Extended hospitalisation

Death.
Permanent disabling injury
(eg blindness, loss of hand/s,
quadriplegia)

High (H)
Moderate (M)
Low (L)
Low (L)
Low (L)

High (H)
High (H)
Moderate(M)
Low (L)
Low (L)

Extreme (X)
High (H)
High (H)
Moderate(M)
Moderate (M)

Extreme (X)
Extreme (X)
Extreme (X)
High (H)
High (H)

Extreme (X)
Extreme (X)
Extreme (X)
Extreme (X)
High (H)

How to Prioritise the Risk Rating

Once the level of risk has been determined the following table may be of use in determining when to act to institute the control measures.
Act immediately to mitigate the risk.Either eliminate, substitute or implement engineering control measures.
Remove the hazard at the source. An identified extreme risk does not allow scope for the use of
Extreme
High

Act immediately to mitigate the risk. Either eliminate, substitute or implement engineering control measures.
If these controls are not immediately accessible, set a timeframe for their implementation and establish interim
risk reduction strategies for the period of the set timeframe.

Medium

Take reasonable steps to mitigate the risk. Until elimination, substitution or engineering controls can be
implemented, institute administrative or personal protective equipment controls. These lower level controls
must not be considered permanent solutions. The time for which they are established must be based on risk.
At the end of the time, if the risk has not been addressed by elimination, substitution or engineering controls a
further risk assessment must be undertaken.

Low

administrative controls or PPE , even in the short term.

An achievable timeframe must be established to ensure that elimination, substitution or engineering controls
are implemented.
NOTE: Risk (and not cost) must be the primary consideration in determining the timeframe. A timeframe of
greater than 6 months would generally not be acceptable for any hazard identified as high risk.
Interim measures until permanent solutions can be implemented:

Develop administrative controls to limit the use or access.

Provide supervision and specific training related to the issue of concern.

below)

(See Administrative Controls

Take reasonable steps to mitigate and monitor the risk. Institute permanent controls in the long term. Permanent
controls may be administrative in nature if the hazard has low frequency, rare likelihood and insignificant
consequence.

Hierarchy of Control

Controls identified may be a mixture of the hierarchy in order to provide minimum operator exposure.

Elimination

Eliminate the hazard.

Substitution

Provide an alternative that is capable of performing the same task and is safer to use.

Engineering Controls

Provide or construct a physical barrier or guard.

Administrative Controls

Develop policies, procedures practices and guidelines, in consultation with employees, to mitigate the risk. Provide training, instruction and supervision about the hazard.

Personal Protective Equipment

Personal equipment designed to protect the individual from the hazard.

Health & Safety Services

June 2006

RISK ASSESSMENT SUMMARY

Topic:

Identify Hazards and

subsequent Risks

Analyse Risks

Hazards/Issues/Risks

Consequence

Health & Safety Services

June 2006

Date:

Issue No.

Identify and evaluate existing risk controls

Review date:

Further Risk Treatments

Evaluate Risks
Likelihood

Risk
level

What we are doing now to manage this risk.

Effectiveness of our
strategies

New
risk
level

Further action needed

Opportunities for improvement

Courtesy of:
Scitor Corporation
256 Gibraltar Drive Sunnyvale, CA 94089
800/533-9876

Risk is a Four-letter Word, But Denial is our Biggest Enemy:

Risk Management is an Essential Part of Project Portfolio Management
As a practitioner and proselytizer of project management for over 38 years, one thing has
puzzled me above all others. That is; why is risk management virtually ignored as an
integral part of the project management process? We all recognize that risk is an
important part of all projects. If we thought about it, we would all acknowledge that the
management of risk can be the most critical factor in project success. Yet as I look at the
practices that have been put in place in most firms, and at the tools that are being used to
support these practices, risk analysis and management are most often missing.
It's not that the processes and tools are not available, but more of a major lack of interest
in the process. I can provide two stories that might help to explain the perilous avoidance
of this essential practice.

The Downside Won't Happen

A company decided to enter into a new business segment. As was standard practice for
this well managed conglomerate, a business analysis plan was prepared to evaluate the
potential profitability of the new venture. As a normal part of the business plan
procedure, three business cases were analyzed: the most probable case, a potential upside
case, and a potential downside case. All well and good up to here. But then, the general
manager, when presenting the business plan to the board, said this: "Here is the most
likely scenario, a potential upside and a potential downside. However, we can ignore the
downside case because it will never happen".
The company went ahead with the new venture (assuming that it couldn't lose), as the
most likely and upside scenarios predicted a reasonable profit in a reasonable amount of
time. Needless to say, the downside did materialize and the venture failed within two
years.

Denial is our Biggest Enemy

Written by Harvey Levine

Page 1 of 5

Courtesy of:
Scitor Corporation
256 Gibraltar Drive Sunnyvale, CA 94089
800/533-9876

Furthermore, an atmosphere of fear (fear of the truth) brings on such denial. The successminded manager must remove the emotional elements from the business evaluation and
promote methods that require objective analyses of the entire business case. To do
otherwise, puts the liar, the bully, (and the myopic) at an unfair advantage. The result,
understandably, is the improper selection of business opportunities and a deleterious
effect on the corporate bottom line. To put it even more strongly, the failure to select the
best business opportunities may eventually cause the business to loose its market
position, and eventually cause a fatal collapse.
So why, knowing all of this, do we fail to require the objective analysis and management
of risk? It can't be because the process is difficult. Actually there are many approaches
and processes for risk evaluation. All are simple and valid (except for the pain of
admitting that something can go wrong (that denial thing, again). The key thing to realize
is that all of the available approaches are simple, down-to-earth methods, certainly not in
the realm of rocket science. We will discuss these methods in a sequel to this article.
The solution must consist of a total risk management system. Such a system, as part of a
project management system, must contain all of the necessary elements that we would
have in our PM system. This includes a risk management process, tools to support the
risk management process, training in the process and use of the tools, and clear support
for the process at all levels of management. An enlightened, risk management-aware
senior management must demand to see the entire picture (rather than just the good stuff)
and must play the role of the devil's advocate until the entire picture is presented. Yet, in
my experience, executives have done just the opposite. They often give the impression
that they don't want to know the potential downside, or that if they do learn the true risks
that they will squash the proposal (which in many cases would be the proper action). We
must discourage the common environment where we tend to "kill the messenger" of
"bad" news. Under this deleterious environment, we reward those that ignore or hide the
truth and penalize those that are diligent about risk analysis and honest about potential
project risk exposure.

Project Portfolio Management

One of the emerging themes as we approach the end of this decade is "Project Portfolio
Management". Senior management is paying closer attention to the strategic management
of a portfolio of projects, merging project and operations management and all of the tools
and practices associated with both disciplines. Risk management is one of these practices.
Yet, there is one aspect of risk assessment that I have not seen, either in the literature or
in practice. This is the effect of risk on "payback time".
Can we assume that our typical business analysis case will contain a cash flow analysis?
This CFA will show the outflow of money as the project is executed, and the inflow of
money (or the projected cost savings) once the benefits of the project start to be realized.
At some point in time, the cumulative curve will cross from negative territory (having
recouped the investment plus the time-value cost of that money) to where the expected

Written by Harvey Levine

Page 2 of 5

Courtesy of:
Scitor Corporation
256 Gibraltar Drive Sunnyvale, CA 94089
800/533-9876

payback starts to accumulate. Usually, this payback analysis is a key component of the
decision to proceed with the project.
Now, consider this. Let's say that a project was to cost ten thousand dollars per month,
with expected completion in two years. Let's also say that the cost of money is 8% per
year and that the project will generate an income of $10,000 per month, starting
immediately upon completion. The projected payback time would be about 50 months
(from project initiation).
What do you think would happen to the payback time if the project ran just 4 months
over, at a cost overrun of 15 percent per month? The payback time is extended by a
whopping 18 months. If a truthful risk analysis indicated that there was a high probability
of this extension to the payback time, might this be enough to sour the executives on the
value of this project?
Let's further consider that this project was the average IT/IS project that was surveyed by
the Standish Group, several years ago. That survey noted that the average IT/IS project
ran 50% longer than planned at a cost overrun of 186%. If we apply this to our subject
project, it would make it a three year job, at a cost of $686,000 (not including the time
value of the investment). In this case, the payback time would be 99 months. I wonder
how many executives would approve the project, if the risk assessment showed a good
probability that the payback time would be 99 months, rather than 50 months?
The "Effect on payback time" concept is so simple that it can be done on the proverbial
"back of the envelop". I created a simple example in an Excel spreadsheet, in less than an
hour. I am amazed that I rarely see anyone evaluating the effect of delays and cost
overruns on "return on investment". Yet, if we use the Standish data, such an evaluation
would show that the typical project would, based on such performance, extend the
payback time to more than twice the original plan. Of course, this is another example of
downside potential. And in todays business environment, such bad news is more likely
to be swept under the rug, rather than to have the project rejected because of the risk.
Unfortunately, hiding the risk does not prevent it from happening.

Organizing for Managing Project Risk

Projects, executives have come to realize, are the basis for future profitability of the firm.
Hence, there is a rising interest on the part of executives in how projects are selected and
managed. They are precipitating a growing demand for more standardization and
automation of project management. But I do not see the stipulation of a structured
approach toward risk management. There has been some success in getting organizations
to recognize the importance of having some kind of Project Office (among pockets of
resistance). There has been a flood of articles promoting the importance of the project
office (also called: project support office, central project office, project management
competency center, program office, etc.) I, for one, have not only preached this gospel at
every opportunity, but have gone as far as to suggest that the firm have a position of
Chief Project Officer. With CEO's, COO's, CFO's, etc., why not a CPO?

Written by Harvey Levine

Page 1 of 5

Courtesy of:
Sciforma Corporation
http://www.sciforma.com
8 0 0 / 5 3 3 -9 8 7 6

The earlier paper offered some insight into the psychology that traps us from dealing with risk
and suggests a few ways to take control of risk. In this paper, we look at a few additional tricks
to help master risk. One of the aids to risk appraisal is the use of a Risk Breakdown Structure
(RskBS).

A WBS for Risk

An excellent way of structuring a review of risk, and to make sure that potential risk items are
not overlooked, is to use a work breakdown structure model for risk. In the example provided
below, we use the WBS primarily as a structured checklist.
At the first level of the WBS, we list seven categories for risk consideration. These are Time,
People, Costs, Deliverables, Quality, Contract, and Market. Obviously, there can be others. For
each of these categories, we list any areas where there could be a risk issue. For instance; under
the category of Costs, we might ask, Are there any risk issues associated with Escalation,
Estimating Errors, Penalty Exposure, or Exchange Rates? Where did these second-level items
come from? These are areas where issues often arise that impact the cost projections developed
to support the project proposal.
In developing a cost figure, we assume a number for escalation. In the risk assessment exercise,
we have to ask, What is the range of possible escalation on items that are sensitive to such
escalation? Then we ask, What is the effect on cost? We would also probe the project
estimating data, looking for areas that might be sensitive to an estimating error. Is this a risk
item?
Is there a penalty condition in the contract? What risks to cost (or income) does this present? Are
we dealing with multiple currencies? Is there a risk to cost (or income) because of unexpected
exchange rate changes? I personally experienced a major international project where all aspects
of the project were completed with great success and the firm lost money on it because of
significant and damaging changes in the exchange rate.

Using the WBS as a Checklist

Theres a good chance that your project does not have exchange rate or penalty exposure. No
problem! You just cross that off the checklist that the Risk WBS represents. It is much easier to
start with a list of all possible items and to delete those that do not apply, rather than starting out
with a blank sheet of paper (or a blank screen) and trying to think of risk items.
Templates can be developed for each type of common project. The proposal manager deletes
items that dont apply and adds items that are unique to that project. Actually, even better than
deleting non-applicable items is to mark them with an N/A. This serves as an audit trail,
showing that the item was considered.
Some of the second-level items can easily belong in more than one place. This is not important
as long as they show up somewhere and are not overlooked.

Written by Harvey Levine

Page 2 of 5

Courtesy of:
Sciforma Corporation
http://www.sciforma.com
8 0 0 / 5 3 3 -9 8 7 6

Page 5 of 5

RISK BREAKDOWN STRUCTURE (RBS)

Project Risk

External

Internal

Organizational

Customer

Process

Culture

Stability

Planning

Financial

Managerial

Initiation

Communication

Labor

Technology

Environment

Requirements

Culture

Requirements

Physical

Financial

Stability

Regulatory

Contractual

Communication

Social

Performance

Application

Complexity

Limits

Organizational
Experience

Conditions of Use

Technological
Maturity

Skillset required

Uncertainty

Costs

Physical
Resources

Execution

Control

This RBS is meant to provide guidance on risk identification. It is not meant to be all
inclusive and there may be project risk categories not included on it. Please ensure
stakeholder and subject matter expert participation when conducting risk
identification and consider ALL project risks.

RPM204v0607
2007 Seattle Childrens Hospital Research Institute

Lecture # 26
PRM 702
Project Quality and Risk Management
Ghazala Amin

Three Definitions
Risk
A possible future event which if it occurs will
lead to an undesirable outcome.

Project Risk
The cumulative effect of the chances of an
uncertain occurrence that will adversely affect
project objectives.

Risk Management
A systematic and explicit approach for
identifying, quantifying, and controlling project
risk.

What is Risk?
Risk and uncertainty are
equivalent

DEFINITION
PROJECT RISK MANAGEMENT IS THE ART AND SCIENCE OF
IDENTIFYING, ASSESSING, AND RESPONDING TO PROJECT
RISK THROUGHOUT THE LIFE OF A PROJECT AND IN THE
BEST INTERESTS OF ITS OBJECTIVES
PROJECT RISK IS THE CUMULATIVE EFFECT OF THE CHANCES OF
UNCERTAIN OCCURRENCES ADVERSELY AFFECTING PROJECT
OBJECTIVES

ISSUES

RISK MANAGEMENT PURPOSE

IDENTIFY FACTORS THAT ARE LIKELY TO IMPACT THE PROJECT
OBJECTIVES OF SCOPE, QUALITY, COST AND TIME

A RISK SHOULD ONLY BE TAKEN WHEN THE POTENTIAL BENEFIT AND

CHANCES OF WINNING EXCEED THE REMEDIAL COST OF AN
UNSUCCESSFUL DECISION AND CHANCES OF LOSING BY A
SATISFACTORY MARGIN

QUANTIFY THE LIKELY IMPACT OF EACH FACTOR

GIVE A BASELINE FOR PROJECT NON-CONTROLLABLES
MITIGATE IMPACTS BY EXERCISING INFLUENCE OVER PROJECT
CONTROLLABLES
THE PMBOK ALSO POINTS OUT THAT RISK MANAGEMENT INCLUDES
MAXIMIZING THE RESULTS OF POSITIVE EVENTS AND MINIMIZING THE
CONSEQUENCES OF ADVERSE EVENTS.

NATURE OF RISK MANAGEMENT

WHEN SPEAKING OF RISK, THINK OF ONLY HAZARDOUS ONES
EVERYDAY COMMON DAY ONES ARE IGNORED

WHAT WILL BE GAINED?

WHAT COULD BE LOST?
WHAT ARE THE CHANCES OF SUCCESS (AND FAILURE)?
WHAT CAN BE DONE IF THE DESIRED RESULT IS NOT ACHIEVED?
IS THE POTENTIAL REWARD WORTH THE RISK?
POTENTIAL FREQUENCY OF LOSS
AMOUNT AND RELIABILITY OF INFORMATION AVAILABLE
POTENTIAL SEVERITY OF LOSS
MANAGEABILITY OF THE RISK
VIVIDNESS OF THE CONSEQUENCES
POTENTIAL FOR (ADVERSE) PUBLICITY
WHOSE MONEY IS IT?

PROJECT RISK MGMT IS PRO-ACTIVE

CLASSIC SYSTEMS METHODOLOGY:
INPUT

PROCESS

OUTPUT

RARELY DO WE SYSTEMATICALLY IDENTIFY ALL RISKS INVOLVED

HOWEVER, INCLINED TO CONSIDER RISK DIFFERENTLY RELATIVE TO
FAMILY - VERY PRECIOUS AND LOTS OF POTENTIAL
EXAMPLES:
SMALL CHILDREN - STAY AWAY FROM ROAD
HOW DID DAY GO? - DO MORE TO HELP THEM

FEEDBACK LOOP
THIS PROCESS VITAL TO EFFECTIVE PROJECT CONTROL, HOWEVER

- RISK ID & AVOIDANCE

- INFO FEEDBACK

THESE ACTIONS ARE ESTABLISHING THE BASIC ELEMENTS OF

MANAGING PROJECT RISK INTO OUR CHILDREN

RISK IS DIFFERENT - - HAS TO DO WITH:

UNCERTAINTY, PROBABILITY OR UNPREDICTABILITY, AND
CONTINGENT PLANNING

REACTIVE vs. PRO-ACTIVE

Positive and Negative Risk
CRISIS MANAGEMENT -- REACTIVE MODE -- SELECT RESPONSE
PRO-ACTIVE -- ANTICIPATE AND PLAN TO AVOID

Opportunities - Positive outcome

Threats - Negative outcome

RISK & DECISION MAKING:

TAKE RISK IF POTENTIAL BENEFIT AND CHANCE OF WINNING
EXCEEDS COST OF UNSUCCESSFUL DECISION AND CHANCES OF
LOSING BY A SATISFACTORY MARGIN (CLASSIC COST / BENEFIT
ANALYSIS)

Benefits of Risk Management

More and better information is available
during planning and decision making
Project objectives are verified
Improved communications
Higher probability of project success
Proactive approach
Project might be canceled

Why Organizations dont do

Risk Management
Unwillingness to admit risks exist
Postpone the hard parts of the project until
later
Risk management costs money
Up front investment of time
Cant prove its necessary
Think health insurance

Why Organizations dont do

Risk Management

Ways to Avoid
Risk Management

Can Do management style severely

inhibits risk management
Risk identification can make you look like a
whiner

Managing risk is everybodys business

There is only one risk: The project might
fail. And were managing that by working
real hard to assure that doesnt happen.

The Uncertainty Spectrum

Project Risk

NO
Information

Partial
Information

(Unknown
unknowns)

(Known
unknowns)

GENERAL
TOTAL
UNCERTAINTY UNCERTAINTY

SPECIFIC
UNCERTAINTY

Complete
Information

Integration
Communication
Scope

(Knowns)

TOTAL
CERTAINTY

Time

Project Risk

Quality

Procurement

SCOPE OF PROJECT RISK MANAGEMENT*

Human Resources
*Note: in this range the information to be sought is known

Cost

INTEGRATING RISK
PROJECT
MANAGEMENT
INTEGRATION

Life Cycle and

Environment Variables

SCOPE

Requirements
Standards

PROJECT
RISK

Time Objectives,
Restraints

TIME

INFORMATION /
COMMUNICATIONS

A subset of project management that

includes the processes concerned with
identifying, analyzing, and responding to
project risk.

Ideas, Directives,
Data Exchange Accuracy

Expectations
Feasibility

QUALITY

Project Risk Management

Availability
Productivity

HUMAN
RESOURCES

Services, Plant, Materials:

Performance

Cost Objectives,
Restraints

CONTRACT /
PROCUREMENT

COST

Risk Management Objectives

Reduce the number of surprise events
Minimize consequences of adverse events
Maximize the results of positive events

Risk Classification

Business risks vs. pure (insurable) risks

Classified by uncertainty (business risks)
Classified by impact on project elements
Classified by their nature
Classified by their source
Classified by their probability to occur and
amount at stake

Consequences of Risk Analysis

Positives

Negatives

greater information is made available during the

course of planning and decision making
project objectives are verified
better communications
better probability that project realization will be
optimal
increased chance of project success

Some Considerations
Real information is the key.
The relationship between uncertainty and
information is inverse.
For the project manager, conditions of relative
uncertainty (partial information) are the rule.
There is a natural resistance to formal risk
analysis.
Risks should only be taken to achieve a project
objective.

belief that all risks have been accounted for

project could be shut down

SUMMARY
PROJECTS ARE LAUNCHED TO TAKE ADVANTAGE OF OPPORTUNITIES,
BUT OPPORTUNITIES ARE ASSOCIATED WITH UNCERTAINTIES WHICH
HAVE RISKS ATTACHED
RISK CAN NEVER BE 100% ELIMINATED
FOR THE PROJECT TO BE VIABLE, THE EXPECTED VALUE RESULTING
FROM A FAVORABLE PROBABILITY OF GAIN MUST BE HIGHER THAN
THE CONSEQUENCES AND PROBABILITY OF LOSS
THEREFORE, THE RISKS ASSOCIATED WITH A PROJECT MUST RECEIVE
CAREFUL EXAMINATION IN THE CONTEXT OF THE ORGANIZATION'S
WILLINGNESS OR AVERSION TO TAKING RISKS
THIS IS THE DOMAIN OF PROJECT RISK MANAGEMENT, WHICH FORMS
A VITAL AND INTEGRAL PART OF PROJECT MANAGEMENT

When Should Risk Assessments

be Carried Out?
Risk assessments should be carried out
as early as possible and then continuously.

Dont take the risk if...

the risk does not achieve the project objective.
the expected value from baseline assumptions is
negative.
the data is unorganized, without structure or
pattern.
there is not enough data to understand the results.
a contingency plan for recovery is not in place
should the results prove unsatisfactory.

Dont take the risk if...

the organization cannot afford to lose.

the exposure to the outcome is too great.
the situation (or project) is not worth it.
the odds are not in the projects favor.
the benefits are not clearly identified.
there appear to be a large number of acceptable
alternatives.

PRM 702
Project Risk Management
Lecture #27

Project Risk Management

What to Study
Risks with various qualifiers
The three components of risk: Risk Event,
Probability of Risk Event and Impact of Risk
Probability-Impact Matrix
Risk assessment using decision trees and
expected monetary values
The relationship of risk and the project life cycle

PMIs Project Risk Management Processes

Ghazala Amin

Project Risk Management

Reference study materials
A guide to the Project Management Body of
Knowledge (PMBOK Guide), Chapter 11
Study notes
Dr. Kerzners book, Chapter 17

Key Definitions
Certainty, Risk, Uncertainty
Business Risk, Insurable(Pure) Risk
Technical Risks, Project Management Risks,
Organizational Risks, External Risks, Internal Risks,,
Legal Risks
Known Risks, Unknown Risks
Expected Monetary Value (EMV)
Trigger (a.k.a Risk symptom or Warning sign)
Contingency Plan, Fallback Plan
Contingency Reserve, Management Reserve
Delphi technique
Workaround

Project Risk Management

What is a risk?
A risk is a potential event or a future situation that may negatively affect
the project.

Risk Management process include:

Formal planning activity,
Analysis to quantify the likelihood and predict impact on
the project,
Handling strategy for selected risks,
Ability to monitor progress in reducing these risk to the
level to minimize impact on the project.

Risks are identified, described and analyzed in terms of;

Probability that they will occur
Effects or consequences if they do happen
Time frame within which their consequences might occur
Examples of few risks to the project;
Technology not easily available
Resources not committed to the project
Sponsor does not show up for meetings
Unidentified end users etc. etc.

Source/Reference: IBM Learning Centre for development of PM Curriculum

Project Risk Management

Risk Management is the systematic process of
identifying, analyzing, and responding to project risk

Project Risk Management Processes (PMBOK)

It is continuous process of identifying, analyzing,

and planning for risks.
It is the most effective means of preventing and/or
minimizing exposure to your project.

Plan Risk Management

Risk Identification
Qualitative Risk Analysis
Quantitative Risk Analysis
Risk Response Planning
Risk Monitoring and Control

Risks associated with project integration are usually the smallest during the projects
initiation and charter approval phase of the project life cycle.
6

Types of Risk Takers

Project Risk Management Processes (PMBOK)

Process Groups Initiation

Planning

Execution

Control

Closing

Knowledge Areas

Risk
Management

Risk
Managemen
t Planning

Risk
Monitoring
and
Control

Risk
Identificatio
n
Qualitative Risk
analysis
Quantitative
Risk
analysis
Risk Response
Planning

Project Risk Management is the process of being proactive rather than reactive.

Risk Averter (Risk Avoider)

Utility rises at the decreasing rate
When more money is at stake, project managers
satisfaction or tolerance decreases
Prefers certain outcome and demand premium to
accept risks.
Risk Neutral
The slope of utility curve is constant
Risk Seeker (Risk Lover)
The utility rises at the increasing rate
The project managers satisfaction increases
when more money is at stake
Prefers uncertain outcome and willing to pay
penalty to take risks

Risk - Definitions
Risk Preference and Utility Theory

Decision making falls into the following categories:

Utility which can be defined as the amount of

satisfaction or pleasure that the project manager
receives from a payoff (This is also called project
managers tolerance for risk).

Certainty
All information for making the right decision is available
Can predict the outcome with confidence

Risk
The totality of the occurrence can be described within
established confidence limit
Expected payoff can be mathematically calculated

PM must use expert judgment and tools to deal with risks.

The ultimate decision on how the PM deals with risk is
based on his/her own tolerance for risk.

Uncertainty
Meaningful assignments of probabilities are not possible
Management decision can be made applying one of 4
criteria
10

Decision Making Under

Uncertainty

Decision Making Under Risk: Expected Value

Hurwicz Criterion (Maximax)

The decision maker is always optimistic and attempts to
maximize profits by a go-for-broke strategy

Expected value is the product of two numbers:

Risk Event Probability (states of nature)

Wald Criterion (Maximin)

An estimate of the probability that a given risk

event will occur.

The decision maker is concerned with how much he/she

can afford to lose. In this criteria, a pessimistic approach
is taken

Risk Event Value (Payoff for strategies)

Savage Criterion (Minimax)

An estimate of the gain or loss that will be

incurred if the risk event does occur.

The project manager attempts to minimize the maximum

regrets

Laplace Criterion
13

Decision Making Under Risk: Expected Value

Decision Trees

Expected monetary value

Mathematically:

A decision tree is a diagram that depicts key

interactions among decisions and associated
chance events as they are understood by the
decision makers
The branches of the tree represent either
decisions (shown as boxes) or chance events
(shown as circles)

E i =j =1 Pij pj,
Where
E i = expected payoff for strategy i
P = Payoff element
p = Probability of event
E 1 = (50)(0.25)+40(0.25)+90(0.5) = 67.50
E 2 = (50)(0.25)+50(0.25)+60(0.5) = 55
E 3 = (100)(0.25)+80(0.25)+(-50)(0.5) = 20
Based on the Expected payoff value, Strategy 1 should
be used.

Transforms decision making under uncertainty into

decision making under risk

Decision Tree - Example

A product can be manufactured using Machine A or

Machine B
Machine A has a 40% chance of being used and
Machine B has a 60% chance of being used
When Machine A is selected, Process C is selected
80% of the time and Process D 20% of the time
When Machine B is selected, Process C is selected
30% of the time and Process D 70% of the time
What is the probability of being produced by the
various combinations?
17

Decision Tree - Example

PRM 702
Project Risk Management
Lecture #28

Plan Risk Management

Inputs
Project scope statement
Cost management plan
Schedule management plan
Communications management plan
Enterprise environmental factors
Organizational process assets

PMIs Project Risk Management Processes

II of II
Ghazala Amin

Plan Risk Management

Tools & techniques

Risk management planning is the process of

deciding how to approach and plan the risk
management activities for a project.

Planning meetings and analysis

The process of developing and documenting an

organized, comprehensive and interactive strategy
and methods
for identifying and analyzing risks,
developing risk response plans,
and monitoring and controlling how risks have changed.

Plan Risk Management

Inputs

Outputs

Risk management plan

Risk Identification

Risk management plan

Activity cost estimates
Activity duration estimates
Scope baselines
Stake holder baseline
Cost management plan
Schedule management plan
Quality management plan
Project planning documents
Enterprise environmental factors
Organizational process assets

Risk Identification

Tools & techniques

Involves determining which risks might affect

the project and documenting their
characteristics.

The process of examining

the program areas and each critical technical
process
to identify and
document the associated risk.
6

Documentation reviews
Information gathering techniques
Checklists analysis
Assumption analysis
Diagramming techniques
Expert judgment
SWOT Analysis

Qualitative Risk Analysis

Risk Identification

Outputs

The process of assessing the impact and

likelihood of identified risks

Risks register

Plan Risk Analysis

Risk analysis includes

Evaluating
Probability that a risk would occur
Impact of the risk if it occurs
Time frame in which it might occur
Frequency of risk occurrence
Prioritizing
Prioritize to ensure right amount of
management attention

Qualitative Risk Analysis

The process of examining each identified risk

Inputs
Risk register
Risk management plan
Project scope statement
Organizational process assets

Estimate the probability

And predict the impact on the project.

It includes:
Qualitative Risk Analysis
Quantitative Risk Analysis
10

Qualitative Risk Analysis

Risk Rating System

High

Tools & Techniques

Likely to cause significant disruption to schedule,

increase in cost or degradation of performance

Risk probability and impact

Probability and impact matrix
Risk data quality assessment
Risk categorization
Risk urgency assessment
Expert judgment

Moderate
Has potential to cause some disruption as above,
will probably overcome difficulties

Low
Has little potential to cause disruption to
schedule, cost or degradation of performance
13

Qualitative Risk Analysis

Quantitative Risk Analysis

Outputs

Aims to analyze numerically the probability of

each risk and its consequence on project
objectives

Risk register updates

Quantitative Risk Analysis

Outputs

Inputs

Risk register updates

Risk management plan

Risk register
Cost management plan
Schedule management plan
Organizational process assets

Risk Response Planning

Quantitative Risk Analysis

Process of developing options and determining

actions to enhance opportunities and reduce threats
to the projects objectives
The process that:

Tools and Techniques

Data gathering and representation techniques
Quantitative risk analysis and modeling techniques
Expert judgment

identifies, evaluates, selects and implements

one or more strategies,
in order to set risk at acceptable levels given program
constraints and objectives.

This includes the specifics on

What should be done

When it should be accomplished
Who is responsible
And associated cost and schedule.

Risk Response Planning

Risk response options include:

Risk Response Planning

Inputs

Acceptance
Avoidance
Mitigation
Transfer

Risk management plan

Risk register

Risk Response Planning

Opportunity response options include:

Acceptance
Enhance
Exploit
Share

Tools & Techniques

Strategies for negative risks or threats
Strategies for positive risks or opportunities
Contingent response strategies
Expert judgment

Risk Response Planning

Reserves

Outputs
Management Reserve

Risk register updates

Risk related contract decisions
Project management plan updates
Project document updates

A separately planned quantity used to allow for

future situations which are impossible to predict
Also known as unknown unknowns
May involve cost, schedule or both

Insurance Strategies

Reserves

Contingency Reserve
A separately planned quantity used to allow for
future situations which may be planned for only in
part
Also known as known unknowns
May involve cost, schedule or both

Direct Property Damage

Indirect Consequential Loss
Legal Liability
Personnel

Risk Monitoring and Control

Inputs

Outputs

Risk register
Project management plan
Work performance information
Performance reports

Risk register updates

Organizational process assets updates
Change requests
Project management plan updates
Project document updates

Risk Monitoring and Control

Tools & Techniques
Risk reassessment
Risk audits
Variance and trend analysis
Reserve analysis
Technical performance measurement
Status meetings

Published in PM World Today -November 2006 (Vol. VIII, Issue 11) "Connecting the World of Project Management"

PM World Today Tips & Techniques November, 2006

Establishing a Risk Reserve

By Daniel Galorath
A Risk Reserve is the additional amount of time, money, or personnel required to
fund mitigation activities that will take a program to successful completion. A risk
reserve may be built into the estimates by setting the probability within parametric
models. When the estimate is allocated to specific activities and elements of a
project and the associated costs are accounted for and budgeted through the work
breakdown structure, a reserve should be established to address potential problems.
The project manager should use a disciplined and comprehensive method to assess
project risk in the estimate. Estimates of the required reserve should be defined
and quantified throughout a projects life cycle as specific risk elements that can be
used to provide adequate risk reserves.
By keeping and managing a risk reserve, an organization can fund mitigation
activities and react to risks that transition to problems. Management must
understand that the processes and costs associated with risk management are
extremely cost-effective, while the cost of mitigation can be significant. When the
cost of risk management is balanced against the cost of mitigation, both in dollars
and reputation, risk management is a bargain.
A risk reserve should be managed and always address reality. The risk officer
should offset the projected cost of mitigation by the number of risks and then
recommend a reserve to management based on these calculations. The reserve
should account for unanticipated or worst case risks and be stated as one of three
ranges: optimistic, most likely, and pessimistic. The risk reserve should include the
costs of the resources required to identify and manage critical and high risk areas
and also include all projected estimates through risk resolution. The reserve should
be a true management asset owned by the manager and it should include funds,
resources, and potential staff required to address risks and their potential effects.
Management should frequently reassess the reserve, identify resources allocated to
handle contingencies, and adjust the amount to account for mitigation costs.
Management should also frequently analyze new requirements for the reserve,
manage requirements creep, and account for potential expansion of work and its
cost and schedule impacts. The risk reserve should be reevaluated and updated as
risk assessments occur and account for such factors as:

Time Add to the schedule a percent above the estimated time to delivery
based on risk of delivery.
Money Increase budget to include potential additional staff, tools, and time
to potential project costs.

PM World Today is a free monthly publication of pmforum.org - http://www.pmforum.org

Page 1

Published in PM World Today -November 2006 (Vol. VIII, Issue 11) "Connecting the World of Project Management"

Staff and potential staff The personnel organization should continue to

interview for good people and establish second sources for single point staff
risks.
Resources Identify second sources and mitigate key resource risks.

Daniel Galorath

Daniel D. Galorath has over 35 years of experience in the

software industry where he has solved a variety of management,
costing, systems, and software problems, and performed all
aspects of software development and management. Mr. Galorath
is founder and president of Galorath Incorporated, maker of the
SEER; suite of estimation tools; Mr. Galorath is one of the
principal developers of the SEER-SEM; Software Estimation
Model. Mr. Galorath completed his undergraduate work and MBA
from California State Universities. He is a member of the
International Society of Parametric Analysis (ISPA), Society of
Cost Estimation and Analysis (SCEA), IEEE, the International
Function Point Users Group (IFPUG), and the Association of
Computing Machinery (ACM). He was honored with the Freiman
Award, recognizing his long-term contributions to the field of
parametric analysis. Mr. Galorath teaches courses in software
cost, schedule, and risk analysis; software project management;
software engineering; systems architecture, and other related
topics. He has lectured internationally and is the author of many
papers about software project management. Mr. Galorath can be
reached at: [email protected]
His website is www.galorath.com

PM World Today is a free monthly publication of pmforum.org - http://www.pmforum.org

Page 2

Published in PM World Today - November 2006 (Vol. VIII, Issue 11) "Connecting the World of Project Management"

PM World Today Tips and Techniques November 2006

How to Reduce Risk in Project Schedules and Portfolios

By Sarim Khan
Even the best-planned projects go wrong: every project manager knows that.
Unexpectedly, from leftfield, comes a curveballleaving plans, budgets and
timescales in tatters.
But it doesnt have to be that way. Unexpected isnt the same as
unimaginable, or inconceivable. For all too often, the things that go wrong in
projects could have been foreseen as at least possibilities: in many projects,
adverse factors such as bad weather, supplier unreliability and technical delays
are ever-present dangers.
What is often lacking, though, is a way of mitigating against these risksand
doing so cost-effectively. For mitigating against risk, or uncertainty, inevitably
consumes resources and adds to project cost: protecting a project budget or
timescale from every possibility that may impact it can quickly cause costs to
balloon. The result? A budget that was once considered affordable becomes
unimaginably expensivewith scarce resources expended for guarding against
unlikely events that did not in fact occur.
So is there a solution? The answer is yesand perhaps surprisingly, it is a
solution that has its roots in that most fundamental of project planning
constructs, the project network. By incorporating risk and uncertainty
parameters with respect to the individual activities within the network, and then
applying advanced simulation techniques to extrapolate the potential outcomes,
project managers can create a precise picture of where mitigation will be most
effective.
The result: a better understanding of the real risks that projects faceand
resources intelligently expended on mitigating against risks where the probability
of occurrence, and the consequences, are clearly understood. So instead of a
scattergun approach to project plan protectionblasting resources off in the
hope that effective protection will resultprojects managers can deploy a
snipers rifle, clearly targeting identified risks and uncertainties.
The basics arent complicated. Logically, every activity on the project network is
affected by uncertainty. It might cost this muchor it might cost that much.
Theres a range of possible cost outcomes, in other words. Likewise with
timescales: at best, an activity might take this longand at worst, that long. So
plug these ranges into the project network, as parameters associated with each
activity.
Risks are treated in a similar manner. An activity may be deemed to be at risk
of being affected by an identifiable discrete eventsuch as bad weatheror it
may not. That risk, in turn, has consequencescost increases, or timescale
overruns, for example. So if an activity or group of activities is deemed to be at

PM World Today is a free monthly publication of pmforum.org - http://www.pmforum.org

Page 1

Published in PM World Today - November 2006 (Vol. VIII, Issue 11) "Connecting the World of Project Management"

risk, plug that risk into the network as wellas an appropriate percentage
probability as judged by the team in risk workshops.
The resulting network, with risk and uncertainty parameters attached, can then
be modelled. At a basic level, the process of simply constructing the model
yields valuable insights. It might be discovered that most of the risk occurs in
the latter stages of the project, for example, or in a particular branch of the
network. At the very least, it is possible to quantify the number of risks that a
project faces, at which stages in the project they might impact, and the range of
possible project cost and timescale outcomes. This in itself is no mean feat,
given the cumulative nature of project activities, and their linked
interdependencies.
But the real payback comes from simulation. Advanced probability-based Monte
Carlo mathematical modelling techniques and tools can run potentially many
hundreds or even thousands of individual simulations, building up a picture of
the projects risk profile.
The result? Businesses are able to determine, with considerable certainty, both
the most likely risks affecting their overall project, as well as the risks with the
greatest consequences.
This information can be leveraged in a number of ways. Although there are no
hard and fast rules on how to treat such insights, many project managers
typically choose to create a list of the Top 10' risks faced by a project.
Alternatively, through a process of weightings, the most likely risks and the risks
with the greatest consequences can be combined in order to create whats
known as the projects risk exposureanother common technique.
At this point, the most significant benefits of the process can be realized. For a
start, there is an opportunity to manage expectations better. From our
observations, it seems that the sponsors of many high-profile project failures
the sort of IT, aerospace or construction disasters that appear on our
newspapers front pageshad no idea how risky their projects were, or where
those risks lay.
Yet more importantly, there is a major opportunity to actually manage those risk
scenarios better. One obviousand highly cost-effectiveway of doing this is
through closer monitoring of the risk areas. But there is also an opportunity to
deploy that snipers rifle, to apply resources in a focused manner to mitigate
against specific risks. In itself, this can prove a powerful reality check: if
mitigation resources are being applied to areas not on the list of critical Top 10'
risks, for instance, its time to ask some pointed questions as to why.
Indeed, we often find that there may bea disconnect between mitigation
resources and risk areasboth at the project level, and the portfolio level. Are
resources being allocated on the basis of risk, for exampleor on the basis of
quieting those who are shouting loudest? Is the level of mitigation preciselycalculated to be appropriate to the exposureor is it a figure plucked from the
air, with no real sense as to whether it is adequate, or represents good value for
money? Such questions can yield significant savings, as well as sharply

PM World Today is a free monthly publication of pmforum.org - http://www.pmforum.org

Page 2

Published in PM World Today - November 2006 (Vol. VIII, Issue 11) "Connecting the World of Project Management"

improving project performance in terms of meeting budget and timescale

expectations.
At the level of the entire portfolio of projects within an enterprise, the same kind
of opportunity arises. Typically, for example, we see that the largest projects
have the greatest resource reserve set aside for mitigation. Logical, perhaps.
But it is more logical, and far more cost-effective, to allocate the largest
reserves to the riskiest projects. Indeed, several of our customers have
experienced significant overall reductions in the extent of the resources that
they must set aside for project mitigation, precisely for this reason.
In short, it is possible to treat project risks and uncertainly far more intelligently
than is often the case. And in a project-oriented world, where resource
constraints are an ever-present fact of life, that intelligence can make an
enormous difference to project success.

Sarim Khan

Sarim Khan is CEO of PertMaster, a provider of risk and

analytics software for Project Portfolio Management (PPM)
environments, with a focus on oil & gas exploration,
engineering, manufacturing, construction, aerospace,
defence and governmental industries. Mr. Khan manages
and holds responsibility for all aspects of PertMasters
public business and technology strategies. He has over 12
years experience in the decision analytics software
industry and has previously held management and
executive positions at SPSS Inc., SAS Institute, Windmill
Solutions and Jobpartners. Mr. Khan has worked closely
with many Fortune 500 companies to better apply
predictive risk and analytics solutions -- enabling clients to
win and deliver profitable real-life projects. Sarim is a
member of PMI and the Association of Project
Management (APM) in the UK. He has lived in Dubai, UAE
for the last 3 years, and holds a BSc (Management
Sciences, Operational Research) from Lancaster University
Management School, UK. Sarim can be reached at
[email protected]

PM World Today is a free monthly publication of pmforum.org - http://www.pmforum.org

Page 3

Risk Avoidance and

Management for
Infrastructure Projects
London Superconference
May 2006

Risk Avoidance and Management

for Infrastructure Projects
Complex projects demand the latest project management techniques to maintain
timely and proper completion. This session will discuss recent developments with
CAD Modeling, Scheduling and Management tools used to assist modern
management of large, complex projects. The panel will also discuss the
importance of clear contract language requiring proper modeling, scheduling and
overall management of the project. The legal and contractual issues related to
avoiding default termination will also be discussed.
All Engineering and Construction undertakings involve risk. Some are insurable,
some are avoidable and some can only be managed. The panel will outline key
elements of risk that can be avoided by good management practice, identify the
insurable elements and outline the management, schedule and cost elements of
risk on infrastructure projects including State-of-the-Art data banks, project
websites and advanced CAD models. The panel will draw examples from recent
projects to highlight pitfalls to risk resulting from failure to properly identify
execution risk elements and their impact.

Definition

Risk Management is the process of measuring or assessing risk and then

developing strategies to manage the risk. In general, the strategies
employed include transferring the risk to another party, avoiding the risk,
reducing the negative effect of the risk, and accepting some or all of the
consequences of a particular risk. Traditional risk management focuses on
risks stemming from physical or legal causes (e.g. natural disasters or fires,
accidents, death, and lawsuits). Financial risk management, on the other
hand, focuses on risks that can be managed using traded financial
instruments. Intangible risk management focuses on the risks associated
with human capital, such as knowledge risk, relationship risk, and
engagement-process risk. Regardless of the type of risk management, all
large corporations have risk management teams and small groups and
corporations practice informal, if not formal, risk management.
*Definition taken from Wikipedia.org

Definition

Intangible risk management identifies a new type of risk- a risk that has 100%
probability of occurring but is ignored by the organization due to lack of
identification ability. For example, knowledge risk occurs when deficient
knowledge is applied. Relationships risk occurs when collaboration
ineffectiveness occurs. Process-engagement risk occurs when operational
ineffectiveness occurs. These risks directly reduce the productivity of
knowledge workers, decrease cost effectiveness, profitability, service, quality,
reputation, brand value, and earnings quality. Intangible risk management
allows risk management to create immediate value from the identification and
reduction of risks that reduce productivity.

*definition taken from Wikipedia.org

Case Study:

Boston Central Artery

(Automated Highway Control System)

Circa 1992 HUB & Spoke Computer Architecture

Central Computer Control and Display System
Twenty-two integrated subsystems
Phase 1 Contractor installs limited scope system
Phase 2 Contractor builds out final system
- Specification requires current technology
- Schedule
- Phase 1 planned completion - July 1998
- Phase 2 start June 1999
- Completion - February 2005

Case Study (Contd)

Phase 2 Contract Construction Interfaces

Approx. fourty roadway construction contracts
The interfaces consist of:

Road sections
Bridge Sections
Tunnel Sections
Installed power systems
Installed conduit systems

Central Command and Control Center

Case Study (Contd)

Construction Problems

Progress of the interfacing contractors

Uncoordinated conduit and power systems
Contractor work crew interference
Late progress from other contractors
Delayed approval of shop drawing
submissions for Phase 2 equipment
Impossibility of Performance?

Sources of Risk

Contract
Design
Bidding
Construction
Operation

Contractual Risks
Deficiencies/Current Standard
Contracts
Impact of CAD Modeling
Owner Acceleration
Delay Claims

New Contract Requirements

Warning Signs
Default/Termination Issues

New Contract Requirements

Data Exchange Addendum to General
Contract
Clearly defined Information Transfer
and Security responsibilities
Software & System compliance
Promote Collaboration
One party designated to manage the
Exchange Process

Contract Requirements cont.

Define Documents to be accepted
electronically (drawings, models, shop
drawings, change orders, RFIs, etc.)
Version Control and Depository
Reciprocal Indemnity Obligations for failures
and violations
Insurance and Bonding requirements
Determine PriorityHard Copies versus
Electronic Media Files

Design Risks
Programming
Site Selection
Geotechnical Survey

Schematic
Scope Definition and Control

Detailed Design

Engineers Design Estimate

Concept for Work Execution
Schedule for Execution of Work
CAD Models

Bidding
Estimate Development
Estimating Accuracy
Schematic Design: -20% to +20%
Design Development: -15% to +15%
Construction Documents: -10% to +10%

Drawings
Specifications

Scope Translation

Construction

Schedule (Programme) Development

Schedule Contingency
Cost Control
Estimate contingency
CAD Modeling Impact
Contractual Issues/Interface

Potential Risk Treatment

Transfer
Avoidance
Reduction (aka Mitigation)
Acceptance (aka Retention)

Risk Transfer
Means causing another party to accept the risk, typically
by contract or by hedging. Insurance is one type of risk
transfer that uses contracts. Other times it may involve
contract language that transfers a risk to another party
without the payment of an insurance premium. Liability
among construction or other contractors is very often
transferred this way. On the other hand, taking offsetting
positions in derivatives is typically how firms use hedging
to financially manage risk.
* Taken from Wikipedia.org

Risk Reduction
Modern software development methodologies reduce risk
by developing and delivering software incrementally.
Early methodologies suffered from the fact that they only
delivered software in the final phase of development; any
problems encountered in earlier phases meant costly
rework and often jeopardized the whole project. A current
trend in software development, spearheaded by the
Extreme Programming community, is to reduce the size of
increments to the smallest size possible, sometimes as
little as one week is allocated to an increment.
* Taken from Wikipedia.org

Warning Signs To Owner

Delays and scheduling problems

Missed Milestone Dates
Defective workmanship
Unresolved design/technical problems
Excessive number of RFIs
Excessive Change Order requests
Non-conforming materials and equipment
Inadequate labor force on site

Warning Signs To Owner

Inaccessibility or Turnover in Contractor's
Project team
Unexplained removal of Equipment from site
Accidents and Safety problems
Delayed payment of Subcontractors
Subcontractor Liens
Unsupported Claims by Contractor

Warning Signs To Contractor

Late/Defective Design
Late Payment v. Progress
Disputed Change Orders/Payment
Schedule Confusion
Field Coordination Problems
Excessive Requests For Information
Late/Defective Owner supplied materials or
equipment
Unresolved Unforeseen Conditions
Qualifications/Turnover of owners project personnel
Absence of Owners Maintenance/Operations team

To Terminate or Not to
Terminate
Review adequacy of supporting documentation
Check reliability of information sources
Evaluate the impact of termination on the overall
Project:

Completion Options
Percentage of Project completion
Lender requirements
Dates for turnover to key tenants
Industry conditions availability of a Replacement
Contractor and adequate Labor
Status of long lead-time items
Ability to retain key Subcontractors/Suppliers

Owner Post-Termination
Issues
Determine Best Completion Option
Assume Subcontracts and Purchase Orders
(Owners option)

Take possession of Materials and Equipment

Notify the Surety
Notify Lender and other key parties

Operation

Training
Operability
Maintainability
Reliability

What if the Termination is

Wrongful?
Owner's Potential Legal Exposure
Contractor's Damages different theories:
Expectancy damages (contractor in same position if
contract had been performed)
Unpaid costs plus anticipated profits
Other Consequential Damages Overhead, Lost Financing

Reliance Damages (contractor in same position if

contract had been performed with or without a
contract)
Unpaid costs and profit (not limited by contract)

Restitution Damages Owners unjust enrichment

Quantum MeruitEquitable Compensation

Contractors Response to
Termination
Substantial Performance by Contractor
Improper Notice of Termination
Failure to allow Contractor a
reasonable opportunity to Cure
Project Design Problems
Differing Site Conditions

Contractors Response to
Termination
Owner Interference failure to
"cooperate"
Improper/Inadequate Contract
Administration by Owner
Impossibility/Impracticability of
Performance
Disguised Termination for Convenience

Recognizing Risk

Outside Environmental Factors

Changing Technology
Process Design Failure
Bad Management

Thanks for Coming!

Our Speakers:
Gary A. Wilson, Esquire
Robert C. McCue, P.E.

Slides available for download at

www.MDCSystems.com

Contact Us!
Post & Schell PC
Gary Wilson, Esquire
Four Penn Center
1600 John F. Kennedy Boulevard
Philadelphia, PA 19103
T. 215.587.1000
www.PostSchell.com

MDCSystems
Robert C. McCue, P.E.
300 Berwyn Park, Suite 115
Berwyn PA 19312
T. 610.640.9600
www.MDCSystems.com

PROJECT RISK
MANAGEMENT

STUDY NOTES
PMBOK 2000 based, Version 6

In Preparation For
PMP Certification Exam

IBM Education and Training

Worldwide Certified Material

Publishing Information
This publication has been produced using Lotus Word Pro 96.

July 2002 Edition

Project Risk Management

Study Notes

Reference Material to study:

A Guide to the Project Management Body of Knowledge (PMBOK Guide), Chapter 11
(2000 edition)
Project and Program Risk Management, A Guide to Managing Project Risks and
Opportunities, PMI, Edited by R. Max Wideman, 1992
Project Management, A Managerial Approach, Meridith, Jack R. 1995, Chapter 2, 2.4
PMP Exam Practice Test and Study Guide, 4th Edition, by Ward, J. LeRoy, PMP ,
2001
PMP Exam Prep, 3rd Edition, by Mulcahy, Rita, PMP, 2001
ESI PMP Challenge!, 3rd Edition, Risk Section, Ward, J. LeRoy, 2001
What to Study?
The PMBOK phases of Project Risk Management: Risk Management Planning, Risk
Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response
Planning, and Risk Monitoring and Control (Be familiar with Inputs, Tools and
Techniques, and Outputs for each phase)
The means for determining the value of a risk event: R=P*I where R is the calculated
value of the risk event, P is the probability of the occurrence of the risk event, and I
is the impact of the risk event should it occur. (A risk event is a discrete occurrence
that could affect the project for better or worse.)
The relationship of risk and the project life cycle: the amount of uncertainty and risk is
highest at the start of the project and lowest at the end of the project
Positive risk as defined by opportunities and negative risk as defined by threats
The various means of classifying risk: business, pure (insurable), known, unknown
Risk assessment using Decision Trees and Expected Monetary Value
Monte Carlo Analysis, Delphi Technique, Cause-and-effect (also called Ishikawa or
fishbone) diagrams
The different types of scales used in risk analysis: ordinal and cardinal

Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

8-3

Project Risk Management

Key Definitions
Amount at Stake
Assumptions

Assumptions analysis

Brainstorming

Business Risk
Checklist

Contingency Planning

Contingency Reserve

Decision Tree
Analysis

Deflection

Expected Monetary
Value

The extent of adverse consequences which could occur to the

project. (Also referred to as risk impact).
Factors that for planning purposes are considered to be true, real,
or certain. Assumptions affect all aspects of project planning and
are part of the progressive elaboration of the project. Project
teams frequently identify, document, and validate assumptions as
part of their planning process. Assumptions generally involve a
degree of risk.
A technique that explores the accuracy of the assumptions and
identifies risks to the project from inaccuracy, inconsistency, or
incompleteness of assumptions.
A general creativity technique that can be used to identify risks
using a group of team members or subject-matter experts.
Typically, a brainstorming session is structured so that each
participants ideas are recorded for later analysis.
The inherent chances for both profit or loss associated with a
particular endeavor or line of business.
A comprehensive listing of many possible risks that might occur on
a project. Several types of risk that have been encountered on
previous projects are included.
The development of a management plan that identifies alternative
strategies to be used to ensure project success if specified risk
events occur.
The amount of money or time needed above the estimate to
reduce the risk of overruns of project objectives to a level
acceptable to the organization.
A diagram that describes a decision under consideration and the
implications of choosing one or another of the available
alternatives. It incorporates probabilities or risks and the costs or
rewards of each logical path of events and future decisions.
The act of transferring all or part of a risk to another party, usually
by some form contract provision, insurance policy, or warranty.
Also called risk transference.
The product of an events probability of occurrence and the gain
or loss that will result. Expected Monetary Value = Money at
Risk x probability. For example, if there is a 50% probability it will
rain, and rain will result in a $100 loss, the expected monetary
value of the rain event is $50 (.5 * $100).

8-4 Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Project Risk Management

Key Definitions, cont.

The mathematical examination of the nature of individual risks on
the project, as well as potential arrangements of interdependent
risks. It includes the quantification of their respective impact
severity, probability, and sensitivity to changes in related project
variables, including the project life cycle. To be complete, the
analysis should also include an examination of the external status
quo prior to project implementation as well as the projects internal
intrinsic worth as a reference baseline. A determination should
also be made as to whether all risks identified are within the scope
of the projects response planning process.
A particular type of risk which can be covered by an insurance
Insurable Risk
policy. (i.e., floods, fire, etc.) Also called a pure risk.
Management Reserve A separately planned quantity used to allow for future situations
which are impossible to predict. Management reserves are
intended to reduce the risk of missing cost or schedule objectives.
Use of management reserves requires a change to the projects
cost baseline. Management reserves are not included in the
projects cost and schedule baseline. Also used to manage
unknown unknowns types of risk.
Taking steps to lessen risk by lowering the probability of a risk
Mitigation
events occurrence or reducing its effect should it occur.
A technique that performs a project simulation many times in order
Monte Carlo Analysis
to calculate a distribution of likely results.
Future events or series of events that if they occur will have a
Opportunities
positive impact on the project. Benefits which can be realized from
undertaking a project. As related to risk, positive outcomes of risk
events.
The likelihood of occurrence. The ratio of the number of chances
Probability
by which an event may happen (or not happen) to the sum of the
chances of both happening and not happening.
Probability and Impact A common way to determine whether a risk is considered low,
moderate, or high by combining the two dimensions of a risk: its
Matrix
probability of occurrence and its impact on objectives if it occurs.
Includes the processes concerned with identifying, analyzing, and
Project Risk
responding to project risk.
Management
A provision in the project plan to mitigate cost and/or schedule
Reserve
risk. Often used with a modifier (e.g., management reserve,
contingency reserve) to provide further detail on what types of risk
are meant to be mitigated. The specific meaning of the modified
term varies by application area.
A risk that remains after risk responses have been implemented.
Residual Risk
An uncertain event or condition that, if occurs, has a positive or
Risk
negative effect on a project objective.
A discrete occurrence that may affect the project for better or
Risk Event
worse.
Impact Analysis

Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

8-5

Project Risk Management

Key Definitions, cont.

Risk Management
Plan

A subsidiary element of the overall project plan which documents

the procedures that will be used to manage risk throughout the
project. Also covers who is responsible for managing various risk
areas; how contingency plans will be implemented, and how
reserves will be allocated.

Risk Response Plan

A document detailing all identified risks, including description,

cause, probability of occurrence, impacts on objectives, proposed
responses, owners, and current status. Also known as the risk
register.
As related to risk, negative outcomes of risk.
All information is known.
No information is available and nothing is known. By definition,
total uncertainty cannot be envisaged.
Indications that a risk has either occurred or is about to occur.
(Also referred to as risk symptoms or warning signs)
The possibility that events may occur which will impact the project
either favorably or unfavorably. Uncertainty gives rise to both
opportunity and risk.
A response to a negative risk event. Distinguished from
contingency plan in that a workaround is not planned in advance
of the occurrence of the risk event.

Threats
Total Certainty
Total Uncertainty
Triggers
Uncertainty

Project Risk Management Processes

Risk Management Planning (11.1): (Process Group: Planning)

Is the process of deciding how to approach and plan the risk management activities for
a project.
Planning for subsequent risk management processes helps ensure that the level, type,
and visibility of risk management are commensurate with both the risk and importance
of the project to the organization.
Inputs include:
Project charter
Organizations risk management policies (predefined approaches to risk
analysis and response)
Defined roles and responsibilities (predefined roles, responsibilities, and
authority levels for decision-making will influence planning)
Stakeholder risk tolerances:
Different organizations and different individuals have different tolerances
for risk.
These may be expressed in policy statements or revealed in actions.
Template for the organizations risk management plan
WBS.
Methods used during risk management planning include: planning meetings
Outputs include: Risk Management Plan.
Describes how risk identification, qualitative and quantitative analysis, response
planning, monitoring, and control will be structured and performed during the
project life cycle.
Does not address responses to individual risks -- this is accomplished in the risk
response plan.
May include:
Methodology: Defines the approaches, tools, and data sources that
may be used to perform risk management on the project. Different types
of assessments may be appropriate, depending upon the project stage,
amount of information available, and flexibility remaining in risk
management.
Roles and responsibilities: Defines the lead, support, and risk
management team membership for each type of action in the risk
management plan. Risk management teams organized outside of the
project office may be able to perform more independent, unbiased risk
analyses of project than those from the sponsoring project team.
Budgeting: Establishes a budget for risk management for the project.
Timing: Defines how often the risk management process will be
performed throughout the project life cycle. Results should be
developed early enough to affect decisions. The decisions should be
revisited periodically during a project execution.
Scoring and interpretation: The scoring and interpretation methods
appropriate for the type and timing of the qualitative and quantitative risk
analysis being performed. Methods and scoring must be determined in
advance to ensure consistency.

8-8 Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Project Risk Management

Project Risk Management Processes, cont.

Thresholds: The boundaries that identify which risks will be acted

upon, by whom, and in what manner. The project owner, customer, or
sponsor may have a different risk threshold. The acceptable threshold
forms the target against which the project team will measure the
effectiveness of the risk response plan execution.
Reporting formats: Describes the content and format of the risk
response plan. Defines how the results of the risk management
processes will be documented, analyzed, and communicated to the
project team, internal and external stakeholders, sponsors, and others.
Tracking: Documents how all facets of risk activities will be recorded for
the benefit of the current project, future needs, and lessons learned.
Documents if and how risk processes will be audited.

Risk Identification (11.2):

(Process Group: Planning)

The process of determining which risks are likely to affect the project and documenting
the characteristics of each.
Where feasible, participants in the risk identification process generally include: the
project team, the risk management team, subject matter experts from other parts of the
company, customers, end users, other project managers, stakeholders, and outside
experts.
Risk identification is an iterative process.
Inputs include:
Risk Management Plan
Project planning outputs:
Risk identification requires an understanding of the projects mission,
scope, and objectives of the owner, sponsor, or stakeholders.
Outputs of other processes should be reviewed to identify possible risks
across the entire project. These may include, but are not limited to: the
project charter, WBS, product description, schedule and cost estimates,
resource plan, procurement plan, and assumption and constraint lists.
Risk categories. These categories should be well defined and should reflect
common sources of risk for the industry or application area. These categories
include the following:
Technical, quality or performance risks - such as reliance on
unproven or complex technology, unrealistic performance goals,
changes to the technology used or to industry standards during the
project.
Project-management risks - such as poor allocation of time and
resources, inadequate quality of the project plan, poor use of project
management disciplines.
Organizational risks - such as 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 in the
organization.

Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

8-9

Project Risk Management

Project Risk Management Processes, cont.

External risks - such as shifting legal or regulatory environment, labor

issues, changing owner priorities, country risk, and weather. Force
majeure risks such as earthquakes, floods, and civil unrest generally
require disaster recovery actions rather than risk management.
Historical information - information on prior projects may be available
from project files or published information through commercial or
academic sources.

Methods used during risk identification:

Documentation reviews - includes 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 informational sources.
Information-gathering techniques:
Brainstorming: Probably the most frequently used risk identification
technique. Generally performed by the project team although a
multidisciplinary set of experts can also perform this technique. The goal
is to obtain a comprehensive list of risks that can be addressed later in
the qualitative and quantitative risk analysis processes. Under the
leadership of a facilitator, the team generates ideas about project risk.
Sources of risk are identified in broad scope, posted, categorized by
type of risk, and then the definitions sharpened.
Delphi technique: A means for achieving a consensus of experts on a
subject such as project risk. Project risk experts are identified but
participate anonymously. A facilitator uses a questionnaire to solicit
ideas about the important project risks. 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.
Interviewing: Risks are identified by interviewing experienced project
managers or subject-matter experts. The person in charge of risk
identification identifies the appropriate individuals, briefs them on the
project, and provides information such as the WBS and the list of
assumptions. The interviewees then identify risks.
Strengths, weaknesses, opportunities, and threats (SWOT) analysis:
Ensures examination of the project from each of the SWOT perspectives
to increase the breadth of the risks considered.
Checklists:
Lists based on historical information and knowledge that has been
accumulated from previous similar projects and other sources of
information.
An advantage of using a checklist is that the risk identification is quick
and simple.
The disadvantage of using a checklist is that building a checklist with
every possible risk is impossible, and the user may be limited to the
categories that appear on the list.

8-10 Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Project Risk Management

(Process Group: Planning)

The process of measuring the probability and consequences of risks and estimating
their implications for project objectives.
Aims to analyze numerically the probability of each risk and its consequence on project
objectives, as well as the extent of overall project risk.
Uses techniques such as Monte Carlo simulation and decision analysis to:
Determine the probability of achieving a specific project objective.
Quantify the risk exposure for the project and determine the size of cost and
schedule contingency reserves that may be needed.
Identify risks requiring the most attention by quantifying their relative
contribution to project risk.
Identify realistic and achievable cost, schedule, or scope targets.
The quantitative and qualitative risk analysis processes can be used separately or
together.
Trends in the results when quantitative analysis is repeated can indicate the need for
more or less risk management action.
Inputs include:
Risk Management Plan
Identified risks
List of prioritized risks
List of risks for additional analysis and management
Historical information
Expert judgment
Other planning outputs
The methods used in quantitative risk analysis include:
Interviewing:
Interviewing techniques are used to quantify the probability and
consequences of risks on project objectives.
A risk interview with project stakeholders and subject-matter experts may
be the first step in quantifying risks.
The information needed depends upon the type of probability
distributions that will be used. For instance, information would be
gathered on the optimistic (low), pessimistic (high) and the most likely
scenarios if triangular distributions are used, or on mean and standard
deviation for the normal and log normal distributions. (see PMBOK
Guide Figures 11-4, 11-5, and 11-7)
For effective risk response strategies, it is important to document the
rationale of the risk ranges.
Sensitivity analysis:
Helps determine which risks have the most potential impact on the
project.
Examines the extent to which the uncertainty of each project element
affects the objective being examined when all other uncertain elements
are held at their baseline values.

8-14 Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Project Risk Management

Project Risk Management Processes, cont.

Decision tree analysis:

Usually structured as a decision tree.
The decision tree is a diagram that describes a decision under
consideration and the implications of choosing one or another of the
available alternatives.
Decision tree analysis attempts to break down a series of events into
smaller, simpler, and more manageable segments.
Incorporates probabilities of risks and the costs or rewards of each logical
path of events and future decisions.
Solving the decision tree indicates which decision yields the greatest
expected value to the decision-maker when all the uncertain implications,
costs, rewards, and subsequent decisions are quantified.
Simulation:
Uses a model that translates the uncertainties specified at a detailed level
into their potential impact on objectives that are expressed at the level of
the total project.
Project simulations are typically performed using the Monte Carlo
technique.
For a cost risk analysis, a simulation may use the traditional project WBS
as its model. For a schedule risk analysis, the Precedence Diagram
Method (PDM) schedule is used.
Outputs include:
Prioritized list of quantified risks: List of risks that includes those which pose
the greatest threat or present the greatest opportunity to the project together
with the measure of the impact for each quantified risk.
Probabilistic analysis of the project: Forecasts of potential project schedule
and cost results listing the possible completion dates/project duration and costs
with their associated confidence levels.
Probability of achieving the cost and time objectives: The probability of
achieving the project objectives under the current plan and with the current
knowledge of the project risks can be estimated using quantitative risk analysis.
Trends in quantitative risk analysis results: As the analysis is repeated, a
trend in the results may become apparent.

Risk Response Planning (11.5): (Process Group: Planning)

The process of developing options and determining actions to enhance opportunities

and reduce threats to the projects objectives.
Includes the identification and assignment of individuals or parties to take responsibility
for each agreed risk response.
Ensures that identified risks are properly addressed.
The effectiveness of response planning will directly determine whether risk increases or
decreases for the project.

Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

8-15

Project Risk Management

Project Risk Management Processes, cont.

Risk response planning must be:

Appropriate for the severity of the risk
Cost effective in meeting the challenge
Timely to be successful
Realistic within the project context
Mutually agreed upon by all involved parties
Owned by a responsible person
Selects the best risk response from the available options
Inputs to risk response planning include:
Risk Management Plan
List of prioritized risks
Risk ranking of the project
Prioritized list of quantified risks
Probabilistic analysis of the project
Probability of achieving the cost and time objectives
List of potential responses: In the risk identification process, actions may be
identified that respond to individual risks or categories of risks.
Risk thresholds: The level of risk that is acceptable to the organization will
influence risk response planning.
Risk owners: A list of project stakeholders able to act as owners of risk
responses. Risk owners should participate in the development of risk
responses.
Common risk causes: Several risks may be driven by a common cause and
may be able to be mitigated with a generic response.
Trends in qualitative and quantitative risk analysis results
Methods for risk response planning include:
Avoidance:
Changes the project plan to eliminate the risk or protect the project
objectives from the risk impact.
Some risk events that arise early in the project can be avoided by
clarifying requirements, obtaining information, improving communication,
acquiring expertise, etc.
Other examples of avoidance include: reducing scope, adding
resources, extending project time, adopting familiar approaches,
avoiding unfamiliar subcontractors, etc.
Transference:
Shifts the consequence of a risk to a third party together with ownership
of the response.
Most effective in dealing with financial risk exposure. Nearly always
involves payment of a risk premium to the party taking on the risk.
Examples include: use of insurance, performance bonds, warranties,
and guarantees.
Different types of contracts may also be used to transfer risk. For
example, a fixed-price contract places most of the risk on the seller of
the product/services whereas a cost-plus contract places most of the risk
on the buyer or customer.

8-16 Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Project Risk Management

Project Risk Management Processes, cont.

Mitigation:
Seeks to reduce the probability and/or consequences of an adverse risk
event to an acceptable threshold.
Taking early action helps reduce the probability of an adverse risk
occurring and/or the severity of the impact and is more effective than
repairing the consequences after the risk has occurred.
Must take into consideration the mitigation costs given the likely probability
of the risk and its consequences.
Examples of mitigation include: adopting less complex processes,
conducting more engineering tests, choosing a more stable seller,
developing prototypes, adding more skilled resources, etc.
Acceptance:
Project team makes a conscious decision to not change the project plan to
handle the risk.
Project team may not be able to identify any other suitable response
strategy other than accepting the risk.
Active acceptance may include developing a contingency plan to
execute, should a risk occur.
Passive acceptance requires no action, leaving the project team to deal
with the risks as they occur.
A contingency plan is applied to identified risks that arise during the
project. Developing a plan in advance can greatly reduce the cost of an
action should the risk occur.
A fallback plan is developed if the risk has a high impact, or if the
selected strategy may not be fully effective. This could include allocation
of a contingency amount, development of alternative options, or changing
the project scope.
The most usual risk acceptance response is to establish a contingency
allowance or reserve which includes amounts of time, money, or
resources to account for known** risks. The allowance should be
determined by the impacts, computed at an acceptable level of risk
exposure, for the accepted risks.
** Authors note: In the Project and Program Risk Management by Max
Wideman, these types of risk are referred to as known unknowns.

Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

8-17

Project Risk Management

Project Risk Management Processes, cont.

Outputs include:
Risk response plan: a detailed plan which describes the actions that will be
taken in regards to handling/accepting risk. It is also called the risk register
and should include some or all of the following:
Identified risks and descriptions, areas of the affected project (e.g., WBS
element), causes of identified risks, and impact on project objectives.
Risk owners and assigned responsibilities.
Results from the qualitative and quantitative risk analysis processes.
Agreed responses including avoidance, transference, mitigation, or
acceptance for each risk in the risk response plan.
The level of residual risk expected to be remaining after the strategy is
implemented.
Specific actions to implement the chosen response strategy.
Budget and times for responses.
Contingency plans and fallback plans.
Residual risks:
Risks that remain after the execution of avoidance, transfer, or mitigation
responses.
Also include minor risks that have been accepted and addressed via
contingency planning.
Secondary risks:
Risks that arise as a direct result of implementing a risk response.
Should be identified and have responses planned.
Contractual agreements: Should specify each partys responsibility for
specific risks. (example: insurance)
Contingency reserve amounts needed: the amount of buffer or contingency
needed to reduce the risk of overruns of project objectives to a level acceptable
to the organization.
Inputs to other processes: Alternative strategies must be fed back into the
appropriate processes in other knowledge areas.
Inputs to a revised project plan: Results of risk response planning should be
incorporated into the project plan.

Event Probabilities: (ref: Project and Program Risk Management by Wideman from
PMI, pg. IV-7.)
Determining probabilities of related events using simple probabilities:

Probability of Event 1 multiplied by Probability of Event 2 = Probability of both Events

The probability of an event occurring plus the probability of the same event not
occurring should always equal one.
Example: Given an 0.80 probability that the project scope will be defined by next month
and a 0.70 probability that the scope will be approved, what is the probability of both
events occurring? Answer: 0.8 X 0.7, or 56%.
Given that only one of the above events needs to occur before project planning begins,
what is the probability that project planning will occur? Answer:
Consider that project planning will not occur if neither event occurs. Therefore, the
Probability (Scope not defined) X Probability (Scope not approved) =
0.2 X 0.3 = 0.06. Therefore, there is a 94% chance of project planning beginning.

Scope of Project Risk Management: (ref: Project and Program Risk Management
by Wideman from PMI, pg. I-2)

p=0.2

Task C p=0.15

23. A risk event is defined as :

A. The severity of the consequences of a loss
B. How likely the event is to occur
C. A discrete occurrence that may affect the project for better or worse
D. A symptom of a risk

Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

8-25

Project Risk Management

Sample Questions, continued

24. An analysis has identified four different options for reducing project costs. Given the
following decision tree, which option should be selected ?

P=0.7

P=0.4

P=0.1

Option B value $1,000

P=0.2

Option C value $ 5,000

P=0.6

A.
B.
C.
D.

Option A value $100

Option D value $ 2,000

18.

19.

20.

21.

22.

23.

24.

10.

25.

11.

26.

12.

27.

13.

28.

14.

29.

15.

30.

8-28 Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Project Risk Management

Answers
1 C
2 D
3 A
4 B
5 A
6
7
8
9
10
11
12
13

D
C
D
D
B
B
A
C

14 D
15 A
16 C
17
18
19
20
21
22
23
24

C
A
B
C
B
B
C
D

25
26
27
28
29
30

C
D
D
B
B
C

PMBOK Guide, pg. 127

PMBOK Guide, Glossary and pg. 143, pg. 73
PMBOK Guide, pg. 128 Earned value analysis is used as part of Risk
Monitoring and Control
Project & Program Risk Management by R. Max Wideman, Editor
A workaround is an unplanned response to a negative risk event. Option C is
the definition of a checklist.
Project & Program Risk Management by R. Max Wideman, Editor. glossary
PMBOK Guide, pg. 142
PMBOK Guide, pg. 142
PMBOK Guide, pg. 131
PMBOK Guide, glossary
PMBOK Guide, pg. 135
PMBOK Guide, pgs. 134-136. A nonlinear scale can provide a greater risk
score for risks with high impacts and probabilities. This allows the organization
with high-impact risk aversion to better rank and focus on these risks. The use
of data with low precision as suggested in Option B may lead to qualitative risk
analysis of little use to the project manager. Option A is a type of risk response.
PMBOK Guide, pgs. 132-133
PMBOK Guide, pg. 128
0.2 x 0.3 = 0.06, Project & Program Risk Management by R. Max Wideman,
Editor, decision tree analysis
PMBOK Guide, pg. 128.
PMBOK Guide, pg. 143. Option A is transference; Option C is mitigation.
PMBOK Guide, pg. glossary
Risks can never be completely eliminated on a project.
0.1 x .2 x .15 = .003
PMBOK Guide, glossary
a. Option A Expected value of Opportunity = (.4)(.7)($100) = $ 28
c. Option B Expected value of Opportunity = (.4)(.1)($1000) = $ 40
b. Option C Expected value of Opportunity = (.4)(.2)($5000) = $ 400
d. Option D Expected value of Opportunity = (.6)($2000)
= $1200
PMBOK Guide, pg. 142
PMBOK Guide, pg. 140
PMBOK Guide, pg. 133
PMBOK Guide, pg. 134, Wideman pg. VII-2
$15,000 x .07 = $1,050

Project Risk Management

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

8-29

Project Risk Management

PMP Certification Exam Preparation

What did I do wrong ?

I would have answered a larger number of questions

correctly if I had ___________.

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.

Assignment Project Quality Management (Full)
92% (24)
Assignment Project Quality Management (Full)
26 pages
Is333 MST Trial Answers 2017
No ratings yet
Is333 MST Trial Answers 2017
12 pages
CQE Body of Knowledge
No ratings yet
CQE Body of Knowledge
11 pages
Quality Assurance
No ratings yet
Quality Assurance
3 pages
Project Management and ISO 9001
100% (4)
Project Management and ISO 9001
6 pages
Implementing Iso 90012008 Quality Management System A Reference PDF
100% (1)
Implementing Iso 90012008 Quality Management System A Reference PDF
197 pages
ASQ CMQ OE Body of Knowledge BOK Mapping of
100% (3)
ASQ CMQ OE Body of Knowledge BOK Mapping of
12 pages
Gap Analysis - Project Quality Plan
No ratings yet
Gap Analysis - Project Quality Plan
7 pages
A Gift of Fire - Chapter 9
100% (1)
A Gift of Fire - Chapter 9
16 pages
Role Play 1: "BRAIN DRAIN": Situation
No ratings yet
Role Play 1: "BRAIN DRAIN": Situation
1 page
PMI-RMP Exam Companion
From Everand
PMI-RMP Exam Companion
SUJAN
No ratings yet
PMBOK Quality MGMT - by Skanchi
100% (2)
PMBOK Quality MGMT - by Skanchi
44 pages
Project Quality Management
100% (6)
Project Quality Management
31 pages
5 Project Quality Management
100% (2)
5 Project Quality Management
40 pages
QMS Guidelines PDF
100% (2)
QMS Guidelines PDF
203 pages
PMF-project Quality Management
100% (1)
PMF-project Quality Management
41 pages
Foundation of Quality Management
No ratings yet
Foundation of Quality Management
19 pages
L01-Project Quality Management
100% (1)
L01-Project Quality Management
29 pages
Conastruction Quality Management PDF
100% (1)
Conastruction Quality Management PDF
209 pages
Project Quality Management
100% (6)
Project Quality Management
94 pages
Quality Management Plan Outline
100% (1)
Quality Management Plan Outline
124 pages
ISO 21500 Additional Slides
No ratings yet
ISO 21500 Additional Slides
47 pages
Project Quality Management
100% (1)
Project Quality Management
41 pages
QUALITY MANAGEMENT PLAN TEMPLATE v0.1
No ratings yet
QUALITY MANAGEMENT PLAN TEMPLATE v0.1
30 pages
T5 - PM Project Quality Management
100% (1)
T5 - PM Project Quality Management
71 pages
Lecture 6 Quality Management System QMS
No ratings yet
Lecture 6 Quality Management System QMS
18 pages
Cqia Sample Exam
No ratings yet
Cqia Sample Exam
9 pages
Qlty MGMT in Projects
No ratings yet
Qlty MGMT in Projects
5 pages
CQM Brochure - Meritphase
100% (1)
CQM Brochure - Meritphase
19 pages
Management & Control of Quality
No ratings yet
Management & Control of Quality
2 pages
2019 CMQOE BoK Map PDF
No ratings yet
2019 CMQOE BoK Map PDF
13 pages
Quality PMBOK
No ratings yet
Quality PMBOK
12 pages
CMQ CTC PDF
0% (1)
CMQ CTC PDF
4 pages
Iso 9001 Supply Chain
No ratings yet
Iso 9001 Supply Chain
20 pages
ProjectManagement AuditGuide
100% (1)
ProjectManagement AuditGuide
11 pages
Client Evaluation Form Rev8a
No ratings yet
Client Evaluation Form Rev8a
2 pages
Cost of Quality
No ratings yet
Cost of Quality
40 pages
Guide To The QBOK
100% (2)
Guide To The QBOK
40 pages
01 - Quality Management Introduction
No ratings yet
01 - Quality Management Introduction
11 pages
What Is A Quality Management System?
No ratings yet
What Is A Quality Management System?
180 pages
Quality Progress
No ratings yet
Quality Progress
68 pages
5 - Project Quality Management
100% (1)
5 - Project Quality Management
53 pages
Chapter 11 - Project Risk Management PDF
100% (2)
Chapter 11 - Project Risk Management PDF
87 pages
CMQ Practise Test
No ratings yet
CMQ Practise Test
1 page
Quality Control Construction
No ratings yet
Quality Control Construction
31 pages
Basic Management Principles PDF
100% (1)
Basic Management Principles PDF
88 pages
Quality Management Systems Guide
No ratings yet
Quality Management Systems Guide
27 pages
Cost of Quality: Not Only Failure Costs
100% (1)
Cost of Quality: Not Only Failure Costs
4 pages
Internal Audits Op
No ratings yet
Internal Audits Op
30 pages
Definition of Quality
No ratings yet
Definition of Quality
11 pages
Iso 31000 PDF
No ratings yet
Iso 31000 PDF
37 pages
Quality Management and Quality Techniques
No ratings yet
Quality Management and Quality Techniques
168 pages
Project Quality Management
No ratings yet
Project Quality Management
30 pages
Quality Planning Process
No ratings yet
Quality Planning Process
36 pages
Quality Improvement
No ratings yet
Quality Improvement
17 pages
PMI-RMP Exam Excellence: Study Guide & Practice Tests
From Everand
PMI-RMP Exam Excellence: Study Guide & Practice Tests
SUJAN
No ratings yet
Course Outline Sample Oct2023
No ratings yet
Course Outline Sample Oct2023
2 pages
CKPM209 Course Outline 2010 v1.0
No ratings yet
CKPM209 Course Outline 2010 v1.0
10 pages
Course Outline
No ratings yet
Course Outline
3 pages
CSP Project Risk Management
No ratings yet
CSP Project Risk Management
7 pages
Project Manangement
No ratings yet
Project Manangement
5 pages
Allama Iqbal Open University Islamabad (Department of Business Administration)
No ratings yet
Allama Iqbal Open University Islamabad (Department of Business Administration)
7 pages
Allama Iqbal Open University Islamabad (Department of Business Administration)
No ratings yet
Allama Iqbal Open University Islamabad (Department of Business Administration)
6 pages
EMPLOYEES TAX
No ratings yet
EMPLOYEES TAX
81 pages
Medical Card
No ratings yet
Medical Card
1 page
tax challan for Noor Ahmed
No ratings yet
tax challan for Noor Ahmed
1 page
Running Account bill
No ratings yet
Running Account bill
3 pages
Pakistan Salary Income Tax Calculator Tax Year 2021 2022
No ratings yet
Pakistan Salary Income Tax Calculator Tax Year 2021 2022
4 pages
certificate NTN
No ratings yet
certificate NTN
1 page
02525-23-176013853
No ratings yet
02525-23-176013853
2 pages
STRN certificate
No ratings yet
STRN certificate
1 page
Chapter 20outlets
No ratings yet
Chapter 20outlets
3 pages
Contractor Tax 474560
No ratings yet
Contractor Tax 474560
16 pages
Chapter 13 Roofing
No ratings yet
Chapter 13 Roofing
10 pages
Pipfa Syllabus Winter-2019 For Prad: (Updated 2020)
No ratings yet
Pipfa Syllabus Winter-2019 For Prad: (Updated 2020)
56 pages
Income Tax Payment Challan: PSID #: 57372718
No ratings yet
Income Tax Payment Challan: PSID #: 57372718
1 page
2 Labor Rate 2
No ratings yet
2 Labor Rate 2
2 pages
Experience Certificate AL KHIDMAT2
No ratings yet
Experience Certificate AL KHIDMAT2
1 page
P H Y: 40 Ion: - A T e
No ratings yet
P H Y: 40 Ion: - A T e
4 pages
Record of Achievement: Muhammad Kashif
No ratings yet
Record of Achievement: Muhammad Kashif
1 page
Experience Certificate AL KHIDMAT
No ratings yet
Experience Certificate AL KHIDMAT
1 page
Experience Certificate BINUQ
No ratings yet
Experience Certificate BINUQ
1 page
Federal Public Service Commission: Aga Khan Road, Sector F-5/1, ISLAMABAD
No ratings yet
Federal Public Service Commission: Aga Khan Road, Sector F-5/1, ISLAMABAD
3 pages
DLP No 5 Creates Rhythmic Pattern in Time Signatures
No ratings yet
DLP No 5 Creates Rhythmic Pattern in Time Signatures
4 pages
South Africa Lesson Plan
No ratings yet
South Africa Lesson Plan
1 page
Gk Syllabus Class-8, 2024-25
No ratings yet
Gk Syllabus Class-8, 2024-25
8 pages
Daftar Pustaka
No ratings yet
Daftar Pustaka
4 pages
A Chair For My Mother: Objective
No ratings yet
A Chair For My Mother: Objective
5 pages
Hugot Inspirational Quotes
No ratings yet
Hugot Inspirational Quotes
15 pages
What Every Student Needs To Read Now
No ratings yet
What Every Student Needs To Read Now
44 pages
How To Write A Cover Letter For Research Jobs
No ratings yet
How To Write A Cover Letter For Research Jobs
7 pages
Friedrich Wilhelm Joseph Von Schelling
No ratings yet
Friedrich Wilhelm Joseph Von Schelling
3 pages
English Esl Conversation Mood Feelings and Emotion
No ratings yet
English Esl Conversation Mood Feelings and Emotion
5 pages
Summer Internship Presentation Competency Mapping: Indian Farmers Fertilizer Co-Op. Ltd. Kalol Unit
No ratings yet
Summer Internship Presentation Competency Mapping: Indian Farmers Fertilizer Co-Op. Ltd. Kalol Unit
26 pages
Resume For Freshers TCS
100% (1)
Resume For Freshers TCS
2 pages
Call For Submission of Application For Application For Teaching Positions.
No ratings yet
Call For Submission of Application For Application For Teaching Positions.
15 pages
Wipro Logical Reasoning Practice Set 1 263b5a8d
No ratings yet
Wipro Logical Reasoning Practice Set 1 263b5a8d
5 pages
Prospectus (2019-20) : Executive Post Graduate Diploma Programmes in International Business (Epgdib)
No ratings yet
Prospectus (2019-20) : Executive Post Graduate Diploma Programmes in International Business (Epgdib)
31 pages
School Grade Level VI Teacher Learning Areas ART Teaching Dates and Time Quarter 1 Quarter
No ratings yet
School Grade Level VI Teacher Learning Areas ART Teaching Dates and Time Quarter 1 Quarter
35 pages
(Ebook) Psychology: Australian and New Zealand edition by Douglas A. Bernstein, Julie Ann Pooley, Lynne Cohen, Stephen Provost, Jacquelyn Cranney, Bethanie Gouldthorp, Neil Drew ISBN 9780170445375, 9781337612395, 0170445372, 1337612391 - The full ebook version is ready for instant download
100% (2)
(Ebook) Psychology: Australian and New Zealand edition by Douglas A. Bernstein, Julie Ann Pooley, Lynne Cohen, Stephen Provost, Jacquelyn Cranney, Bethanie Gouldthorp, Neil Drew ISBN 9780170445375, 9781337612395, 0170445372, 1337612391 - The full ebook version is ready for instant download
72 pages
[FREE PDF sample] (Ebook) Critical Theory: The Basics by Martin Shuster ISBN 9781003861720, 1003861725 ebooks
No ratings yet
[FREE PDF sample] (Ebook) Critical Theory: The Basics by Martin Shuster ISBN 9781003861720, 1003861725 ebooks
76 pages
gender project
No ratings yet
gender project
21 pages
PebblePad Help
No ratings yet
PebblePad Help
4 pages
New BSBLDR804 Case Study - Ghanian Armed Forces - Branding
No ratings yet
New BSBLDR804 Case Study - Ghanian Armed Forces - Branding
17 pages
Seat Acceptance Letter
No ratings yet
Seat Acceptance Letter
1 page
15 Customer Service Skills That Every Employee Needs: Help Scout Why Help Scout? Pricing Resources
No ratings yet
15 Customer Service Skills That Every Employee Needs: Help Scout Why Help Scout? Pricing Resources
14 pages
Module 3 Q2 Gen Chem II
No ratings yet
Module 3 Q2 Gen Chem II
10 pages
Multi Agent MRP Class System For Production and Dis - 2000 - IFAC Proceedings Vo
No ratings yet
Multi Agent MRP Class System For Production and Dis - 2000 - IFAC Proceedings Vo
6 pages
PSP3702 Theme 10 Family and Community Partnerships
No ratings yet
PSP3702 Theme 10 Family and Community Partnerships
7 pages
List of MoUs
No ratings yet
List of MoUs
3 pages