Project Quality & Risk Management-Manual

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
Table of Contents
Introduction ....................................................................................................
03
Objective .......................................................................................................
03
Contacting the module instructor ..................................................................
03
Rationale including Aims ..............................................................................
04
Pre-Requisites ..............................................................................................
04
Teaching and Learning Outcomes ...............................................................
04
Teaching Methodology .................................................................................
04
Assessment Scheme ...................................................................................
05
Reading Materials ........................................................................................
05
10
Course Requirement and Expectations ........................................................
05
11
Academic Dishonesty ...................................................................................
06
12
Module Contents ..........................................................................................
07
2 of 7
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:
ghazala_amin@comsats.edu.pk
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
3 of 7
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
4 of 7
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
5%
Assignment#1 after 8 weeks
10%
Mid-term examination after 09 weeks
25%
Quiz#2 after 13 weeks
5%
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%
5 of 7
>=
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.
6 of 7
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
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
10
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
13
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
14
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
16

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
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
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 ?
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
10
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.
11
12
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
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

7
ISO 9000-Wikipedia-Certification
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
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.
11
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.
12
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.
13
14
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
Total Quality Management (TQM)
Ghazala Amin
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
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 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
10
Organizational commitment
Yields: Employees attitudes that they can
accomplish what is important and to be
accomplished
11
12
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.
13
TQM: Primary strategies
14
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
16
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.
17
Malcolm Baldridge National Quality

Award (1987)
18
Baldridge Performance Excellence Award

From: Baldrige Performance Excellence Program [mailto:baldrigeprogram@nist.gov]
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
baldrige@nist.gov 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
20
Quality Gurus
Lec#6
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.
5.
Plan
6.
7.
8.
9.
10.
11.
Do
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

7
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

9
10
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
12
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.
13
Continuous Improvement Process

(CIP)
14
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

15
16
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.
17
Resolving Customer Complaints

Best Practices
1995 Corel Corp.
18
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
19
20
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

21
Just-In-Time (JIT) Example

Reducing inventory reveals
problems so they can be solved.
Unreliable
Vendors
Scrap
Capacity
Imbalances
23
Scrap
Capacity
Imbalances
22

(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
Quality Processes
Ghazala Amin
A company dedicated to quality usually provides training for all employees

2
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
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 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.

9
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.
10
For example, procurement planning may identify

contractor quality requirements.
11
12
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
13
Quality Policy Statements
14
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
15
16

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.
17
18
Some commonly used tools & techniques employed

for Quality planning are;

Best practices for benchmarking;

Flowcharting
Determine what to benchmark

Form a benchmark team
Identify benchmarking partners
Collect and analyze benchmarking
information
Take action to match or exceed the
benchmark
a technique which creates a diagram that displays how various

elements of a system relate.
Can assist the project team with anticipating what and where
quality problems may occur and with developing approaches
for addressing the problems.
19
20

Flowcharts commonly used in quality management
include:
Some commonly used tools & techniques employed for Quality planning
are;
A statistical method that helps identify which factors might
influence specific variables.
Is applied most frequently to the product of the project .
Cause-and-effect diagrams: illustrate how various factors

may be linked to potential problems or effects. (also
referred to as Ishikawa or fishbone diagrams)
Example: automotive designers may wish to determine which

combination of suspension and tires will produce the most
desirable ride characteristics at a reasonable cost.
System or process flow charts: show how various

elements of a system interrelate.
21
22


Can also be applied to project management issues such as
cost and schedule
tradeoffs.
Example: senior engineers will cost more than junior engineers
but will usually complete the assignment in less time. An
appropriately designed experiment which computes project
costs and duration for various combinations of senior and
junior engineers will often yield an optimal solution from a
relatively limited number of cases.
23
Cost of Quality
Refers to the total cost of all efforts to achieve
product/service quality.
Includes all work to ensure conformance to
requirements as well as all work resulting from
nonconformance to requirements.
24

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

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
26
Quality is never an
accident, it is always the
result of an intelligent
effort
Lecture #8
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
3.
CONSISTENCY
4.
PRECISION
5.
ACCURACY
6.
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/
http://perspectives.avalution.com/2009/what-is-management-system/
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
10
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.
11
12
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
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:
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 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
10
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.
11
12
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

13
14
Quality Control
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.
15
16
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
Operational definitions
Checklists
17
Quality Control
18
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
19
20
Quality Control - Outputs
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
21
Quality Control Outputs
22
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.
23
24
The Seven QC Tools

Identification
Analysis

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.
10
Total
13
34
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
10
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.
12
Statistical Sampling
Statistical sampling involves choosing part of a
population of interest for inspection.
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.

13
14
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)
15
16
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
20
Out of Control States
Out of Control States
Visual patterns indicating out-of-control state or a condition that requires

attention:

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.
21
22
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.
23
24
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
26
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

Mrs. Ghazala Amin
2 (8)
No.

Approved
MPM Internal
QUALITY ASSURANCE
DOCUMENT
Checked
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

No.

Approved
3 (8)
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

4 (8)
No.

Approved
MPM Internal
QUALITY ASSURANCE
DOCUMENT
Checked
Mrs. Ghazala Amin
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.

Mrs. Ghazala Amin
5 (8)
No.

Approved
MPM Internal
QUALITY ASSURANCE
DOCUMENT
Checked
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

6 (8)
No.

Approved
MPM Internal
QUALITY ASSURANCE
DOCUMENT
Checked
Mrs. Ghazala Amin
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.

7 (8)
No.

Approved
MPM Internal
QUALITY ASSURANCE
DOCUMENT
Checked
Mrs. Ghazala Amin
Date
Rev
Reference
document property
name.
A
Reports and Quality
Provided to
Provided
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:

Mrs. Ghazala Amin
8 (8)
No.

Approved
MPM Internal
QUALITY ASSURANCE
DOCUMENT
Checked
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

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
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
12
Quality Processes

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.
b.
10
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
14
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
16
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?
18
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
19
20
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.
21
22

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
24
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:
Page 929: Project Management Maturity Model
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:
28
Page 941: Continuous Improvement
Quality as an organizational goal
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

5
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.
10
Cost of Quality-Wikipedia
The cost of Quality

Investments in prevention
can drastically reduce total
cost of quality
11
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.
12
Feigenbaums quality cost areas
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
13
The Cost of Quality
14
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.
15
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
17
These Two Main Areas Can Be Split Further As Shown Below:
18
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
20
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
22

Lecture # 14
Six Sigma
References
Ghazala Amin
http://www.ge.com/sixsigma/SixSigma.
pdf
Six Sigma
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.

3
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.
10
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
15
68.27
317,300,000
95.45
45,400,000
99.73
2,700,000
99.9937
63,000
99.999943
57
99.9999998
16
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.
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

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
5-3
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

Key Definitions, continued
Quality Control (QC)
Quality Plan
Quality Policy
Quality Planning
Rework
Total Quality
Management (TQM)
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.

5-5
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.

Project Quality Management Processes

Quality Planning (8.1): (Process Group: Planning)
The process of identifying which quality standards are relevant to the project and
determining how to satisfy them.
One of the key facilitating processes during project planning, meaning it should be
performed regularly and in parallel with other project planning processes. For example:
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.
Inputs include: Quality policy, scope statement, product description, standards and
regulations, and other process outputs.
Quality policy:
The overall intentions and direction of an organization with regard to
quality, as formally expressed by top management.
When a formal quality policy is not available, or in the case of joint
ventures involving multiple performing organizations, the project
management team will need to develop a quality policy for the project.
Regardless of origin, the project management team is responsible for
ensuring that the project stakeholders are fully aware of the quality policy.
Other process outputs: outputs from other knowledge areas that should be
considered as part of quality planning. For example, procurement planning may
identify contractor quality requirements.
Methods used during quality planning include: benefit/cost analysis, benchmarking,
flowcharting, and design of experiments.
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.
The benefits of the quality management discipline outweigh the costs.
Benchmarking: 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.

5-7
Project Quality Management Processes, cont.

Flowcharting: a technique which creates a diagram that displays how various elements
of a system relate. Can assist the project team with anticipating what and where quality
problems may occur and with developing approaches for addressing the problems.
Flowcharts commonly used in quality management include:
Cause-and-effect diagrams: illustrate how various factors may be linked to
potential problems or effects. (also referred to as Ishikawa or fishbone
diagrams)
System or process flow charts: show how various elements of a system
interrelate.
Design of experiments:
A statistical method that helps identify which factors might influence specific
variables.
Is applied most frequently to the product of the project (e.g., automotive
designers may wish to determine which combination of suspension and tires will
produce the most desirable ride characteristics at a reasonable cost.)
Can also be applied to project management issues such as cost and schedule
tradeoffs. Example: senior engineers will cost more than junior engineers but will
usually complete the assignment in less time. An appropriately designed
experiment which computes project costs and duration for various combinations
of senior and junior engineers will often yield an optimal solution from a relatively
limited number of cases.
Cost of quality:
Refers to the total cost of all efforts to achieve product/service quality.
Includes all work to ensure conformance to requirements as well as all work
resulting from nonconformance to requirements.
Three types of incurred costs: prevention, appraisal, and failure where failure is
broken down into internal and external costs.
Quality Management Plan:
Describes how the project management team will implement its quality policy.
In ISO 9000 terminology, it should describe the project quality system: the
organizational structure, responsibilities, procedures, processes, and resources
needed to implement quality management.
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.
Operational definitions:
Describes in very specific terms what something is and how it is measured by the
quality control process.
Also called metrics in some application areas.


Checklists:
Usually a list of specific items that are used to verify that a set of required steps
has been performed.
May be simple or complex.
Usually phrased as imperatives (Do this!) or interrogatories (Have you done
this?).
Standardized in many organizations for frequently performed tasks.
Available from professional associations or commercial service providers in some
application areas.
Inputs to other processes: The quality planning process may identify a need for further
activity in another area.
Outputs include: Quality Management Plan, operational definitions, checklists, and
inputs to other processes.
Quality Assurance (8.2): (Process Group: Executing)
The process of evaluating overall project performance on a regular basis to provide

confidence that the project will satisfy the relevant quality standards.
Should be performed throughout the project.
Often, although not always, provided by a Quality Assurance Department or similarly
titled organization.
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.
Inputs include: Quality Management Plan, results of quality control measurements, and
operational definitions.
Results of quality control measurements: records of quality control testing and
measurement in a format for comparison and analysis.
Methods used include: quality planning tools and techniques and quality audits.
Quality planning tools and techniques: includes benefit/cost analysis,
benchmarking, flowcharting, checklists, etc.
Quality audits:
A structured review of other quality management activities.
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.
May be scheduled or random; may be carried out by trained in-house
auditors or by third parties such as quality system registration agencies.
Outputs include: quality improvement.
Includes taking action to increase the effectiveness and efficiency of the project
to provide added benefits to the project stakeholders.

5-9
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.
Quality Control (8.3): (Process Group: Controlling)
The process of monitoring specific project results to determine if the results comply with
relevant quality standards and identifying ways to eliminate causes of unsatisfactory
performance.
Should be performed throughout the project.
Project results include both product results such as deliverables and project
management results such as cost and schedule performance.
Often, although not always, provided by a Quality Control Department or similarly titled
organization.
Project management team should have a working knowledge of statistical quality
control, especially sampling and probability, to help evaluate quality control outputs.
The team may find it useful to know the differences between:
Prevention: keeping errors out of the process, versus,
Inspection: keeping errors out of the hands of the customer.
Attribute sampling: the result either conforms or it does not, versus,
Variables sampling: the result is rated on a continuos scale that measure that
degree of conformity.
Special causes: unusual events, versus,
Random causes: normal process variation.
Tolerances: the result is acceptable if it falls within the range specified by the
tolerance, versus,
Control limits: the process is in control if the result falls within the control limits.
Note: Result can be within the control limits of a process but out of tolerance.
Inputs include: work results (both process and product results), Quality Management
Plan, operational definitions, and checklists.
.
Methods used during quality control include: inspection, control charts, pareto
diagrams, statistical sampling, flowcharting, and trend analysis.
Inspection:
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.
Note: in some application areas these terms have narrow and specific
meanings.
Control charts:
Graphic displays of the results over time of a process.
Used to determine if the process is in control (e.g., are differences in the
results attributed to random variations or unusual events whose causes
must be identified and corrected?)
Although most frequently used to track repetitive activities such as
manufacturing lots, control charts may be used to monitor any type of

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

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

5-11
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.

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.

5-13
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

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

5-15
Project Quality Management Concepts, continued

Quality Concepts:
Zero Defects
Implies that there is no tolerance for errors within the system.
The goal of all processes is to avoid defects in the product or service.
Similar to six sigma: almost zero defects
The Customer is the Next Person in the Process
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.
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.
Do the Right Thing Right the First Time (DTRTRTFT)
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.
Continuous Improvement Process (CIP) (From Japanese word, Kaizen)
A concept which recognizes that the world is constantly changing and any
process that is satisfactory today may well be unsatisfactory tomorrow.
A sustained, gradual change to improve the situation.
Differs from innovation -- does not make a sudden jump to a plateau where it
matures over time. (see Ireland, I-6)
Focuses on 11 principles: constancy of purpose, commitment to quality,
customer focus and involvement, process orientation, continuous improvement,
system-centered management, investment in knowledge, teamwork,
conservation of human resources, total involvement, and perpetual commitment.
Rather than manage the output of the project, the focus is on managing the total
process and subprocesses. The process is held constant only after it has been
proven capable of the work. Hence, the product naturally meets the
requirements.
CIP steps:
Define and standardize processes (and subprocesses).
Assess process performance.
Improve processes.
Measure progress.


Project Characteristics/Attributes that bear on quality:
Producibility (technology required)

Ability of a product or service to be produced within the existing technology,
human resources, skills, knowledge, and materials at a cost compatible with
market expectations.
Producibility is one of the most critical aspects of developing any new product.
Usability (effort expended to use)
The ability of a product to perform its intended function for the specified user
under the prescribed conditions.
Usability is determined by examining performance, function and condition of a
product.
Reliability (Mean-Time-Between-Failure: MTBF)
The degree to which a unit of equipment performs its intended function under
specified conditions for a specified period of time.
Computed by 2 methods of Mean-Time-Between-Failure (MTBF):
Predicted MTBF: Based on a mathematical computation of a component
failure using a tree diagram to determine sequential failure aspects of the
component rated periods. Least desirable method because it cannot
account for environmental variations that can degrade components to
lower rates.
Actual MTBF: Use of field collected data to compute the failures under
realistic operating conditions to find the average time between failure.
The actual reliability will seldom be the same as the predicted reliability.
Maintainability (Mean-Time-To-Repair: MTTR)
The ability of a unit to be restored within a specified time to its performance
capability under the environmental operating conditions within a specified,
average period of time.
Availability (Probability of performance)
The probability of a product being capable of performing a required function
under the specified conditions when called upon.
The key parts of availability are reliability and maintainability.
Operability (Expected conditional use)
The ability of a product to be operated by human resources for specified periods
of time under given conditions without significant degradation of the output.
Flexibility (Expected variable use)
The ability of a product to be used for different purposes at different capacities
and under different conditions.
Social Acceptability (Environment and safety)
The degree of compatibility between the characteristics of a product or service
and the prevailing values and expectations of the relevant society
The degree to which a public accepts a product for use.

5-17
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

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

5-19
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)

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.)
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.

5-21
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


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.

5-23
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
2. The process of monitoring specific project results to determine if they comply with relevant
quality standards is called:
A. Quality Assurance
B. Quality Control
C. Quality Planning
D. Quality Review
3. A histogram ordered by frequency of occurrence that shows how many results were
generated by each identified cause is:
A. Statistical Histogram
B. Juran Histogram
C. Fishbone Diagram
D. Pareto Diagram
4. Tools and techniques used during the Quality Planning process include:
A. Benefit/cost analysis
B. Benchmarking
C. Quality audits
D. a and b
5. Top managements overall intentions and direction with regard to quality is formally
expressed in the:
A. Quality Plan
B. Quality Statement
C. Quality Policy
D. TQM
6. CIP is:
A. Synonymous with innovation
B. A sustained, gradual change
C. A substantial change which matures over time
D. The same as DTRTRTFT
7. The practice of ceasing mass inspections and ending awards based on price is credited to:
A. Edward Deming
B. Philip Crosby
C. Juran
D. Pareto

Sample Questions, continued

8. Which of the following are costs of quality?
A. Product design and process validation
B. Quality planning
C. Scrap, rework, product recalls, and warranty repairs or service
D. All the above
9. The concept of making a giant leap forward followed by a period of maturity is:
A. Innovation
B. Continuous improvement
C. Just in time
D. Paradigm
10. The concept that it is easier and less costly to do the work right the first time is called:
A. Zero defects
C. DTRTRTFT
D. The customer is the next person in the process
11. The ability of a product to be used for different purposes at different capacities and under
different conditions determines its:
A. Usability
B. Flexibility
C. Operability
D. Availability
12. Which of the following is not considered a cost of nonconformance to quality?
A. Scrap
B. Rework
C. Expediting
D. Process control
13. Which of the following statements is false?
A. The cost of quality is the total price of all efforts to achieve product or service quality.
B. The cost of non-quality is all expenditures that waste time, motion, material or other
valuable resources.
C. Having an acceptable quality level such as an allowable defect rate is an example of
a quality cost.
D. Acceptance of the extra burden of non-quality costs as a cost of doing business can
materially affect the profit of a project.
14. Which of the following statements regarding grade and quality is/are true?
A. The terms are synonymous.
B. Grade is a rank given to entities having the same functional use but different
characteristics while quality refers to the characteristics of an entity that bear on its
ability to satisfy stated or implied needs.
C. Low quality and low grade are always considered problematic.
D. B and C

5-25

15. A series of consecutive points on the same side of the average is called:
A. A run
B. A trend
C. An outliner
D. A cycle
16. Which of the following statements concerning acceptance sampling is true?
A. Acceptance sampling is used when it is expensive and time-consuming to test the
product 100%.
B. Inspection and test standards must be established to ensure that procedures can
adequately determine conformance and nonconformance.
C. If the number of defects found in the sample exceeds the predetermined amount, the
entire lot is rejected.
D. All of the above are true
17. The philosophy that the majority of defects are caused by a small percentage of the
identifiable problems can be contributed to:
A. Edward Deming
B. Philip Crosby
C. Juran
D. Pareto
18. A structured tool, usually industry or activity specific, used to verify that a set of required
steps has been performed is called:
A. Quality Policy
B. Check list
C. Trend analysis
D. Pareto diagram
19. A tool that analyzes the inputs of a process to identify the causes of errors is called:
A. Cause and effect diagram or Ishikawa diagram
B. Scatter diagram
C. Trend diagram
D. Pareto diagram
20. The concept of zero inventory is called:
A. Six sigma
C. Just in Time
D. Zero defects


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

5-27

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
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

Answer Sheet
1.
16.
2.
17.
3.
18.
4.
19.
5.
20.
6.
21.
7.
22.
8.
23.
9.
24.
10.
25.
11.
26.
12.
27.
13.
28.
14.
29.
15.
30.

5-29
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

PMP Certification Exam Preparation

What did I do wrong ?
I would have answered a larger number of questions

correctly if I had ___________.
Number
1. Read the question properly and identified the keywords
_________
2. Read the answer properly and identified the keywords
_________
3. Read ALL the answers before answering the question
_________
4. Used a strategy of elimination
_________
5. Known the formula
_________
6. Known the PMBOK definition
_________
7. Checked the mathematics
_________
8 Used the PMI rather than my own perspective
_________
9. Reviewed my answer after reading the other questions
_________
10. NOT rushed to finish
_________
Total
_________

5-31
Lecture # 17
PRM 702
Project Risk Management
Ghazala Amin

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

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

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
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
Category
Root
Cause
Triggers
Potential
Responses
Risk
Owner
Probabilit
y
Impact
Severity
Problem
No.
Rank
R44
Status
Staff
R21
Late delivery of hardware
R7
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)
15
16
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

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
medium
INCREASING
1.2
Lack of technical skills

in Client Business Unit
high
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:
Andrew.gordon@oaks.state.oh.us
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

OAKS
1.4
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

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
(Shirley.Whaley@oaks.state.oh.us) and Andrew Gordon (Andrew.Gordon@oaks.state.oh.us).
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

OAKS
2.3
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

OAKS
2.6
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

OAKS
2.9
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

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
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

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

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
No
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

OAKS
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

OAKS
3.1.3
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

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

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%

high likelihood of occurrence.
Medium
41-60%

moderate likelihood of
occurrence.
Low
21-40%

small likelihood of occurrence.
Very Low
1-20%

very small likelihood of
occurrence.
Page 13 of 35

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

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

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

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
High
Very High
High
61%-80%
Low
Medium
Medium
High
High
Medium
41%-60%
Low
Medium
Medium
Medium
High
Low
21%-40%
Low
Low
Low
Medium
Medium
Very Low
1%-20%
Very
Low
Low
Low
Low
Medium
Very
Low
Low
Medium
High
Very High
Severity of Impact
Figure 5 - Risk Rating

Page 17 of 35

OAKS
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

OAKS
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

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
No
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

OAKS
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

OAKS
Developing and Documenting a Risk Mitigation or Contingency Plan

A successful mitigation plan includes all the necessary steps (in sequential order) needed to
reduce the risks exposure. The sequential plan contains those steps that when completed in the
order given will successfully mitigate or eliminate the risk. Each step requires a corresponding
decrease in probability and/or impact. When the Risk Owner completes this plan, he or she
should e-mail it to the Risk Administrator who can include it in the appropriate reports to be
approved by the appropriate party (in most cases, the Project Team Lead at the regular Release
meetings).
At a minimum, every Risk Mitigation or Contingency Plan contains steps that will
successfully mitigate the risk to a lower severity level by the risk's targeted due date.
When completed, these steps should be sent to the Risk Administrator to ensure the
database is updated.
Should the Risk Owner need help in formulating the Risk Mitigation or Contingency Plan, the
Risk Owner should read the Risk Owner Guide, on the risk section of BI Designer website
(OAKS\Cabinets\Project Management\Risk Management\Risk Job Aids).
Obtain Approval For a Risk Mitigation or Contingency Plan
Risk mitigation plans are required for risks with Yellow or Red Risk Ratings. However, risk
mitigation and contingency plans may be developed for Green Risks as desired. The final Risk
Mitigation step for the Risk Owner is to obtain approval of the Risk Mitigation Plan. When the
Risk Owner documents the Risk Mitigation or Contingency Plan, the Project Team Lead or RM
Working Group reviews the plan. Should the Project Team Lead or RM Working Group have
any questions or need further clarification, they will contact the Risk Owner. At the next
Release Meeting or RM Working Group Meeting, the plan is reviewed and approved or denied.
Figure 5 illustrates the decision-making authority for each risk profile. The OAKS EL approves
mitigation plans regarding Very High severity level risks. The Project Team Leads or RM
Working Group approves mitigation plans involving High and Medium severity level risks.
Lo Med
Hi
Hi V.Hi
Lo Med Med Hi
OAKS Executive Leadership
Lo
Lo
V.Lo Lo
Lo Med
Lo Med Med
Lo
Lo Med
Hi
Hi
Lo Med Med Hi
Project Team Leads or RM WG
V.Hi
Hi
Lo Med Med Med Hi

Lo
Lo
V.Lo Lo
Lo Med
Lo Med Med
Lo
Lo Med
Hi
Hi
Lo Med Med Hi
No Mitigation Plan Required
Hi
Lo Med Med Med Hi
V.Hi
Hi
Lo Med Med Med Hi

Lo
Lo
V.Lo Lo
Lo Med Med
Lo
Lo
Med
Figure 7 - Risk Mitigation Approval Matrixes

Page 22 of 35

OAKS
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

OAKS
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

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
All
Once a week by Risk

Administrator, and as needed
by team members.
Risk Radar
Administrator
All
Once a week by Risk

by team members.
Detailed Reports (or

all risks) Sorted by ID
Risk Radar
Administrator
All
Once a week by Risk

by team members.
Short Term Risks

(Risks coming due in
the next 30 days)
Risk Radar
Administrator
All
Once a week by Risk

by team members.
Detailed Report (For

all risks) sorted by
owner
Risk Radar
Administrator
All
Once a week by Risk

by team members.
Detailed Report (For

all risks) sorted by
Rank
Risk Radar
Administrator
All
Once a week by Risk

by team members.
Risk Mitigation Steps

Past Due
Risk Radar
Administrator
All
Once a week by Risk

by team members.
Mid Term Risks (risks

coming due in the
next 31 90 days)
Risk Radar
Administrator
All
Once a week by Risk

by team members.
Risks Past Due
Table 2 - Standard Risk Notices and Reports
Page 25 of 35

OAKS
3.5
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

OAKS
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

OAKS
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

OAKS
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

OAKS
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

OAKS
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

OAKS
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

OAKS
DESIGN
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

OAKS
CODING
PACKAGES & REUSE
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

OAKS
TESTING
PROTOTYPES
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
<Insert
Company Logo
Here>
<Project Title>
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:
<Name>
<Title>
<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.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

<This paragraph shall briefly state the major risks for the
project.>
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.>

<This section contains information used to create the Risk
Table, and the values used for the risk management planning.
A sample table is shown below.>
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
ST
60%
Where:
Category is the risk category based on:
Product size
PS
Business impact
BU
Customer characteristics
CU
Process definition
PR
Development environment
DE
Reference
Technology
TE
Staff size and experience
ST
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

<This paragraph provide a description of the significant risk
items identified for the project:>
2.3 Factors influencing probability and impact

<This paragraph describes the impact assessment for the
significant project risks.>
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

1
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

<This section describes the schedule for reviewing and
revising the Risk Management Plan. Ad-hoc or scheduled
project milestones may be the triggers to revisit the Risk
Management Plan and revise the mitigation, monitoring, or
management decisions.>
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
10
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

This true incident can be explained, in part, by the message that was presented by James
Taylor, Senior Vice President of Gateway 2000, in his keynote address to the Project
Management Institute, in Long Beach (10/12/98). His theme was: "Denial is our biggest
enemy". Digging deeper, we will find that there are several dimensions to this denial.
Perhaps, in the company illustration above, the GM deliberately devalued the weight of
the potential downside because "he couldn't sell the venture if he admitted the risk".
Another dimension is our eternal optimism - preferring to look at the bright side.
Unfortunately, wishing that bad things won't happen is almost a sure way of establishing
an atmosphere that will breed unwanted events.
Written by Harvey Levine
Page 1 of 5
Courtesy of:
Scitor Corporation
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
Page 2 of 5
Courtesy of:
Scitor Corporation
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?
Page 3 of 5
Courtesy of:
Scitor Corporation
800/533-9876
Furthermore, in an environment of Project Portfolio Management, why not a Chief Risk

Officer? The CRO would be responsible for establishing standards for risk analysis and
management, and for implementing a system of risk practices and tools. The input of the
CRO would be required before a proposed project is accepted into the portfolio.
A Series of Closing Doors

As a youth group adviser, a few decades ago, I listened to a colleague tell a group of high
school kids that life was a series of closing doors. That they had all kinds of opportunities
under their control. That the decisions that they made and the actions that they took (or
didn't take) could allow some of those doors to become closed to them.
In a similar vein, Dr. Taylor suggested that a project is a series of closing doors. By the
decisions that we make and the actions that we take (or postpone), we tend to shut some
of these doors. As we move through a project there are fewer alternatives available to
address problems. This is a natural condition, that cannot be overcome by even the best
management practices. But what we can do is to minimize the problems and further, to
minimize the deleterious effect of the eventual problems, by organizing properly for
projects (with a CPO and a CRO), by implementing a solid risk management program,
and by fostering proactive management for early recognition and rectification of such
problems.
Page 4 of 5
Courtesy of:
Scitor Corporation
800/533-9876
Harvey A. Levine, with 38 years of service to the project management industry, is

founder of The Project Knowledge Group, a consulting firm specializing in PM
training, PM software selection, evaluation & implementation, and PM using
microcomputers.
He has implemented or enhanced the project management capabilities of numerous firms,
often combined with the selection or implementation of computerized project
management tools. Mr. Levine is considered the leading consultant to the project
management software industry and is recognized as the leading expert in tools for project
management.
He has been an Adjunct Professor of Project Management at Rensselaer Polytechnic
Institute and Boston University. And has conducted numerous project management
public seminars for ASCE, AMA, IBM, and PMI.
Mr. Levine is the author of the book "Project Management using Microcomputers", and
has been published extensively in other books, periodicals and videos.
Mr. Levine is a past president of the Project Management Institute and the recipient of
PMI's 1989 Distinguished Contribution to Project Management award. Recently, he was
recently elected as a Fellow of PMI.
Mr. Levine has offices in Saratoga Springs, NY and San Diego, CA and can be contacted
via e-mail at: LevineHarv@cs.com
Page 5 of 5
Courtesy of:
Sciforma Corporation
http://www.sciforma.com
8 0 0 / 5 3 3 -9 8 7 6
All Opportunities Have Risk

Uncover Hidden Risks with a Risk Breakdown Structure
Several years ago, we published a paper on this website, entitled Risk is a Four-letter Word, But
Denial is our Biggest Enemy at http://www.sciforma.com/resources/white_papers/Riskpuzl.htm.
We started with this story of certain failure.
The Downside Won't Happen

A company decided to enter into a new business segment. As was standard practice for this wellmanaged 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

This true incident can be explained, in part, by the message that was presented by James Taylor,
Senior Vice President of Gateway 2000, in his keynote address to the Project Management
Institute, in Long Beach (10/12/98). His theme was: "Denial is our biggest enemy". Digging
deeper, we will find that there are several dimensions to this denial. Perhaps, in the company
illustration above, the GM deliberately devalued the weight of the potential downside because he
felt that he couldn't sell the venture if he admitted the risk. Another dimension is our eternal
optimism--preferring to look at the bright side. Unfortunately, wishing that bad things wouldnt
happen is almost a sure way of establishing an atmosphere that will breed unwanted events.
Furthermore, an atmosphere of fear (fear of the truth) brings on such denial. The success-minded
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 ultimately lead to 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.
Page 1 of 5
Courtesy of:
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.
Page 2 of 5
Courtesy of:
8 0 0 / 5 3 3 -9 8 7 6
Page 3 of 5
Courtesy of:
8 0 0 / 5 3 3 -9 8 7 6
Assessing and Mitigating Risk

On each of these second-level items, the first question is, Does it apply? If the answer is yes,
then you want to describe the potential risk event. For each event, you then need to assess the
potential effect on schedule, cost, resources, deliverables, technical objectives, and commercial
objectives. The potential effect is the product of two estimates. First, what is the probability of
the event occurring? Second, what is the impact of the event, if it does happen?
Finally, you will want to consider options for containing the risks. Look for options to reduce the
probability of risk occurrence. Also, look for options to minimize the impact of risk events,
should they occur.
Summary
More people have written about risk management than have practiced it. Risk
Management is a way of dealing with uncertainty in projects. Every project has some
degree of uncertainty. Therefore, every project requires risk management.
o Risk Assessment & Management (RAM) requires a structured, proactive
approach.
o A risk WBS is a valuable element of a structured RAM system.
o Someone needs to be responsible for Risk Assessment & Management. Consider
having a Chief Risk Officer and requiring the CRO to sign-off on all proposed
projects.
An "accurate estimate" is an oxymoron.
o How reliable is your information?
How sensitive is the project to the risks?
o What is the ability to absorb impacts?
o For example: Being late for a dinner reservation can be tolerated. Being late for a
cruise ship departure cannot.
Avoid redundant or cumulative contingency.
o Contingency is important. Without it you will finish late and over budget.
However, there is a tendency to pile on contingencies so that they are redundant.
To avoid this, consider shared contingency. Apply contingency to groups rather
than individual items. For Instance: apply schedule contingency for a string of
tasks rather than to each task. Apply cost contingency to work packages, not
individual line items.
A guarantee against all risk may not be practical or economically feasible.
Risk is dynamic
o The probability and impact of risk can change as the project progresses. Consider
the time dimensions of risk and when to address the risk issues.
Maintain a Risk Issues directory
o Log all risk items. Identify a responsible party for each risk issue. Maintain an
audit trail of all communications and actions. Flag open risk items.
Dont forget the big picture.
Page 4 of 5
Courtesy of:
8 0 0 / 5 3 3 -9 8 7 6
o Consider risk issues at the project level. How well is the organization situated to
do this project? What is the organizations risk culture? What risk guidelines have
been established at the strategic level?
Harvey A. Levine, with 43 years of service to the project management industry, is founder of The Project
Knowledge Group, a consulting firm specializing in PM training, PM software selection, evaluation &
implementation, and PM using microcomputers. He has implemented or enhanced the project
management capabilities of numerous firms, often combined with the selection or implementation of
computerized project management tools. For more information on Harvey Levine or the Project
Knowledge Group, please visit http://home.earthlink.net/~halevine/.
Mr. Levine is the leading consultant to the project management software industry and is recognized as
the leading expert in tools for project management. He has been Adjunct Professor of Project
Management at Rensselaer Polytechnic Institute and Boston University. He has conducted project
management public seminars for ASCE, AMA, IBM, PMI.
Mr. Levine is the author of books, articles and videos on Project Management. His 2002 book, "Practical
Project Management: Tips, Tactics, and Tools", is still available from John Wiley & Sons. Mr. Levine's
new book, "Project Portfolio Management, A Practical Guide to Selecting Projects, Maintaining Portfolios,
and Maximizing Benefits", Jossey-Bass, was released in July, 2005. Mr. Levine is past president of the
Project Management Institute, a recipient of PMI's 1989 Distinguished Contribution to Project
Management award, and has been elected a Fellow of PMI.
Mr. Levine has offices in Saratoga Springs, NY and San Diego, CA. His e-mail address is:
halevine@earthlink.net.
Page 5 of 5
RISK BREAKDOWN STRUCTURE (RBS)
Project Risk
External
Internal
Organizational
Customer
Process
Culture
Stability
Planning
Financial
Managerial
Initiation
Communication
Labor
Close
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
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
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
Lecture #27

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

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
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

5

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
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
11
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
12
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
15
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
14
16
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
18
19
PRM 702
Lecture #28

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

Inputs
Outputs
Risk management plan
Risk Identification

Activity cost estimates
Activity duration estimates
Scope baselines
Stake holder baseline
Project planning documents
Enterprise environmental factors
Risk Identification
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

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
11
The process of examining each identified risk

to
Inputs
Risk register
Project scope statement
Estimate the probability

And predict the impact on the project.
It includes:
10
12
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
15
Outputs
Aims to analyze numerically the probability of

each risk and its consequence on project
objectives
Risk register updates
14
16

Outputs
Inputs

Risk register
17
19
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
18
What should be done

When it should be accomplished
Who is responsible
And associated cost and schedule.
20

Risk response options include:
Inputs
Acceptance
Avoidance
Mitigation
Transfer

Risk register
21
23
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
22
24
Reserves
Outputs
Management Reserve

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
25
27
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
26
Direct Property Damage

Indirect Consequential Loss
Legal Liability
Personnel
28
Inputs
Outputs
Risk register
Project management plan
Work performance information
Performance reports

Organizational process assets updates
Change requests
Project management plan updates
Project document updates
29

Tools & Techniques
Risk reassessment
Risk audits
Variance and trend analysis
Reserve analysis
Technical performance measurement
Status meetings
30
31
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: info@galorath.com
His website is www.galorath.com
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
Page 1
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
Page 2
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
sarim@pertmaster.com
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.
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
July 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.

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
"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.

8-3
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

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
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

8-5
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
Workaround

Project Risk Management Concepts

Project Risk Management:
Is the systematic process of identifying, analyzing, and responding to project risk.

Includes maximizing the probability and consequences of positive events and
minimizing the probability and consequences of adverse events to project objectives.
Project Risk:
Is an uncertain event or condition that, if occurs, has a positive or negative effect on a

project objective.
Has its origins in the uncertainty that is present in all projects.
Includes both threats (negative effects) to the projects objectives and opportunities
(positive effects) to improve on those objectives.
A risk has a cause and, if it occurs, a consequence.
Known risks are those that have been identified and analyzed and may be possible to
plan for their occurrence and mitigation.
Unknown risks cannot be managed, although project managers may address by
applying a general contingency based on past experience with similar projects.
Risks that are threats to the project may be accepted if they are in balance with the
reward that may be gained by taking the risk. Likewise, risks that are opportunities may
be pursued to benefit the projects objectives.
Organizations must be committed to addressing risk management throughout the
project. One measure of an organizations commitment is its dedication to gathering
high-quality data on project risks and the characteristics of the risks.

8-7
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.

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:
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.

8-9
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.

Care should be taken to explore relevant items that do not appear on a

standard checklist.
The checklist should itemize all types of possible risks to the project.
The checklist should be formally reviewed at every project-closing to
improve the list of potential risks and to improve the description of risks.
Assumptions analysis:
Every project is conceived and developed based on a set of
hypotheses, scenarios, or assumptions. Assumptions analysis is a
technique that explores whether or not the assumptions are valid.
Identifies project risks from inaccuracy, inconsistency, or
incompleteness of assumptions.
Diagramming techniques:
Cause-and-effect diagrams (also known as Ishikawa or fishbone
diagrams)
System or process flow charts
Influence diagrams - a graphical representation of a problem
showing causal influences, time ordering of events, and other
relationships among variables and outcomes.
Outputs include:
Risks: Uncertain events or conditions that, if occur, have a positive or negative
effect on project objectives.
Triggers: Indications that a risk has occurred or is about to occur. Also called
risk symptoms or warning signs. For example, failure to meet intermediate
milestones may be an early warning of an impending schedule delay.
Inputs to other processes: Risk identification may identify a need for further
action in another area. For example, the WBS may not have sufficient detail to
allow adequate identification of risks, or the schedule may not be complete or
entirely logical.
Qualitative Risk Analysis (11.3): (Process Group: Planning)
The process of assessing the impact and likelihood of identified risks.

Prioritizes risks according to their potential effect on project objectives.
A means for determining the importance of addressing specific risks and guiding risk
responses.
Requires that the probability and consequences of the risks be evaluated using
established qualitative-analysis methods and tools.
The importance of a risk may be magnified due to time-criticality of risk-related actions.
Trends in the results when qualitative analysis is repeated can indicate the need for
more or less risk-management action.
Use of these tools helps correct biases that are often present in a project plan.
Should be revisited during the projects life cycle to stay current with changes in the
project plan.

8-11
Inputs include:
Identified risks from the risk identification process.
Project status: The uncertainty of a risk often depends on the projects
progress through its life cycle. For instance, in the early stages of the project,
the design may be immature and changes are likely to occur, making it likely
that more risks will be discovered.
Project type: More common or recurrent type projects tend to have better
understood probability of occurrence of risk events and their consequences
versus state-of-the-art or leading-edge technology projects.
Data Precision: Describes the extent to which a risk is known and understood
by measuring the extent of data available as well as the reliability of the data.
The source of the data that was used to identify the risk must be evaluated.
Scales of probability and impact:
Probability scale: Scale runs from 0.0 (no probability) to 1.0
(certainty). Assessing risk may be difficult because historical data is not
often available. An ordinal scale representing relative probability values
from very unlikely to almost certain, or, a general scale with specific
probabilities such as 0.1, 0.3, 0.5, 0.7, etc., could be used.
Impact scale: Scale reflects the severity of its effect on the project
objective. Impact can be ordinal or cardinal, depending on the culture of
the organization performing the analysis. Ordinal scales are
ranked-order values such as very low, low, moderate, high, and very
high. Cardinal scales assign values, either linear or nonlinear, to these
impacts. Example of linear values: 0.1, 0.3, 0.5, 0.7, 0.9. Example of
nonlinear values: 0.05, 0.1, 0.2, 0.4, 0.8. Nonlinear values may be used
when an organization desires very much to avoid high-impact risks.
Assumptions identified during the risk identification process are evaluated as
potential risks.
Methods used during qualitative risk analysis include:
Risk probability and impact:
Risk probability is the likelihood that a risk will occur. Risk impact (or
consequences) is the effect on project objectives if the risk event occurs.
These two dimensions of risk are applied to specific risk events, not to
the overall project.
This technique helps identify those risks that should be managed
aggressively.

Probability-impact risk rating matrix:

A matrix that assigns risk ratings (very low, low, moderate, high, and very
high) to risks or conditions based on combining probability and impact
scales.
The risk rating is determined using a matrix and risk scales for each risk.
The organization must determine which combinations of probability and
impact result in a risks being classified as a high risk (red condition),
moderate risk (yellow condition), and low risk (green condition) for either
a cardinal or ordinal approach.
The risk score helps put the risk into a category that will guide risk
response actions.
Project assumptions testing: Identified assumptions must be tested against
two criteria: assumption stability and the consequences on the project if the
assumption is false.
Data precision ranking: A technique used to evaluate the degree to which the
data about risks is useful for risk management. It involves examining:
Extent of understanding of the risk.
Data available about the risk.
Quality of the data.
Reliability and integrity of the data.
Outputs include:
Overall risk ranking for the project:
Indicates the overall risk position of a project relative to other projects by
comparing the risk scores.
Can be used to assign personnel or other resources to projects with
different risk rankings, to make a benefit-cost analysis decision about a
project, or to support a recommendation for project initiation,
continuation, or cancellation.
List of prioritized risks: Risks and conditions can be prioritized or grouped by
a number of criteria including:
Risk rank or WBS level
Urgency (risks requiring an immediate response versus those which can
be handled later)
Risk impact type (cost, schedule, functionality, quality, etc.)
List of risks for additional analysis and management: Risks classified as high
or moderate would be prime candidates for more analysis, including quantitative
risk analysis, and for risk management action.
Trends in qualitative risk analysis results: As the analysis is repeated, a
trend of results may become apparent, and can make risk response or further
analysis more or less urgent and important.

8-13

Quantitative Risk Analysis (11.4):
(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:
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.

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.

8-15
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:
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.

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.

8-17
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.
Risk Monitoring and Control (11.6): (Process Group: Controlling)
The process of keeping track of the identified risks, monitoring residual risks and
identifying new risks, ensuring the execution of risk plans, and evaluating their
effectiveness in reducing risks.
Records risk metrics that are associated with the implementation of contingency plans.
Is an ongoing process for the life of the project.
Provides information that assists with effective decision making in advance of the risk
occurrence.
The purpose of risk monitoring is to determine whether or not:
Risk responses have been implemented as planned.
Risk response actions are as effective as expected, or if new responses should
be developed.

Project assumptions are still valid.

Risk exposure has changed from its prior state, with analysis of trends.
A risk trigger has occurred.
Proper policies and procedures are followed.
Risks have occurred or arisen that were not previously identified.
Risk control may involve choosing alternative strategies, implementing a contingency
plan, taking corrective action, or replanning the project.
The risk response owner should report periodically to the project manager and the risk
team leader on the effectiveness of the plan, any unanticipated effects, and any
midcourse correction needed to mitigate the risk.
Inputs to risk response control include:
Risk response plan
Project communication: work results, issue logs, action-item lists, escalation
notices, project records, etc.
Additional risk identification and analysis: As project performance is
measured and reported, potential risks not previously identified may surface.
Should follow cycle of six risk management processes.
Scope changes: Changes to the scope often require new risk analysis and
response plans.
Methods used during risk monitoring and control:
Project risk response audits:
Risk auditors examine and document the effectiveness of the risk
response in avoiding, transferring, or mitigating risk occurrence as well
as the effectiveness of the risk owner.
Risk audits are performed during the project life cycle to control risk.
Periodic project risk reviews:
Should be regularly scheduled.
Project risk should be an agenda topic at all team meetings.
Risk ratings and priorities may change during the course of the project
and may require additional qualitative or quantitative analysis.
Earned value analysis:
Used for monitoring overall project performance against a baseline plan.
If earned value analysis (or comparable tool) shows a significant
deviation from the baseline, updated risk identification and analysis
should be performed.
Technical performance measurement:
Compares technical accomplishments during project execution to the
project plans schedule of technical achievement.
Deviation can imply a risk to achieving the projects objectives.
Additional risk response planning: May be required for unanticipated risks or
for risks where the impact was greater than expected.

8-19
Outputs include:
Workaround plans:
Unplanned responses to emerging risks that were previously unidentified
or accepted.
Must be properly documented and incorporated into the project plan and
risk response plan.
Corrective action: Execution of the contingency plan or workaround.
Project change requests: Change requests to the project plan as a result of
implementing contingency plans or workarounds.
Updates to the risk response plan:
Risk events that do occur should be documented as such and evaluated.
Implementation of risk controls may reduce the impact or probability of
identified risks.
Risk rankings must be reassessed so that new, critical risks may be
properly controlled.
Risk events that do not occur should be documented as such and closed
in the risk response plan.
Risk database:
A repository that provides for collection, maintenance, and analysis of
data gathered and used in the risk management processes.
Use of this database will assist risk management throughout the
organization and form the basis of a risk lessons learned program over
time.
Updates to risk identification checklists: Checklists updated from experience
will help risk management of future projects.

Project Risk Management Concepts

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)
Scope of project risk management lies somewhere between the two extremes of total
certainty and total uncertainty
Spectrum: Total Uncertainty, General Uncertainty, Specific Uncertainty, and Total
Certainty
Spectrum: Unknown Unknowns (no information), Known Unknowns (partial
information), and Knowns (complete information)
Management Reserves handle unknown unknowns while contingency reserves
handle known unknowns**
** PMBOK Guide considers these as knowns.

8-21
Sample Questions
1
Which of the following processes is not part of Project Risk Management?

A. Qualitative Risk Analysis
B. Risk Identification
C. Risk Analysis
D. Risk Response Planning
2. Using the PMBOK Guide definition of contingency reserve, which of the following
statements about contingency reserves is false?
A. A contingency reserve is a separately planned quantity of money or time that has been
set aside to allow for future situations which may be planned for only in part.
B. Contingency reserves are used to reduce the risks of overruns of project objectives to
a level acceptable to the organization.
C. Contingency reserves may be set aside for known risks.
D. Contingency reserves can be included in the projects cost and schedule estimates
without any identifying documentation.
3. Which of the following is not a tool or technique used during the Quantitative Risk Analysis
process?
A. Earned value analysis
B. Interviewing
C. Decision Trees
D. Sensitivity Analysis
4. Which of the following statements regarding pure risk is false?
A. The risk can be deflected or transferred to another party through a contract or
insurance policy. Also referred to as insurable risk.
B. Pure risks involve the chance of both a profit and a loss.
C. No opportunities are associated with pure risk, only threats.
D. Pure risk could be classified as a known-unknown risk.
5. A contingency plan is:
A. A planned response that defines the steps to be taken if an identified risk event should
occur.
B. A workaround
C. A comprehensive listing of many possible risks that might occur on a project.
D. a and b
6. The inherent chances for both profit or loss associated with a particular endeavor is called:
A. Favorable risk
B. Opportunity risk
C. Pure risk
D. Business risk


7. A risk response which involves eliminating a threat is called:
A. Mitigation
B. Deflection
C. Avoidance
D. Transfer
8. Deflection or transfer of a risk to another party is part of which of the following risk
response categories?
A. Mitigation
B. Acceptance
C. Avoidance
D. Transference
9. When should risk identification be performed? (select best answer)
A. During Concept Phase
B. During Development Phase
C. During Implementation Phase
D. Risk identification should be performed on a regular basis throughout the project.
10. Which of the following statements is false?
A. Uncertainty and risk are greatest at the start of the project and lowest at the end.
B. The amount at stake is lowest at the end of the project and greatest at the start.
C. Analysis of risks using probability and consequences helps identify those risks that
should be managed aggressively.
D. Opportunities are positive outcomes of risk.
11. A contingency plan is executed when:
A. A risk is identified.
B. An identified risk event occurs.
C. When a workaround is needed.
D. All of the above
12. A risk probability or impact scale that uses rank-ordered values such as very low, low,
moderate, high, and very high is called:
A. An ordinal scale
B. A cardinal scale
C. A nonlinear scale
D. All of the above
13. Organizations that desire very much to avoid high-impact risks may use which of the
following techniques during qualitative risk analysis? Choose the best answer.
A. Avoidance
B. Data precision ranking with low precision
C. A probability-impact risk rating matrix using nonlinear scales
D. The organization would not use any techniques

8-23

14. What is the Delphi technique as it relates to the risk identification process?
A. An information-gathering technique where experts perform a Strengths, Weaknesses,
Opportunities, Threats (SWOT) analysis.
B. An information-gathering technique where experts are briefed about the project and
then interviewed for their opinions.
C. An information-gathering technique where experts meet and generate ideas about
project risk.
D. An information-gathering technique where experts participate anonymously and ideas
about project risk are gathered via a circulated questionnaire.
15. Which of the following are considered tools and techniques for qualitative risk analysis?
A. Risk probability and impact, probability-impact risk rating matrix, and data precision
ranking
B. Interviewing, sensitivity analysis, decision tree analysis, and simulation
C. Avoidance, transference, mitigation, and acceptance
D. Checklists, sensitivity analysis, and simulation
16. A contingency plan has a 20% chance of failing. The corresponding risk event has a 30%
chance of occurring. Whats the probability for the risk to occur AND the contingency plan
to fail?
A. 50%
B. 25%
C. 6%
D. 10%
17. The independence of two events in which the occurrence of one is not related to the
occurrence of the other is called:
A. Event phenomenon
B. Independent probability
C. Statistical independence
D. Statistical probability
18. Which of the following documents is primarily used as an input into the Risk Identification
Process?
A. Risk Management Plan
B. WBS
C. Scope Statement
D. Contingency Plan
Risks are accepted when:
A. The project team decides to transfer the risk to a third party.
B. The project team decides not to change the project plan to deal with a risk or is unable
to identify any other suitable response strategy.
C. The project team reduces the probability and consequences of an adverse risk event
to an acceptable threshold.
D. Risks are never accepted.

20. 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 is usually called the:
A. Executive reserve
B. Project manager slush fund
C. Contingency reserve
D. Mitigation buffer
21. By using Project Risk Management techniques, project managers can develop strategies
that do all but which of the following:
A. Significantly reduce project risks
B. Eliminate project risks
C. Provide a basis for better decision making on overruns
D. Identify risk, their impact(s) and any appropriate responses
22. In the following network, all three tasks, A, B and C, each have a duration 5 days. The
value p indicates the probability of each task finishing on schedule. If all 3 tasks start on
day 1, what is the probability that all 3 tasks will finish in 5 days?
A. p = .4
B. p = .003
C. p = .014
D. Probability cannot be determined from the data given
Task A
p=0.1
Task B
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

8-25

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
Option A
Option B
Option C
Option D
25. Risk avoidance involves:

A. Accepting the consequences
B. Developing a contingency plan
C. Eliminating a specific threat, usually by eliminating the cause
D. Reducing the effect of the risk event by reducing the probability of the occurrence
26. Examples of probability distributions used in quantitative risk analysis are:
A. Six-sigma distributions
B. Probability-impact matrix distributions
C. Delphi distributions
D. Beta and triangular distributions
27. When developing a risk response plan, which risks should you focus on first? Choose the
best answer.
A. Near term risks with a high probability of occurrence
B. High impact risks with a low probability of occurrence
C. Risks with a high risk score
D. a and c


28. Warning signs that indicate a risk has occurred or is about to occur are called:
A. Risks
B. Triggers
C. Sign posts
D. Stop gaps
29. What is risk event probability? Choose the best answer.
A. The value used in mitigation and deflection
B. An estimate of the probability that a given risk event will occur
C. The probability of the risk not occurring at this time
D. An estimate of the probability that an uncontrollable event will occur
30. A project of $1.5 million has an adverse event that has a probability of 0.07 of occurring
and a potential loss of $15,000. This represents an expected negative monetary value of
how much?
A. $100,500
B. $105
C. $1,050
D. $15,000

8-27
Answer Sheet
1.
16.
2.
17.
3.
18.
4.
19.
5.
20.
6.
21.
7.
22.
8.
23.
9.
24.
10.
25.
11.
26.
12.
27.
13.
28.
14.
29.
15.
30.

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, 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, glossary
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
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. 134, Wideman pg. VII-2
$15,000 x .07 = $1,050

8-29
PMP Certification Exam Preparation

What did I do wrong ?
I would have answered a larger number of questions

correctly if I had ___________.
Number
1. Read the question properly and identified the keywords
_________
2. Read the answer properly and identified the keywords
_________
3. Read ALL the answers before answering the question
_________
4. Used a strategy of elimination
_________
5. Known the formula
_________
6. Known the PMBOK definition
_________
7. Checked the mathematics
_________
8 Used the PMI rather than my own perspective
_________
9. Reviewed my answer after reading the other questions
_________
10. NOT rushed to finish
_________
Total
_________


Project Quality &amp; Risk Management-Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Quality &amp; Risk Management-Manual

Uploaded by

Copyright:

Available Formats

Project Quality and Risk Management - Module Handbook- MSPM II

Project Quality and Risk

Department of Management Sciences, CIIT Islamabad

Project Quality and Risk Management - Module Handbook- MSPM II

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

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

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

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

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

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

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

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

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

Department of Management Sciences, CIIT Islamabad

Project Quality and Risk Management - Module Handbook- MSPM II

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

Contacting the Module Instructor

Rationale Including Aims

Department of Management Sciences, CIIT Islamabad

Project Quality and Risk Management - Module Handbook- MSPM II

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

Project Quality and Risk Management

Project Quality and Risk Management:

Project Risk Management Concepts, Analysis, Identification and Mitigation:

Department of Management Sciences, CIIT Islamabad

Project Quality and Risk Management - Module Handbook- MSPM II

Individual reading and study, together with lectures.

Ability to understand various case studies.

Assignment#1 after 8 weeks

Mid-term examination after 09 weeks

Quiz#2 after 13 weeks

Terminal Examination after 16 week

Study Notes and class discussions

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

Dr. Harold Kerzners book

Course Requirements and Expectations

Department of Management Sciences, CIIT Islamabad

Project Quality and Risk Management - Module Handbook- MSPM II

Department of Management Sciences, CIIT Islamabad

Project Quality and Risk Management - Module Handbook- MSPM II

Department of Management Sciences, CIIT Islamabad

What Went Wrong?

*Design News (February 1988).

Quality is defined by the customer

Excellence, Luxury, Prestige, or Grade

Other experts define quality based on:

Difference between Quality and Grade?

Other experts define quality based on:

Low quality is always a problem; low

Difference between Quality and Grade?

Dimensions of Quality for Goods

Or, a software product may be of low

Service Quality Attributes

Costs & market

Defining Quality -ities

Salability: Other Definitions

Salability: the balance between quality and cost

the quality of being salable or marketable

Defining Quality -ities

Defining Quality -ities

Produce ability: the ability to produce the product

Flexibility: The ability of a product to be used for

Social acceptability: the degree of conflict

Availability: the probability that the product, when

Project Quality & Risk Management-Manual

Project Quality & Risk Management-Manual