PMBOK 5th Edition Study Notes

of 61
Project Management Processes
Knowledge area Process Definition Inputs Tools & Techniques Outputs
Integration
Management
Includes the processes
& activities to identify,
define, combine, unify,
& coordinate the
various processes &
project management
activities within the
project management
process groups
Integration includes
making choices about
resource allocation,
making tradeoffs,
among competing
objectives and
alternatives, and
managing the
interdependencies
among the project
management
knowledge area. The
project deliveries may
also need integrating
with ongoing
operations of the
performing org, the
requesting org, and
long term strategic
planning that takes
future problems and
opportunities into
considerations.
Also includes the
activities needed to
manage project
documents to ensure
consistency with the
project management
plan and product,
service or capability
deliverables
Some activities
performed by project
management team are
(1) Develop, review,
analyze and
understand the scope.
This includes the
project and product
requirements, criteria,
assumptions,
constraints, & other
influences related to a
project & how each
Process Group: Initiating
4.1 Develop Project Charter
It is the process of developing a document that formally authorizes
the existence of a project and provides the project manager with the
authority to apply organizational resources to project activities
Benefits: Is a well-defined project start and project boundaries,
creation of a formal record of the project, and a direct way for senior
management to formally accept and commit to the project
Project charter establishes a partnership between the performing &
the requesting organization. In case of external projects, a formal
contract is typically the preferred way to establish an agreement. A
charter is still used to established internal agreements within an
organization to assure proper delivery under the contract.
(1) The approved charter formally initiates the project
(2) The project charter should be authored by the sponsoring entity
(3) The project charter provides the project manager with the
authority to plan and execute the project
(4) It is recommended that project manager participate in the
development of the project charter, to obtain a functional
understanding of the project requirements. The understanding will
better allow for efficient resource allocation to project activities
(5) Projects are initiated by an entity external to the project such as
sponsor, program or project management office (PMO) staff person,
or a portfolio governing body chairperson or authorized
representative
(6) The project initiator or sponsor should be at a level that is
appropriate to procure funding or commit resources to the project
(7) Chartering a project validates alignment of the project to the
strategy and ongoing work of the organization
(8) A project charter is not considered to be a contract, because
there is no consideration of money promised or exchanged in its
creation.
(1) Project Statement of Work: Narrative
description of products, services or results to be
delivered by a project. For internal projects, the
project initiator or sponsor provides the SOW
based on business needs, products or service
requirements. For external projects, the SOW
can be received from the customer as part of
the bid document (RFP, RFI, RFB) or as part of
contract.
(1.1) Business Need: & The Cost Benefit
Analysis are contained in the Business Case
(1.2) Product Scope Description: Documents the
characteristics of the product, service or results
that the project will be undertaken to create.
The description should also document the
relationship between the products, services, or
the results being created and the business need
that project will address
(1.3) Strategic Plan
(2) Business Case: Describes the necessary
information from a business standpoint to
determine whether or not the project is worth
the required investment. Typically, the business
need and the cost-benefit analysis are
contained in the business case to justify and
establish boundaries for the project. It is
commonly used for decision making by
managers or executives above the project level.
Such analysis is usually completed by a business
analyst using various stake holder inputs. The
sponsor should agree to the scope and the
limitations of the business case.
(2.1) Business Need
(A) Market Demand
(B) Organizational Need
(C) Customer Request
(D) Technological Advance
(E) Legal requirement
(F) Ecological Impacts
(G) Social Need
(2.2) Project Selection Methods
(A) Benefit Measurement Methods
• Murder Board
• Peer Review
• Scoring Models
• Economic Models
o Present Value
o Net Present Value (NPV)
o Internal Rate of Return (IRR)
o Payback Period
o Cost-Benefit Analysis (CBA)
(B) Constrained Optimization Methods
• Linear Programming
• Integer Programming
• Dynamic Programming
• Multi-Objective Programming
(3) Agreements
(3.1) MOU, SLA, LOA, LOI, Verbal, email or
other written agreements
(1) Expert Judgment
(1.1) Other units within the organization
(1.2) Consultants
(1.3 Stakeholders, including customers or
sponsors
(1.4) Professional or Technical Associations
(1.5) Industry Groups
(1.6) Subject Matter Experts (SME)
(1.7) Project Management Office (PMO)
(2) Facilitation Techniques
(2.1) Brainstorming
(2.2) Conflict Resolution
(2.3) Problem Solving
(2.4) Meeting Management
(1) Project Charter
(1.1) Project Purpose or Justification
(1.2) Measurable project objectives and related success
criteria.
(1.3) High-level requirements
(1.4) Assumptions & Constraints
(1.5) High level project descriptions and boundaries
(1.6) High-level risks
(1.7) Summary milestone schedule
(1.8) Summary budget
(1.9) Stakeholder list
(1.10) Project approval requirements
(A) What constitutes project success?
(B) Who decides the project is successful?
(C) Who signs off on the project?
(1.11) Assigned project manager, responsibility and
authority level
(1.12) Name and authority of the sponsor or other
person(s) authorizing the project charter

of 61
will be managed or
addressed with in the
project.
(2) Transform the
collected project
information into a
project management
plan using a structured
approach as described
in the project mgmt.
guide.
(3) Perform activities
to produce project
deliverables
(4) Measure & monitor
the project progress &
take appropriate action
to meet project
objectives.
(3.2) Contracts are used for external customer
(4) Enterprise Environmental Factors
(5) Organizational Process Assets
Process Group: Planning
4.2 Develop Project Management Plan
It is the process of defining, preparing, and coordinating all
subsidiary plans and integrating then into a comprehensive project
management plan.
Benefits: It is a central document that defines the basis of all
project work.
(1) Project Management Plan defines how the project is executed,
monitored & controlled, and closed.
(2) The project management plan’s content varies depending upon
the application area and complexity of the project.
(3) Project Management Plan is progressively elaborated by updates
and controlled and approved through the Perform Integrated Change
Control Process
(4) Projects that exists in context of a program should develop a
project management plan that is consistent with the program
management plan.
(1) Project Charter
(2) Outputs from Other processes
(3) Enterprise environmental factors
(4) Organizational process assets
(1) Expert Judgment
(2) Facilitation Techniques
(2.1) Brainstorming
(2.2) Conflict Resolution
(2.3) Problem Solving
(2.4) Meeting Management
(1) Project Management Plan
(1.1) Scope Baseline
(1.2) Schedule Baseline
(1.3) Cost Baseline
(1.4) Scope Management Plan
(1.5) Requirements Management Plan
(1.6) Schedule Management Plan
(1.7) Cost Management Plan
(1.8) Quality Management Plan
(1.9) Process Improvement Plan
(1.10) Human Resource Management Plan
(1.11) Communications Management Plan
(1.12) Risk Management Plan
(1.13) Procurement Management Plan
(1.14) Stakeholder Management Plan
(1.15) Change Management Plan
(1.16) Configuration Management Plan
(1.17) Life cycle selected for the project & processes for
each phase
(1.18) Details of tailoring decisions specified by the project
management team
(A) Project Management Processes selected by the
project management team
(B) Level of implementation for each selected
processes
(C) Description of tool and techniques to be used for
accomplishing those processes
(D) Description of how the selected process will be
used to manage the specific project, including the
dependencies and interactions among those
processes and the essential inputs and outputs
(1.19) Description of how the integrity of project baseline
will be maintained
(1.20) Stakeholder communication requirements and
techniques
(1.21) Description of how work will be executed to
accomplish project deliverables
(1.22) Key mgmt. reviews for content, the extent of, &
timing to address open issues & pending decisions
Process Group: Execution
4.3 Direct and Manage Project Work
It is the process of leading and performing the work defined in the
project management plan and implementing approved changes to
achieve the project’s objectives.
Benefits: It provides overall management of the project work.
Direct and Manage project work include
(1) Perform activities to accomplish project activities
(2) Create project deliverables to meet the planned project work
3) Provide, train and manage the team members assigned to the
project
(2) Approved Change Requests: are an output
of the PICC process, and include those requests
reviewed and approved for implementation by
the change control board
(2.1) Corrective Action: An intentional activity
that realigns the performance of the project
work with the project management plan
(2.2) Preventive Action: An intentional activity
that ensures the future performance of the
project work is aligned with the project
management plan
(2.3) Defect Repair: An intentional activity to
(1) Expert Judgment
(2) Project Management Information
Systems (PMIS)
(3) Meetings
(3.1) Information Exchange
(3.2) Brainstorming, option evaluation or
design
(3.3) Decision Making
(1) Deliverables: A deliverable is any unique and verifiable
product, result or capability to perform a service that is
required to be produced to complete a process, phase or
project. Deliverables are typically tangible components
completed to meet the project objectives and can include
components of the project management plan.
(2) Work performance data: Are the raw observations and
measurements identified during activities being performed
to carry out the project work. Data are often viewed as
lowest level of detail from which information is derived by
other processes. Data is gathered through work execution
and passed to the controlling process for further analysis.
(3) Change Requests: A formal proposal to modify any
document, deliverable, or baseline. An approved change
request will replace the associated document, deliverable
or baseline and may result in update to other parts of the
project management plan. Request for change can be

of 61
(4) Obtain, manage, and use resources including materials, tools,
equipment and facilities
(5) Implement the planned methods and standards
(6) Establish and manage project communication channels, both
external and internal to the project team
(7) Generate work performance data, such as cost, schedule,
technical and quality progress, and status to facilitate forecasting
(8) Issue change requests and implement approved changes, into
the project scope, plans, and environment
(9) Manage risk and implement risk response activities
(10) Manage sellers and suppliers
(11) Manage stakeholders and their engagements
(12) Collect and document lessons learned and implement approved
process improvement activities
(13) Review of the impact of all project changes and the
implementation of approved changes.
(14) During project execution the work performance data is collected
and appropriately actioned and communicated
modify a non-conforming product or product
component.
(4) Organization Process Assets
direct or indirect, externally or internally initiated, and can
be optional or legally / contractually mandated and may
include corrective action, preventive action, defect repair
and updates.
(4) Project Management Plan Updates
(4.6) Process Management Plan
(4.13) Cost Baseline
(5) Project Documents Update
(5.1) Requirements Documentation
(5.2) Projects Logs (issues, assumptions, risk register,
stakeholder register)
Process Group: Monitoring & Controlling
4.4 Monitor and Control Project Work
It is the process of tracking, reviewing, and reporting the progress to
meet the performance objectives defined in the project management
plan
Benefits: It allows stakeholders to understand the current state of
the project, the steps taken, and budget, schedule and scope
forecasts.
Monitoring includes collecting, measuring, and distributing
performance information, and assessing measurements and trends to
effect process improvements. Continuous monitoring gives the
project management team insight into the health of the project and
identifies any area that may require special attention
Control includes determining corrective or preventive actions or re-
planning and following upon actions plans to determine whether the
actions taken resolved the performance issue.
The monitoring and control project work process is concerned with
(1) Comparing actual project performance against the project
management plan
(2) Assessing performance to determine whether any corrective or
preventive actions are indicated, and then recommending those
actions as necessary
(3) Identifying new risks and analyzing, tracking, and monitoring
existing project risks to make sure the risks are identified, their
status is reported, and that the appropriate risk response plans are
being executed.
(1.6) Communication Management Plan
(1.13) Cost Baseline
(2) Schedule Forecasts
(2.1) Time Estimate to Complete (ETC)
(2.2) Schedule Variance (SV)
(2.3) Schedule Performance Index (SPI)
(3) Cost Forecasts
(3.1) Estimates to Complete (ETC)
(3.2) Cost Variance (CV)
(3.3) Cost Performance Index (CPI)
(4) Validated Changes
(5) Work Performance Information: is the
performance data collected from various
controlling processes, analyzed in context, and
integrated based on relationships across areas.
Thus work performance data has been
transformed into work performance information
(1) Expert Judgment
(2) Analytical Techniques
(2.1) Regression Analysis
(2.2) Grouping Methods
(2.3) Casual Analysis
(2.4) Root Cause Analysis
(2.5) Forecasting Methods
(A) Judgment Methods (Qualitative)
• Salesforce estimates
• Executive Opinion
• Market Research
• Delphi Method
(B) Quantitative Methods
• Linear Regression (Casual)
• Time-Series Analysis
o Naïve Forecast
o Simple Moving Average
o Weighted Moving Average
o Exponential Smoothing
o Trend-Adjusted Exponential
Smoothing method
o Multiplicative Seasonal Method
o Additive Seasonal Method
(2.6) Failure Mode & Effect Analysis
(FMEA): An analytical procedure in which
each potential failure mode in every
component of a product is analyzed to
determine its effect on the reliability of that
component and, by itself or in combination
with other possible failure modes, on the
reliability of the product or system and on
the required function of the component; or
the examination of a product (at the system
and/or lower levels) for all ways that a
failure may occur. For each potential failure,
(1) Change Requests
(1.1) Corrective Action
(1.2) Preventive Action
(1.3) Defect Repair
(2) Work Performance Reports: are the physical or
electronic representation of work performance information
complied in project documents, intended to generate
decisions, actions or awareness. Work performance
reports are the subset of project documents.
(3.8) Cost Baseline
(4) Project Documents Updates
(4.1) Schedule forecasts
(4.2) Cost forecasts
(4.3) Work Performance Reports
(4.4) Issue log

of 61
(4) Maintaining an accurate, timely information base concerning the
projects products and their associated documentation through
project completion
(5) Providing information to support status reporting, progress
measurement and forecasting
(6) Providing forecasts to update current cost and current schedule
information
(7) Monitoring implementation of approved changes as they occur
(8) Providing appropriate reporting on project progress and status to
program management when the project is part of an overall program
an estimate is made of its effect on the total
system and of its impact. In addition, a
review is undertaken of the action planned
to minimize the probability of failure and to
minimize its effects.
(2.7) Fault Tree Analysis (FTA)
(2.8) Reserve Analysis
(2.9) Trend Analysis
(2.10) Earned Value Management
(2.11) Variance Analysis
(3) Expert Judgment
(4) Project Management Information
Systems (PMIS)
4.5 Perform Integrated Change Control
It is the process of reviewing all change requests; approving changes
and managing changes to deliverables, organizational process assets,
project documents, and the project management plan; and
communicating the disposition. It reviews all requests for changes or
modifications to project documents, deliverables, baselines, or the
project management plan and approves or rejects the changes.
Benefits: It allows for documented changes within the project to be
considered in an integrated fashion while reducing project risk, which
often arises form changes made without considerations to the overall
project objectives or plan.
PICC process is conducted from project inception through completion
and is the ultimate responsibility of the project manager
Changes may be requested by any stake holder involved with the
project. Although changes may be initiated verbally, they should be
recorded in written form and entered into the change management /
or configuration management system.
Configuration Management System: A subsystem of overall project
management system. It is a collection of formal documented
procedures used to apply technical and administrative direction and
surveillance to:
(1) Identify and document the functional and physical characteristics
of a product, result, service, or component
(2) Control any changes to such characteristics;
(3) Record and report each change and its implementation status;
(4) Support the audit of the products, results, or components to
verify conformance to requirements.
It includes the documentation, tracking systems, and defined
approval levels necessary for authorizing and controlling changes.
Every documented change request needs to be either approved or
rejected by a responsible individual, usually the project sponsor or
project manager. The responsible individual will be identified in the
project management plan or by organizational procedures.
When required, the PICC process includes a Change Control Board
(CCB), which is formally chartered group responsible for reviewing,
evaluating, approving, delaying, or rejecting changes to the project,
and for recording and communicating such decisions. The applied
level of change control is dependent upon the application area,
complexity of the specific project, contract requirements, and the
context and environment in which the project is performed.
(2) Work Performance Reports
(2.1) Resource Availability
(2.2) Schedule & Cost Data
(2.3) EVM Reports
(2.4) Burn up & Burn down Charts
(3) Change Requests
(5) Organization Process Assets
(1) Expert Judgment
(2) Meetings
(3) Change Control Tools
(1) Approved Change Requests
(2) Change Log
(3.1) All subsidiary plans
(3.2) Baselines that are subject to change control process
Relationships among Portfolio, Programs, and Projects
Portfolio: Refers to a collection of projects, programs, sub-portfolios and operations managed as a group to achieve strategic objectives.
Programs: are grouped within a portfolio and are comprised of subprograms, projects, or other work that are managed in coordinated fashion in
support of the portfolio. Although the projects or programs within the portfolio may not necessarily be interdependent or directly related, they are linked
to the organization’s strategic plan by means of the organization’s portfolio.
Project: A project is a temporary endeavour undertaken to create a unique product, service or result. Temporary nature indicates a definite beginning
and end. A project ends when the project objectives have been achieved, when the project is terminated because its objectives will not or cannot be
achieved, or when the need for the project no longer exists. The outcome of the project may be tangible or intangible. Most projects are undertaken to
create a lasting outcome. Although repetitive elements may be present in some project deliverables and activities, this repetition does not change the
fundamental, unique characteristics of the project work. Because of the unique nature of projects, there may be uncertainties or differences in products,
services, or results that the project creates. In addition, projects are undertaken at all organizational levels. A project can involve a single individual or
multiple individuals, a single organization unit, or multiple organizational units from multiple organizations
What Project creates? A product that can be either component of other item, an enhancement of an item, or am end item in itself. A service or a
capability to perform a service. An improvement in existing products or service lines (6sigma). A result such as an outcome ot document (eg research
project)

of 61
Configuration control is focused on the specification of both the
deliverables and the processes; while change control is focused on
identifying, documenting, and approving or rejecting changes to the
project documents, deliverables, or baselines. Some configuration
management activities included in PICC are as follows
(1) Configuration Identification: Identification and selection of a
configuration item to provide a basis for which the product
configuration is defined and verified, documents and products are
labeled, changes are managed, and accounting is maintained.
(2) Configuration Status Accounting: Information is recorded and
reported as to when appropriate data about the configuration item
should be provided. This information includes a listing of approved
configuration identification, status of proposed changes to the
configuration, and the implementation status of the approved
changes
(3) Configuration Verification & Audit: ensures the composition of a
projects configuration items is correct and that corresponding
changes are registered, assessed, approved, tracked, and correctly
implemented. This ensures the functional requirements defined in
the configuration documentation have been met.
Process Group: Closing
4.6 Close Project or Phase
It is the process of finalizing all activities across all of the Project
Management Process Groups to formally complete the project or
phase.
Benefits: It provides lessons learned, the formal ending of project
work, and the release of organization resources to pursue new
endeavors.
When closing the project, the project manager reviews all prior
information from the previous phase closure to ensure that all
project work is completed and that the project has met his objectives
Since project scope is measured against the project management
plan, the project manager reviews the scope baseline to ensure
completion before considering the project closed.
Step by step methodologies that address
(1) Actions and activities necessary to satisfy completion or exit
criteria for the phase or project
(2) Actions & activities necessary to transfer the project’s products
services or results to the next phase or to production and / or
operations.
(3) Activities needed to collect project or phase records, audit project
success or failure, gather lessons learned and achieve project
information for future use by the organization.
(2) Accepted Deliverables
(1) Expert Judgment
(2.1) Regression Analysis
(3) Meetings
(3.1) Lessons learned
(3.2) Close out
(3.3) User Group
(3.4) Review Meetings
(1) Final Product, service, or result transition
(2) Organizational Process Assets Updates
(2.1) Project Files: Documentation resulting from the
project’s activities, for e.g. project management plan,
scope, cost, schedule, and project calendars; risk registers
and other registers; change management documentation;
planned risk response actions; and risk impact
(2.2) Project of Phase Closure Documents: Consists of
formal documentation that indicates completion of project
or phase and the transfer of the completed project or
phase deliverables to others, such as an operations group
or to the next phase. During project closure, the project
manager reviews prior phase documentation, customer
acceptance documentation from the validate scope
process, and the contract (if applicable), to ensure that all
project requirements are completed prior to finalizing the
closure of the project. If the project was terminated prior
to completion, the formal documentation indicates why
the project was terminated and formalizes the procedures
for the transfer of finished and unfinished deliverables of
the cancelled project to others.
(2.3) Historical Information
Scope
Management
Includes processes
required to ensure that
the project includes all
the work required, and
only the work
5.1 Plan Scope Management
It is the process of creating a scope management plan that
documents how the project scope will be defined, validated, and
controlled
Benefits: It provides guidance and direction on how scope will be
(2) Project Charter
(1) Expert Judgment
(2) Meetings
(1) Scope Management Plan: Component of project or
program management plan that describes how the scope
will be defined, developed, monitored, controlled and
verified. Scope management plan is a major input to the
Develop Project Management Plan Process. The
components of the scope management plan include
(1.1) Process for preparing detailed project scope
statement
(1.2) Process that enables the creation of WBS from the
Project Management: Application of knowledge, skills, tools and techniques to project activities to meet the project requirements. Project
management is accomplished through the appropriate application and integration of the 47 logically grouped project management processes, which
are categorized into 5 process groups. These five groups are
(1) Initiating (2) Planning (3) Executing (4) Monitoring & Controlling (5) Closing
Project management develops and implements plans to achieve a specific scope that is driven by the objectives of program or portfolio it is subjected
to and, ultimately to organizational strategies.

of 61
required, to complete
the work successfully.
Managing the project
scope is primarily
concerned with
defining and
controlling what is and
is not included in the
project.
In term scope can
refer to
(1) Product Scope:
Features and functions
that categorize a
product, service or
result.
(2) Project Scope:
Work performed to
deliver a product,
service, or result with
the specified features
and functions. The
term project scope is
sometimes viewed as
including product
scope
The scope baseline for
the project is the
approved version of
the project scope
statement, WBS, and
its associated WBS
dictionary. A baseline
can be changed only
through formal change
control procedures and
is used as a basis for
comparison while
comparing validate
scope and control
scope processes as
well as other
controlling processes.
Completion of the
project scope is
measured against the
project management
plan.
Completion of product
scope is measured
against the product
requirements.
managed throughout the project.
The development of the scope management plan and the detailing of
the project scope begin with the analysis of the information
contained in the project charter, the latest approved subsidiary plans
of the project management plan, historical information contained in
the organizational process assets and any other relevant enterprise
environmental factors.
This plan helps reduce the project scope creep.
Scope Creep: Is the uncontrolled expansion to product or project
scope without adjustments to time, cost, and resources.
detailed project scope statement
(1.3) Process that establishes how the WBS will be
maintained and approved
(1.4) Process that specify how formal acceptance of the
completed deliverables will be obtained
(1.5) Process that control how requests for changes to the
detailed project scope statement will be processed (This
process is directly linked to PICC process)
(2) Requirements Management Plan: Component of the
project management plan that describes how the
requirements will be analyzed, documented and managed.
The phase-to-phase relationship strongly influences how
the requirements are managed. The project manager
chooses the most effective relationship for the project and
documents this approach in the requirements
management plan.
(2.1) How requirements activities will be planned tracked
and reported
(2.2) Configuration management activities such as: how
changes to the project will be initiated, how impacts will
be analyzed, how they will be tracked, and reported as
well as authorization levels required to approve these
changes.
(2.3) Requirement prioritization process
(2.4) Product metrics that will be used and the rationale
for using them
(2.5) Traceability structure to reflect which requirement
attributes will be captured on the traceability matrix
5.2 Collect Requirements
It is the process of determining, documenting, and managing
stakeholder needs and requirements to meet project objectives.
Benefits: It provides the basis for defining and managing the
project scope and including the product scope.
Requirements become the foundation of WBS, cost, schedule, quality
planning, and sometimes procurements are based upon these
requirements. The development of requirements begins with analysis
of information contained in the project charter, the stakeholder
register, and the stakeholder management plan.
(1) Scope Management Plan
(2) Requirements Management Plan
(3) Stakeholder Management Plan
(4) Project Charter
(5) Stakeholder Register
(1) Interviews
(2) Focus Groups: They bring together
prequalified stakeholders and subject
matter experts to learn about their
expectations and attitudes about a
proposed product, service, or result. A
trained moderator guides the group through
an interactive discussion, designed to be
more conversational than one-on one
interview.
(3) Facilitated Workshops: are focused
sessions that bring key stakeholders
together. Workshops are considered a
primary technique for quickly defining cross-
functional requirements and reconciling
stakeholder differences. Because of their
interactive group nature, well-facilitated
sessions can build trust, foster relationships,
and improve communication among
participants, which can lead to increased
stakeholder consensus. In addition, issues
can be discovered earlier and resolved more
quickly than in individual sessions.
(3.1) Joint Application Design/Development
(JAD): are used in software development
industry. These facilitated sessions focus on
bringing business SME’s and the
development team together to improve the
software development process
(3.2) Quality Function Deployment (QFD):
Used in the manufacturing industry that
helps determine critical characteristics for
new product development. QFD starts by
(1) Requirements Documentation: Describes how the
individual requirements meet the business need of the
project. Requirements may start at a high level and
become progressively more detailed as more about the
requirements is known. Before being baselined
requirements needs to be unambiguous (measureable and
testable), traceable, complete, consistent, and acceptable
to key stakeholders. Components of requirements
documentation include.
(1.1) Business Requirements
(A) Business & Project objectives for traceability
(B) Business rules for the performing organization
(C) Guiding principles of the organization
(1.2) Stakeholder requirements
(A) Impacts to other organizational areas
(B) impacts to other entities inside and outside the
performing organization
(C) Stakeholder communication and reporting
requirements
(1.3) Solution requirements
(A) Functional and nonfunctional requirements
(B) Technology and standard compliance
requirements
(C) Support and training requirements
(D) Quality Requirements
(E) Reporting requirements
(1.4) Project requirements
(A) Levels of service, performance, safety, compliance
etc
(B) Acceptance criteria
(1.5) Transition requirements
(1.6) Requirements assumptions, dependencies, and
constraints
(2) Requirements Traceability Matrix: is a grid that links
Progressive Elaboration: Involves continuously improving and detailing a plan as more detailed and specific information and more accurate estimates
become available. Progressive elaboration allows a project management team to define work and manage it to a greater level of detail as the project evolves.
Project Constraints:
(1) Scope (2) Quality (3) Schedule (4) Budget (5) Resources (6) Risks
Project Boundary: is defined as the point in time at which the start or completion of the project or project phase
is authorized.

of 61
collecting customer needs also known as
the voice of the customer (VOC). These
needs are then objectively and goals are set
for achieving them.
(3.3) User stories: Which are short, textual
descriptions of required functionality, are
often developed during a requirements
workshop. User stories describe the
stakeholders who benefits from the feature
(role), what the stakeholder needs to
accomplish (goal), and the benefit to the
stakeholder (motivation). User stories are
widely used with agile methods.
(4) Group Creativity Techniques
(4.1) Brainstorming: A technique used to
generate and collect multiple ideas related
to project and product requirements.
Although brainstorming by itself does not
include voting or prioritization, it is often
used with other group creativity techniques
that do
(4.2) Nominal Group Technique: A
technique that enhances brainstorming with
a voting process used to rank the most
useful ideas for further brainstorming or for
prioritization
(4.3) Idea/Mind Mapping: A technique in
which ideas created through individual
brainstorming sessions are consolidated into
a single map to reflect commonality and
differences in understanding, and generate
new ideas.
(4.4) Affinity Diagram: A technique that
allows large numbers of ideas to be
classified into groups for review and
analysis
(4.5) Multi criteria decision analysis: A
technique that utilizes a decision matrix to
provide a systematic analytical approach for
establishing criteria, such as risk levels,
uncertainty, and valuation, to evaluate and
rank many ideas
(5) Group Decision Making Techniques
(5.1) Unanimity: A decision that is reached
whereby everyone agrees on a single
course of action. One way to reach
unanimity is the Delphi Technique, in which
a selected group of experts answers
questionnaires and provides feedback
regarding the responses from each round of
requirement gathering. The responses are
only available to the facilitator to maintain
anonymity
(5.2) Majority: A decision that is reached
with support obtained from more than 50%
of the members of the group. Having a
group size with an uneven no. of
participants can ensure that a decision will
be reached, rather than resulting in a tie
(5.3) Plurality: A decision that is reached
whereby the largest block in a group
decides, even if a majority is not achieved.
This method is generally used when the
product requirements from their origin to the deliverables
that satisfy them. The implementation of a requirements
traceability matrix helps ensure that each requirement
adds business value linking it to the business and project
objectives. It provides a means to track requirements
throughout the project lifecycle, helping to ensure that the
requirements approved in the requirements
documentation are delivered at the end of the project.
Finally it provides a structure for managing changes to the
product scope.
(2.1) Tracing includes
(A) Business needs, opportunities, goals and
objectives
(B) Project Objectives
(C) Project Scope/WBS deliverables
(D) Product Design
(E) Product Development
(F) Test Strategy & Test scenarios
(G) High-level requirements to more detailed
requirements
(2.2) Attributes: Attributes associated with each
requirement can be recorded in the requirements
traceability matrix. These attributes helps to define key
requirements help to define key information about the
requirement. Typical attributes used in the requirements
traceability matrix may include.
(A) A unique identifier
(B) Requirement description
(C) Rationale for inclusion
(D) Owner, Source, Priority, Version
(E) Current Status (Active, Cancelled, Deferred,
Added, Approved, Assigned, Completed)
(F) Status Date
(G) Stability
(H) Complexity
(I) Acceptance Criteria
Project Management Office: A management structure that standardizes the project related governance processes and facilitates the
sharing or resources, methodologies, tools and techniques. Responsibility of PMO can vary from providing project management support
functions to actually being responsible for the direct management of one or more projects
Types of PMO:
(1) Supportive: Provide a constructive role to projects by supplying templates, best practices, training, access to information and lessons
learned from other projects. This type of PMO serves as a project repository. The degree of control provided by the PMO is low.
(2) Controlling: Provide support and require compliance through various means. Compliance may involve adopting project management
frameworks or methodologies, using specific templates, forms and tools, or conformance to governance. The degree of control provided by
the PMO is moderate.
(3) Directive: This type of PMO takes control of the projects by directly managing the projects. The degree of control provided by the PMO is
high.
Integrates data and information from corporate strategic projects and evaluates how higher level strategic objectives are being fulfilled
Natural liaison between the organization’s portfolios, programs, projects and the corporate measurement system
Projects supported or administered by the PMO may not be related, other than by being managed together
May have the authority to act as integral stakeholder and a key decision maker throughout the life of each project, to make recommendations,
or to terminate projects or take other actions, as required, to remain aligned with the business objectives. The PMO may be involved in the
selection, management and deployment of shared or dedicated project resources.
Functions of PMO:
(1) Managing shared resources across all projects administered by the PMO
(2) Identifying and developing project management methodology, best practices, and standards
(3) Coaching, mentoring, training and oversight
(4) Monitoring compliance with project management standards, policies, procedures, and templates, by means of project audit.
(5) Developing and managing project policies, procedures, templates, and other shared documentation (OPA)
(6) Coordinating Communication across projects
Project Management Vs PMO
(1) Focuses on specified project objectives (1) Manages major program, scope changes which may be seen as potential
opportunities to better achieve business objectives
(2) Controls the assigned project resources to best meet (2) Optimizes use of shared resources across all projects
Project objective
(3) Manages the constraints (scope, schedule, cost, quality, (3) Manages the methodologies, standards, overall risks / opportunities
Etc) of the individual projects matrices and interdependencies among projects at enterprise level.

of 61
number of options nominated is more than
two.
(5.4) Dictatorship: In this method, one
individual makes the decision for the group.
(6) Questionnaires & Surveys
(7) Observations: provide a direct way of
viewing individuals in their environment and
how they perform their jobs or tasks and
carry out processes. It is particularly helpful
for detailed processes when the people that
use the product have difficulty or are
reluctant to articulate their requirements
(7.1) Job Shadowing: It is usually done
externally by an observer viewing a
business expert performing a job.
(7.2) Participant Observer: Who actually
performs a process or procedure to
experience how it is done to uncover hidden
requirements
(8) Prototypes: Supports the concept of
progressive elaboration in iterative cycles of
mock-up creation, user experimentation,
feedback generation, and prototype
revision. When enough feedback cycles
have been performed, the requirements
obtained from the prototype are sufficiently
complete to move to a design or build
phase.
(8.1) Storyboarding: is a prototyping
technique showing sequence or navigation
through a series of images or illustrations.
Storyboards are used on a variety of
projects in a variety of industries, such as
film, advertising, industrial design, and on
agile and other software development
projects. In software development,
storyboards use mock-ups to show
navigation paths through webpages,
screens, or other user interfaces.
(9) Benchmarking: involves comparing
actual or planned practices, such as
processes and operations, to those of
comparable organizations to identify best
practices, generate ideas for improvement,
and provide a basis for measuring
performance
(10) Context Diagrams: is an e.g. of scope
model. Context diagrams visually depict the
product scope by showing a business
system (process, equipment, computer
system, etc) and how people and other
systems (actors) interact with it. Context
diagrams show inputs to the business
system, the actor(s) providing the input, the
outputs from the business system, and the
actors receiving the output.
(11) Document Analysis: is used to elicit
requirements by analyzing existing
documentation and identifying information

of 61
relevant to the requirements. E.g of
documents that may be analyzed include,
business plans, marketing literature,
agreements, requests for proposal, current
process flows, logical data models, business
rules, repositories, application software
development, business process or interface
documentation, user cases, other
requirement documentation, problem/issue
logs, policies, procedures, and regulatory
documentation such as laws, codes, or
ordinances, etc
5.3 Define Scope
It is the process of developing a detailed description of the project
and product.
Benefits: It describes the product, service, or result boundaries by
defining which of the requirements collected will be included in and
excluded from the scope.
Define scope process selects the final project requirements from the
requirements documentation delivered during the Collect
Requirement Process. It then develops the detailed description of the
project and product, service, or result.
The define scope process can be highly iterative. In iterative life
cycle projects, a high-level vision will be developed for the overall
project but the detailed scope is developed one iteration at a time
and the detailed planning for the next iteration is carried out as work
progresses for the current project scope and deliverables.
(2) Project Charter
(3) Requirements Documentation
(1) Expert Judgment
(2) Product Analysis
(2.1) Product Breakdown
(2.2) Systems Analysis
(2.3) Requirements Analysis
(2.4) Systems Analysis
(2.5) Value Engineering: An approach used
to optimize project life cycle costs, save
time, increase profits, improve quality,
expand market share, solve problems, and /
or use resources more effectively
(2.6) Value Analysis
(3) Alternatives Generation
(3.1) Brainstorming
(3.2) Lateral Thinking
(3.3) Analysis of Alternatives
(4) Facilitated Workshops
(1) Project Scope Statement: The project scope statement
documents the entire scope including the project and
product scope. It describes in details the project
deliverables and the work required to create those
deliverables. It may contain explicit scope exclusions that
can assist in managing stakeholder expectations. Detailed
project scope statement includes the following
(1.1) Product scope description
(1.2) Acceptance Criteria
(1.3) Deliverable: Also includes ancillary results, such as
project management reports & documentation
(1.4) Project exclusions
(1.5) Constraints: Internal or external limiting factors that
affects the execution of a project or progress
(1.6) Assumptions: A factor in the planning process
considered to be true, real, or certain, without proof or
demonstrations. Also describes the potential impact of
those factors if they prove to be false.
(2.1) Stakeholder register
(2.2) Requirements documentation
(2.3) Requirements traceability matrix
5.4 Create WBS
It is the process of subdividing project deliverables and project work
into smaller, more manageable components.
Benefits: It provides a structured vision of what has to be delivered.
The WBS is a hierarchical decomposition of the total scope of work to
be carried out by the project team to accomplish the project
objectives and create the required deliverables. The work organizes
and defines the total scope of the project, and represents the work
specified in the current approved project scope statement.
The planned work is contained in the lowest level of WBS
components, which are called Work Packages.
Work Packages: A work package is used to group the activities where
work is scheduled and estimated, monitored, and controlled. The
work package is the work defined at the lowest level of WBS for
which cost & duration can be estimated. In the context of the WBS,
work refers to work products or deliverables that are the result of
activity and not to the activity itself. The level and details of work
package will vary with the size and complexity of the project.
(2) Project Scope Statement
(1) Decomposition: It is the technique used
for dividing & subdividing the project scope
and project deliverables, into smaller more
manageable parts. The level of
decomposition is often guided by the
degree of control needed to effectively
manage the project. Decomposition of the
total project work into work packages
generally involves the following activities
(1.1) Identifying and analyzing the
deliverables and related work
(1.2) Structuring and organizing the WBS
(1.3) Decomposing the upper WBS levels
into lower-level detailed components
(1.4) Developing and assigning
identification codes to the WBS component
(1.5) Verifying that the degree of
decomposition of the deliverable is
appropriate.
(2) Expert Judgment: is often used to
analyze the information needed to
decompose the project deliverables down
into smaller component parts in order to
create an effective WBS. Such judgment
and expertise is applied to technical details
of the project’s scope and used to reconcile
differences in opinion on how to best
(1) Scope Baseline: is the approved version of a scope
statement, WBS, and its associated WBS dictionary, that
can be changed only through formal change procedures
and is used as a basis for comparison. It is the component
of the project management plan. Components of the
scope baseline include
(1.1) Project Scope Statement
(1.2) WBS: The WBS is finalized by assigning each work
package to a control a/c and establishing a unique
identifier for that work package from a code of accounts
(A) Identifier: These identifiers provide a structure for
hierarchical summation of costs, schedule and
resource information.
(B) Control Account: Is a management control point
where scope, budget, actual cost, and schedule
are integrated and compared to the earned value
for performance measurement. Control a/c’s are
placed at selected management points in the
WBS. Each Control a/c may include one or more
work packages, but each of the work packages
should be associated with only one control a/c. A
control a/c may include one or more planning
packages
(C) Planning Package: Is a work breakdown structure
component below the control a/c with known
work content but without detailed schedule
activities.
(1.3) WBS Dictionary: Is a document that provides

of 61
breakdown the overall scope of the project.
This level of expertise of provided by any
group or individual with relevant training,
knowledge, or experience with similar
projects or business areas. Expert judgment
can also come in the form of predefined
templates that provide guidance on how to
effectively breakdown common deliverables.
The project manager, in collaboration with
the project team, then determines the final
decomposition of the project scope into the
discrete work packages that will be used to
effectively manage the work of the project.
(2.1) Top-Down Approach, use of
Organization specific guidelines & WBS
Templates
(2.3) Bottom-Up Approach: During
integration of sub components
(2.4) Decomposition: of the upper level
WBS components requires subdividing the
work for each of the deliverables or
subcomponents into its most fundamental
elements, where the WBS components
represent verifiable products, services, or
results. The WBS may be structured as an
outline, an organization chart, or other
method that identifies a hierarchical
breakdown. Verifying the correctness of the
decomposition requires determining that the
lower-level WBS components are those that
are necessary and sufficient for completion
of the corresponding higher-level
deliverables. Different deliverables have
different levels of decomposition. To arrive
at the work package, the work for some
deliverables needs to be decomposed only
to the next level, while others need
additional level of decomposition. As the
work is decomposed to greater level of
detail, the ability to plan, manage, and
control the work is enhanced. However,
excessive decomposition can lead to
nonproductive management effort,
inefficient use of resources, decreased
efficiency in performing the work, and
difficulty aggregating data over different
levels of the WBS
(2.5) Rolling Wave Planning: Decomposition
may not be possible for a deliverable or
subcomponent that will be accomplished far
into the future. The project management
team usually waits, until the deliverable or
sub component is agreed on, so the details
of the WBS can be developed.
(2.6) 100% Rule: The WBS represents all
project and product work, including the
project management work. The total of the
work at the lowest levels should roll up to
the higher levels so that nothing is left out
and no extra work is performed.
(2.7) The WBS Structure
(A) Using phases of the project life
cycle as the second level of
decomposition, with the product
and project deliverables inserted at
detailed deliverable, activity, and scheduling information
about each component in the WBS.
(A) Code of account identifier
(B) Description of work
(C) Assumptions and constraints
(D) Responsible organization
(E) Schedule Milestone
(F) Associated schedule activities
(G) Resources required
(H) Cost estimates
(I) Quality requirements
(J) Acceptance criteria
(K) Technical reference
(L) Agreement Information
Organizational Project Management (OPM): OPM is a strategy execution framework utilizing project, program, and portfolio
management as well as organizational enabling practices to consistently and predictably deliver organizational strategy producing better
performance, better results, and a sustainable competitive advantage. OPM advances organizational capability by linking project, program
and portfolio management principles and practices with organizational enablers (eg structural, cultural, technological and HR practices) to
support strategic goals.

of 61
the third level
(B) Using major deliverables as the
second level of decomposition
(C) Incorporating subcomponents
which may be developed by
organizations outside the project
team, such as contracted work. The
seller then develops the supporting
contract WBS as part of the
contracted work
5.5 Validate Scope
It is the process of formalizing acceptance of the completed
variables.
Benefits: It brings objectivity to the acceptance process and
increases the chance of final product, service or result acceptance by
validating each deliverable
The verified deliverables obtained from the control quality process
are reviewed with the customer or sponsor to ensure that they are
competed satisfactorily and have received formal acceptance of the
deliverables by the customer or sponsor.
In this process, the outputs obtained as a result of the planning
processes in the project scope management area, such as the
requirements documentation or the scope baseline as well as the
work performance data obtained from the execution processes in
other knowledge areas, are the basis for performing the validation
and for final acceptance.
The validate scope process differs from the quality control process in
that the former is primarily concerned with acceptance of
deliverables, while quality control is primarily concerned with
acceptance of deliverables, while quality control is primarily
concerned with correctness of deliverables and meeting the quality
requirements specified for the deliverables
(3) Requirements Traceability Matrix
(4) Verified Deliverables
(5) Work Performance Data
(1) Inspection
(2) Group-Decision Making Techniques
(1) Accepted Deliverables
(2) Change Requests
5.6 Control Scope
It is the process of monitoring the status of the project and product
scope and managing changes to the scope baseline.
Benefits: It allows the scope baseline to be maintained throughout
the project.
(1.4) Configuration Management Plan
(3) Requirements Traceability Matrix
(1) Variance Analysis: is a technique for
determining the cause and degree of
difference between the baseline and actual
performance. Project performance
measurements are used to assess the
magnitude of variation from the original
scope baseline. Important aspects of
project scope control include determining
the cause and degree of variance relative to
the scope baseline and deciding whether
corrective or preventive action is required.
(1) Work Performance Information
(2) Change Requests
(3.1) Scope Baseline Updates
(A) Project Scope Statement
(B) WBS
(C) WBS Dictionary
(3.2) Other Baseline Updates (if required)
(3.2.1) Cost Baseline
(3.2.2) Schedule Baseline
(4) Project Document Updates
(4.2) Requirements Traceability Matrix
(5) Organizational Process Updates
(5.1) Causes of Variances
(5.2) Corrective action chosen and the reasons
(5.3) Lessons learned from project scope control
Time
Management
Process Group: Planning (1) Project Management Plan
(1) Expert Judgment (1) Schedule Management Plan
(1.1) Project Schedule Model Development: The

of 61
Processes required to
manage timely
completion of the
project.
Schedule Model: is a
representation of the
plan for executing the
project’s activities
including durations,
dependencies, and
other planning
information, used to
produce project
schedules along with
other scheduling
artifacts.
6.1 Plan Schedule Management
It is the process of establishing the policies, procedures, and
documentation for planning, developing, managing, executing, and
controlling the project schedule.
Benefits: It provides guidance and direction on how the project
schedule will be managed throughout the project.
Is a component of project management plan, may be formal or
informal, highly detailed or broadly framed, based upon the needs of
the project and includes appropriate control thresholds. It defines
how the schedule contingencies will be reported and addressed. The
schedule management plan may be updated to reflect a change in
the way the schedule is managed. The schedule management plan is
a mojor input to the Develop Project Management Plan process
(1.2) Cost, Risk and Communications
(2) Project Charter
(3) Meetings
scheduling methodology and the scheduling tool to be
used in the development of the project schedule model
are specified.
(1.2) Level of accuracy
(1.3) Units of measure
(1.4) Organizational procedure links
(1.5) Project schedule model maintenance
(1.6) Control thresholds
(1.7) Rules of performance measurements: Earned Value
Management (EVM) rules or other physical measurement
are set. Schedule management plan may specify
(A) Rules of establishing % complete
(B) Control accounts at which management of
progress and schedule will be measured
(C) Earned Value Management techniques to be
employed
(D) Schedule performance measurements such as
schedule variance (SV) and schedule performance
index (SPI) used to assess the magnitude of
variation of the original schedule baseline.
(1.8) Reporting formats
(1.9) Process descriptions: Description of each of the
schedule management process are documented.
6.2 Define Activities
It is the process of identifying and documenting the specific actions
to be performed to produce the project deliverables.
Benefits: Is to breakdown work packages into activities that provide
a basis for estimating, scheduling, executing, monitoring, and
controlling the project work.
Implicit in the process are defining and planning the schedule
activities such that the project activities will be met.
The create WBS process identifies the deliverables at the lowest level
in the WBS – the work package. Work packages are typically
decomposed into smaller components called activities that represent
the work effort required to complete the work packages.
(1) Schedule Management Plan
(2) Scope Baseline
(1) Decomposition: Is a technique used for
dividing and subdividing the project scope
and project deliverables into smaller, more
manageable parts. Activities represent the
effort needed to complete a work package.
The define activities process defines the
final outputs as activities rather than
deliverables, as done in the create WBS
process. The activity list, WBS, and WBS
dictionary can be developed either
sequentially or concurrently, with the WBS
and WBS dictionary as he basis for
development of the final activity list. Each
work package within the WBS is
decomposed into the activities required to
produce the work package deliverables.
(2) Rolling Wave Planning: It is an iterative
planning technique in which the work to be
accomplished in the near term is planned in
detail, while the work in the future is
planned at higher level. It is a form of
progressive elaboration. Therefore, work
can exist at various levels of detail
depending on where it is in the project life
cycle. During early strategic planning, when
information is less defined, work packages
may be decomposed into the known level of
detail. As more is known about the
upcoming events in the near term, work
packages can be decomposed into activities.
(3) Expert Judgment
(1) Activity List: Is a comprehensive list that includes all
schedule activities required on the project. The activity list
also includes the activity identifier and a scope of work
description for each activity in sufficient detail to ensure
that the project team members understand what work is
required to be completed. Each activity should have its
unique title that describes its place in the schedule, even if
that activity title is displayed outside the context of the
project schedule.
(2) Activity Attributes: Activities distinct from milestones,
have durations, during which the work of that activity is
performed, and may have resources and costs associated
with that work. Activity attributes extend the description
of the activity by identifying the multiple components
associated with each activity. The component for each
activity evolves overtime. The nos. of attributes varies by
application area
(2.1) During the initial stages of the project
(A) Activity Identifier (ID)
(B) WBS(ID)
(C) Activity Label or Name
(2.2) When Completed
(A) Activity Codes
(B) Activity Description
(C) Predecessor Activities
(D) Successor Activities
(E) Logical Relationships
(F) Leads & lags
(G) Resource Requirements
(H) Imposed Dates
(I) Constraints & Assumptions
(2.3) Used to Identify
(A) Person responsible
(B) Geographic Area
(C) Project Calendar
(D) Activity Type
• Level of Effort (LOE): An activity that does not
produce definitive end products and is measured
by the passage of time
• Discreet Effort: An activity that can be planned

of 61
and measured and that yields a specific output.
• Apportioned Effort: An activity where effort is
allotted proportionately across certain discrete
efforts and not divisible into discrete efforts
(3) Milestone List: A milestone is a significant point or
event in a project. Milestones are similar to regular
schedule activities, with the same structure and attributes,
but they have zero duration because milestones represent
a moment in time. Milestone list is a list identifying all
project milestones and indicates whether a milestone is
(3.1) Mandatory: those required by contract
(3.2) Optional: those based upon historical information
6.3 Sequence Activities
It is the process of identifying and documenting relationships among
the project activities
Benefits: It defines the logical sequence of work to obtain the
greatest efficiency given all project constraints.
Every activity and milestone except the first and last should be
connected to at least one predecessor with a finish-to-start or start-
to-start logical relationship and at least one successor with a finish-
to-start or finish-to-finish logical relationship. Logical relationship
should be designed to create a realistic project schedule. It may be
necessary to use lead or lag time between activities to support a
realistic and achievable project schedule.
(2) Activity List
(3) Activity Attributes
(4) Milestone List
(1) Precedence Diagraming Method: Is a
technique is used for constructing a
schedule model in which activities are
represented by nodes and are graphically
linked by one or more logical relationships
to show the sequence in which activities are
to be performed. Activity-On-Node (AON) is
one method of representing a precedence
diagram. This is the method used by most
project management software packages.
PDM included four types of dependencies or
logical relationships. A predecessor activity
is an activity that logically comes before a
dependent activity in a schedule. A
successor activity is a dependent activity
that logically comes after another activity in
a schedule.
(1.1) Finish-to-start: A successor activity
cannot start until a predecessor activity has
finished.
(1.2) Start-to-start
(1.3) Finish-to-Finish
(1.4) Start-to-Finish
(2) Dependency Determination
(2.1) Mandatory dependencies: Are those
that are legally or contractually required or
inherent in the nature of the work.
Mandatory dependencies often involve
physical limitations, such as on a
construction project, where it is impossible
to erect the super structure until after the
foundation has been built. Also sometimes
referred to as hard logic or hard
dependencies. Technical dependencies may
not be mandatory. The project team
determines which dependencies are
mandatory during the process of
sequencing the activities. Mandatory
dependencies should not be confused with
assigning schedule constraints in the
scheduling tool.
(2.2) Discretionary dependencies: Are
sometimes referred to as preferred logic,
preferential logic, or soft logic. Discretionary
dependencies are established based on
knowledge of best practices within a
particular application area or some unusual
aspect of the project where a specific
sequence is desired even though there may
(1) Project Schedule Network Diagrams: is a graphical
representation of the logical relationships, also referred to
as dependencies, among the project schedule activities. It
can include full project details, or have one or more
summary activities. A summary narrative can accompany
the diagram and describe the basic approach used to
sequence the activities. Any unusual activity sequences
within the network should be fully described within the
narrative.
(2.1) Activity Lists
(2.2) Activity Attributes
(2.3) Milestone List
(2.4) Risk Register
Operations: Ongoing endeavours that produce repetitive output, with resources assigned to do basically the same set of tasks according to
the standards institutionalized in a product life cycle.
Operational Management: Area of management concerned with on going production of goods and / or services. It is concerned with
managing processes that transforms inputs (eg materials, components, energy and labour) into outputs (eg products, goods, and / or
services). It involves ensuring that business operations continue efficiently by using the optimum resources needed and meeting customer
demands
Operational Stakeholders: (1) Plant Operators (2) Manufacturing line supervisors (3) Help desk staff (4) Production system support
analyst (5) Customer service representative (6) Sales persons (7) Maintenance workers (8) Call centre personnel (9) Retail workers (10) Line
Managers (11) Training Officers (12) Telephone sales personnel
Business Value: Entire value of the business; the total sum of all tangible and intangible elements
Tangible Elements: Monetary assets, fixtures, stock holder equity, and utility
Intangible Elements: Good will, brand recognition, public benefit, and trademarks

of 61
be other acceptable sequences.
Discretionary dependencies should be fully
documented since they can create arbitrary
total float values and can limit later
scheduling options. When fast tracking
techniques are employed, these
discretionary dependencies should be
reviewed and considered for modification or
removal. The project team determines
which dependencies are discretionary
during the process of sequencing the
activities.
(2.3) External dependencies: Involve a
relationship between project activities and
non-project activities. These dependencies
are usually outside the project team’s
control.
(2.4) Internal dependencies: Involve a
precedence relationship between project
activities and are generally inside the
project team’s control.
(2) Leads and Lags: A lead is the amount of
time whereby a successor activity can be
advanced with respect to a predecessor
activity. Lead is often represented as a
negative value for lag in scheduling
software. (Lead = -Lag)
A lag is the amount of time whereby a
successor activity will be delayed with
respect to a predecessor activity.
The use of lead or lag should not replace
schedule logic. Activities and their related
assumptions should be documented.
6.4 Estimate Activity Resources
Is the process of estimating type and quantities of material, human
resources, equipment , or supplies required to perform each activity.
Benefits: It identifies the type, quantity, and characteristics of
resources required to complete the activity which allows more
accurate cost and duration estimates.
The estimate activity resources process is closely coordinated with
estimate cost process
(2) Activity List
(4) Resource Calendars: Is a calendar that
identifies the working days and shifts on which
each specific resource (human resource,
equipment, and material) is available. It
specifies when and how long identified project
resources will be available during the project.
The information may be at the activity or
project level. This knowledge includes
consideration of attributes such as resource
experience and / or skill level, as well as various
geographical locations from which the resources
originate and when they may be available.
(5) Risk Register
(6) Activity Cost Estimates
(1) Expert Judgment
(2) Alternative Analysis
(3) Published Estimating Data
(4) Bottom-Up Estimating: Is a method of
estimating project duration or cost by
aggregating the estimates of the lower level
components of the WBS. Activities may or
may not have dependencies between them
that can affect the application and use of
resources. If there are dependencies, this
pattern of resource usage is reflected and
documented in the estimated requirements
of the activity.
(5) Project Management Software
(1) Activity Resource Requirements: Identify the types and
quantities of resources required for each activity in a work
package. These requirements then can be aggregated to
determine the estimated resources for each work package
and each work period.
(2) Resource Breakdown Structure: Is a hierarchical
representation of resources by category and type. The
resource breakdown structure is useful for organizing and
reporting project schedule data with resource utilization
information.
(2.1) Category : Labor, Material, Equipment, & Supplies
(2.1) Type : Skill level, Grade Level, Other information
(3.1) Activity List
(3.3) Resource Calendars
Process Group: Planning (1) Schedule Management Plan (1) Expert Judgment (1) Activity Duration Estimates: are quantitative
Responsibilities and Competencies of the Project Manager:
(1) Responsible to satisfy needs: task needs, team needs, and individual needs. Project Manager becomes the link between the strategy and
the team
(2) Competencies required:
(a) Knowledge: Project Management Knowledge
(b) Performance: What Project Manager is able to do or accomplish while applying project management knowledge
(c) Personal: How the project manager behaves when performing the project or related activity. Personal effectiveness encompasses
attitudes, core personality characteristics, and leadership which provides the ability to guide the project team while achieving project
activities and balancing project constraints.

of 61
6.5 Estimate Activity Durations
Is the process of estimating the number of work periods needed to
complete individual activities with estimated resources.
Benefits: It provides the amount of time each activity will take to
complete, which is a major input to schedule development process
Estimate activity duration uses information on activity scope of work,
required resource types, estimated resource quantities, and resource
calendars. The inputs to the estimates of activity duration originate
from the person or group on the project team who is most familiar
with the nature of work in the specific activity. The duration estimate
is progressively elaborated, and the process considers the quality
and availability of input data. Thus, the duration estimate can be
assumed to be progressively more accurate and of better quality.
The estimate activity durations process requires an estimation of
amount of work effort required to complete the activity and the
amount of available resources estimated to complete the activity.
These estimates are used to approximate the number of work
periods (activity duration) needed to complete the activity using the
appropriate project and resource calendars. All data and assumptions
that support duration estimating are documented for each estimate
of activity duration
(2) Activity List
(4) Activity Resource Requirements
(5) Resource Calendars
(7) Risk Register
(8) Resource Breakdown Register
(9) Enterprise Environmental Framework
(2) Analogous Estimating: Is a technique for
estimating the duration or cost of an activity
or a project using historical data from a
similar activity or project. When estimating
durations, this technique relies on the
actual duration of previous, similar projects
as the basis for estimating the duration of
the current project. It is a gross value
estimating approach sometimes adjusted
for known differences in project complexity.
It is frequently used when there is limited
amount of detailed information about the
project. It is less costly, less time
consuming than other techniques, but is
also less accurate. Can be applied to a total
project or to segment of a project and may
be used in conjunction with other
estimating methods. Analogous estimating
is most reliable when the previous activities
are similar in fact and not just in
appearance, and the project team members
preparing the estimates have the needed
expertise.
(3) Parametric Estimating: Is an estimating
technique in which an algorithm is used to
calculate cost or duration based on
historical data and project parameters.
Parametric estimating uses a statistical
relationship between historical data and
other variables (eg sq ft in construction) to
calculate an estimate for activity
parameters, such as cost, budget, and
duration. Activity durations can be
quantitatively determined by multiplying the
quantity of work to be performed by labor
hours per unit of work. The technique can
produce higher levels of accuracy
depending upon the sophistication and
underlying data built into the model.
Parametric time estimates can be applied to
a total project or to segments of a project
in conjunction with other estimating
methods.
(4) Three-Point Estimating: The accuracy of
single point activity duration estimates may
be improved by considering estimation
uncertainty and risk. This concept
originated from Program Evaluation and
review Technique (PERT). PERT uses three
estimates to define an approximate range
for an activity’s duration
Most likely (tM): This estimate is based on
the duration of the activity, given the
resources likely to be assigned, their
productivity, realistic expectations of
availability for the activity, dependencies on
other participants, and interruptions
Optimistic(tO): The activity duration based
on the best-case scenario for the activity
assessments of the likely number of time periods that are
required to complete an activity. Duration estimates do
not include any lags. Activity duration estimates may
include some indication of the range of possible results.
For eg 2 weeks +/- 2days, 15% probability of exceeding
three weeks, which indicates high probability 85% that
the activity will take three weeks of less.
(2.2) Assumptions, Skill level, & Availability, basis of
activity duration estimates
Program Management: harmonizes its projects and program components and controls interdependencies in order to realize specified
benefits. A program is defined as group of related projects, subprograms, and program activities, managed in a coordinated way to obtain
benefits not available from managing then individually. A project may or may not be part of a program but a program will always have
projects.
Program management is the application of knowledge, skills, tools and techniques to a program in order to meet the program requirements
and to obtain benefits and control not available by managing projects individually.
Projects within a program are related through the common outcome or collective capability. If the relationship between projects is only that
of a shared client, seller, technology or resource, the effort should be managed as a portfolio of projects rather than as a program.
Program management focuses on the project interdependencies & helps to determine optimal approach for managing them. Actions related
to these interdependencies may include
(1) Resolving resource constraints and / or conflicts that affect multiple projects within the program.
(2) Aligning organizational / strategic direction that affects projects and program goals and objectives
(3) Resolving issues and change management within a shared governance structure.

of 61
Pessimistic(tP): The activity duration based
on analysis of the worst-case scenario for
the activity
Duration estimates based on three points
with an assumed distribution provide an
expected duration and clarify the range of
uncertainty around the expected duration
Following formulae can be used
(4.1) Triangular Distribution : (tO+tM+tP)/3
(4.2) Beta Distribution : (tO+4tM+tP)/6
(4.3) Beta Dist. S.D : (P-O)/6
(4.4) Beta Dist. Variance : [(P-O)/6]^2
(5) Group Decision Making Techniques: Is
an assessment process having multiple
alternatives with an expected out-come in
the form of future actions. These
techniques are useful for engaging team
members to improve estimate accuracy and
commitment to the emerging estimates.
(6) Reserve Analysis
(6.1) Contingency Reserve: Duration
estimates may include contingency reserves
also referred as time reserves or buffers,
into the project schedule to account for
schedule uncertainty. Contingency reserves
are the estimated duration within the
schedule baseline which is allocated for
identified risks that are accepted and for
which contingent or mitigation responses
are developed. Contingency reserves are
associated with the “know-unknowns”,
which may be estimated to account for
unknown amount of rework. The
contingency reserve may be a percentage
of the estimated activity duration, a fixed no
of work periods, or may be developed by
using quantitative analysis methods such as
Mote Carlo Simulation. Contingency reserve
may be separated from individual activities
and aggregated into buffer. As more precise
information about the project becomes
available, the contingency reserve may be
used, reduced, or eliminated. Contingency
should be clearly identified in schedule
documentation.
(6.2) Management Reserve: Estimates may
also be produced for the amount of
management reserve of time for the
project. Management reserves are a
specified amount of the project duration
withheld for management control purpose
and are reserved for unforeseen work that
is within scope of the project. Management
reserves are intended to address the
“unknown-unknowns” that can affect a
project. Management reserve is not
included in the schedule baseline, but it is
part of the overall project duration
requirements. Depending on contract terms,
use of management reserve may require a
Matrix Organization:
(1) Blend of functional and projectized organization
(2) Can be classified as weak, balanced or strong
(3) Weak matrix organizations maintain many of the characteristics of a functional organization, and the role of the project manager is more
of a coordinator or expeditor
Project Coordinator: Power to make some decisions, have some authority , and report to higher level manager
Project Expediter: Cannot personally make or enforce decisions, works as staff assistant, and communications coordinator
(4) Strong matrix organizations have many of the characteristics of the projectized organizations, and have full time project managers with
considerable authority and full time project administrative staff
(5) Balanced matrix organizations recognizes the need for a project manager, it doesnot provide the project manager with the full authority
over the project and the project funding
Advantages: Disadvantages
(1) Highly visible project objectives (1) Extra administration is required
(2) Improved project manager control over resources (2) Project team members have more than one boss
(3) More support from functional area (3) More complex to monitor and control
(4) Maximum utilization of scarce resources (4) Resource allocation is more complex
(5) Better coordination (5) Extensive policies and procedures are needed
(6) Better horizontal and vertical dissemination of information (6) Functional managers may have different priorities than project
managers
(7) Team members maintain a home (7) Higher potential for conflict
Projectized Organization: Team members are often collocated. Most of the organizations resources are involved in project work, and
project managers have a great deal of independence and authority. They often have organizational units called departments, but they can
either report directly to the project manager or provide support services to the various projects
(1) Efficient project organization (1) No “Home” or team members when project is completed
(2) Team loyalty to project (2) Lack of specialization in disciplines
(3) More effective communication than functional organization (3) Duplication of facilities and job functions
(4) May result in less efficient use of resources

of 61
change to the schedule baseline.
6.6 Develop Schedule
It is the process of analyzing activity sequences, durations, resource
requirements, and schedule constraints to create the project
schedule model.
Benefits: By entering schedule activities, durations, resources,
resource availabilities, and logical relationships into the scheduling
tool, it generates a schedule model with planned dates for
completing project activities.
Developing an acceptable schedule is often an iterative process. The
schedule model is used to determine the planned start and finish
dates for project activities and milestones based on the accuracy of
the inputs. Schedule development can require the revision and
review of duration estimates and resources estimates to create the
project schedule model to establish an approved project schedule the
can serve as a baseline to track progress
Once the activity start and finish dates have been determined, it is
common to have project staff assigned to the activities review their
assigned activities and confirm that the start and finish dates present
no conflict with resource calendars or assigned activities in other
projects or taksk and thus are still valid. As work progresses, revising
and maintaining the project schedule model to sustain a realistic
schedule continues throughout the duration of the project
(1) Schedule Management Plan: identifies the
scheduling method, tool used to create the
schedule and how the schedule is to be
calculated
(2) Activity List
(4) Project Schedule Network Diagrams
(7) Activity Duration Estimates
(9) Risk Register
(10) Project Staff Assignments
(11) Resource Breakdown Structure
(1) Schedule Network Analysis: Is a
technique that generates the project
schedule model. It employs various
analytical techniques, such as critical path
method, critical chain method, what-if
analysis, and resource optimization
techniques to calculate the early and late
start and finish dates for the uncompleted
portion of project activities. Some network
paths may have points of path convergence
or path divergence that can be identified
and used in schedule compression analysis
or other analysis.
(2) Critical Path Method: Is a method used
to estimate the minimum project duration
and determine the amount of scheduling
flexibility on the logical network paths
within the schedule model. This schedule
network analysis technique calculates the
early start, early finish, late start, late finish
dates for all activities without regard for any
resource limitations by performing a
forward and backward pass analysis
through the schedule network.
The critical path is the sequence of activities
that represent the longest path through a
project, which determines the shortest
possible project duration.
The resulting early and late start and finish
dates are not necessarily the project
schedule, rather they indicate the time
periods within which the activity could be
executed.
Using the parameters entered in the
schedule model for activity durations, logical
relationships, leads, lags, and other known
constraints. The critical path method is used
to calculate the amount of a scheduling
flexibility on the logical network path within
the schedule model.
On any network path, the schedule
flexibility is measured by the amount of
time that a schedule activity can be delayed
or extended from its early start date without
delaying the project finish date or violating
a schedule constraint, and is termed “total
float”. A CPM critical path is normally
characterized by zero total float on the
critical path. As implemented with PDM
sequencing , critical path may have positive,
zero, or negative total float depending on
constraints applied. Any activity on the
critical path is called a critical path activity.
Schedule networks may have multiple near-
critical paths.
Once the total float for a network has been
calculated, then the “free-float” – the
amount of time that a schedule activity can
(1) Schedule Baseline: Is the approved version of a
schedule model that can be changed only through formal
change control procedures and is used as a basis for
comparison to actual results. It is accepted and approved
by the appropriate stakeholders as the schedule baseline
with baseline start dates and finish dates to determine
whether variations have occurred. The schedule baseline
is a component of the project management plan.
(2) Project Schedule: The project schedule is an output of
a schedule model that presents linked activities with
planned dates, durations, milestones, and resources. At a
minimum project schedule includes a planned start date
and planned finish date for each activity. If resource
planning is done at an early stage, then the project
schedule remains preliminary until resource assignments
have been confirmed and scheduled start and finish dates
are established. This process occurs no later than the
completion of the project management plan. A target
project schedule model may also be developed with a
defined target start and target finish for each activity. The
project schedule presentation may be presented in
summary form , sometimes referred to as master schedule
or milestone schedule or presented in detail. Schedule
presentation formats include
(2.1) Bar Charts
(2.2) Milestone Charts
(2.3) Project Schedule Network Diagrams
(A) Pure-logic diagrams: activities and relationships
without a timescale
(B) Logic-bar chart: activity date information and
project network logic and the projects critical path
(C) Time-scaled logic: Time scale and bars that
represent duration of activities with the logical
activities
(3) Schedule Data
(3.1) Schedule Milestones
(3.2) Schedule Activities
(3.4) Assumptions & Constraints
(3.5) Supporting Details
(A) Resource requirements by time period (Resource
Histogram)
(B) Alternative Schedules, best case or worst case,
not-resource levelled, resource levelled, with or
without imposed dates
(C) Scheduling of contingency reserves
(D) Cash-flow projections
(E) Order & Delivery Schedules
(4) Project Calendars
(6.1) Activity Resource Requirements
(6.3) Calendars
(6.4) Risk Registers
Functional Organization: Is a hierarchy where each employee has one clear supervisor. Staff members are grouped by speciality such as
production, marketing, engineering and accounting at the top level. Specialities may be further subdivided into focused functional units.
Such as mechanical and electrical engineering. Each department in a functional organization will do its project work independently of the
other.
(1) Easier management of specialities (1) People place more emphasis on their functional speciality to
the detriment of the project
(2) Team member reports to only one supervisor (2) No career path in project management
(3) Similar resources are centralized as the company is grouped by
speciality
(3) Project Manager has little or no authority
(4) Clear defined career paths in the area of work specialization (4) Little to none resource availability
(5) Functional Manager manages project budget
(6) Part time availability of project manager and project
management administrative staff
Composite Organization: A projectized organization within a functional organization. Includes full time staff from different functional
departments, may develop its own operating procedures, may even operate outside of the standard, formalized reporting structure during
the project. An organization may manage most of its project in a strong matrix, but allow small projects to be managed by functional
departments

of 61
be delayed without delaying the early start
date of any successor or violating a
schedule constrain can also be determined
(3) Critical Chain Method: It is developed
from the critical path method approach and
considers the effects of resource allocation,
resource optimization, resource levelling,
and activity duration uncertainty on the
critical path determined using the critical
path method. To do so, the critical path
method uses the concept of buffers and
buffer management. The critical chain
method uses activities with durations that
do not include safety margins, logical
relationships, and resource availability with
statistically determined buffers composed of
aggregated safety margins of activities at
specified points on the project schedule
path to account for limited resources and
project uncertainties. The resource
constrained critical path is known as “critical
chain”
The critical chain method adds duration
buffers that are non-work schedule
activities to manage uncertainty. One
buffer, placed at the end of the critical
chain is known as “project buffer” and
protects the target finish date from slippage
along the critical chain. Additional buffers,
known as “feeding buffers” are placed at
each point where a chain of dependent
activities that are not on the critical chain
feeds inot the critical chain. Feeding buffers
thus protect the critical chain from slippage
along the feeding chains. The size of each
buffer should account for uncertainty in the
duration of the chain of dependent activities
leading upto that buffer. Once the buffer
schedule activities are determined, the
planned activities are scheduled to their
latest possible planned start and finish
dates. Consequently, instead of managing
the total float of network paths, the critical
chain method focuses on managing the
remaining buffer durations against the
remaining durations of chain of activities.
(4) Resource Optimization Techniques
(4.1) Resource Levelling: A technique in
which start and finish dates are adjusted
based on resource constraints with the goal
of balancing demand for resources with the
available supply. Resource levelling can be
used when shared or critically required
resources are only available at certain
times, or in limited quantities, or over-
allocated, such as when a resource has
been assigned to two or more activities
during the same time period or to keep
resource usage at constant level. Resource
levelling can often cause the original critical
path to change, usually increase.
(4.2) Resource Smoothing: A technique that
adjusts the activities of a schedule model
Project Stakeholders: A stakeholder is an individual group or organization who may affect, be affected by, or perceive itself to be affected
by a decision, activity or outcome of a project. Stakeholders may be actively involved in the project or have interest that may be positively or
negatively affected by the performance or completion of the project. Different stakeholders may have competing expectations that might
create conflicts within the project. Stakeholders may also exert influence over the project, its deliverables, and the project team in order to
achieve a set of outcomes that satisfy strategic business objectives or other needs.
Stakeholders include all members of the project team as well as all interested entities that are internal or external to the organization. The
project team identifies internal and external, positive and negative, and performing and advising stakeholders in order to determine the
project requirements and the expectations of all parties involved. The project manager should manage the influence of these various
stakeholders in relation to the project requirements to ensure a successful outcome.
Stakeholders have varying levels of responsibility and authority when participating on a project. This level can change over the course of the
project life cycle. Their involvement may range from occasional contributions in surveys, and focus groups to full project sponsorship which
includes providing financial, political or other support. Some stakeholders may also detract from success of the project, either passively or
actively. These stakeholders require the project manager’s attention throughout the project’s life cycle, as well as planning to address any
issues they may raise.
Stakeholder identification is a continuous process throughout the entire project lifecycle. Identifying the stakeholders, understanding their
relative degree of influence on a project, and balancing their demands, needs, and expectations are critical to the success of the project.
Failure to do so can lead to delays, cost increases, unexpected issues and other negative consequences including project cancellation.
Just as stakeholders can positively or adversely impact a project’s objectives, a project can be perceived by the stakeholders as having
positive or negative results. Overlooking negative stakeholders interests can result in an increased likelihood of failures, delays, or other
negative consequences to the project. Eg of stakeholders are
(1) Sponsors (2) Customers and users (customers – acquires projects product; users – utilize project’s product) (3) Sellers (also called
vendors, suppliers, contractors) (4) Business partners (5) Organizational groups (6) Functional Managers (7) other stakeholders

of 61
such that the requirements for resources on
the project do not exceed certain
predefined resources limits. In resource
smoothing, as opposed to resource
levelling, the project’s critical path is not
changed and the completion date may not
be delayed. In others words, activities may
only be delayed within their free and total
float. Thus resource smoothing may not be
able to optimize all resources.
(5) Modeling Techniques
(5.1) What-if Scenario Analysis: This is an
analysis of the question “what if the
situation represented by scenario’ X’
happens?” The outcome of what-if scenario
analysis can be used to assess the feasibility
of the project schedule under adverse
conditions, and in preparing contingency
and response plans to overcome or mitigate
the impact of unexpected situations.
(5.2) Simulation: Simulation involves
calculating multiple project durations with
different sets of activity assumptions,
usually using probability distributions
constructed from three-point estimates to
account for uncertainty. The most common
simulation technique is Monte Carlo
analysis, in which a distribution of possible
activity durations is defined for each activity
and used to calculate a distribution of
possible outcomes for the total project.
(6) Leads and Lags
(7) Schedule Compression: techniques used
to shorten the schedule duration without
reducing the project scope, in order to meet
schedule constraints, imposed dates, or
other schedule objectives
(7.1) Crashing: A technique used to shorten
the schedule duration for the least
incremental cost by adding resources. Eg of
crashing include approving overtime,
bringing in additional resources, or paying
to expedite delivery to activities on the
critical path. Crashing works only for
activities on the critical path where
additional resources will shorten the
activity’s duration. Crashing does not always
produce a viable alternative and may result
in increased risk and /or cost.
(7.2) Fast Tracking: A technique in which
activities or phases normally done in
sequence are performed in parallel for at
least a portion of their duration. Fast
tracking may result in rework and increased
risk. Fast tracking only works if activities
can be overlapped to shorten the project
duration.
(8) Scheduling Tool
Process Group: Monitoring & Controlling (1) Project Management Plan
(1) Performance Reviews

of 61
6.7 Control Schedule
It is the process of monitoring the status of project activities to
update project progress and manage changes to the schedule
baseline to achieve the plan.
Benefits: It provides the means to recognize deviation from the
plan and take corrective and preventive actions and thus minimize
risk.
Control schedule as a component of PICC process is concerned with
(1) Determining the current status of the project schedule
(2) Influencing the factors that create schedule changes
(3) Determining if the project schedule has changed
(4) Managing the actual changes as they occure
If an agile approach is utilized control schedule is concerned with
(1) Determining the current status of the project schedule by
comparing the total amount of work delivered and accepted against
the estimates of work completed for the elapsed time
(2) Conducting retrospective reviews (Scheduled reviews to record
lessons learned) for correcting processes and improving, if required)
(3) Reprioritizing the remaining the work plan (balck log)
(4) Determining the rate at which the deliverables are produced,
validated, and accepted (velocity) in given time per iteration (agreed
work cycle duration, typically two weeks or one month)
(5) Determining that the project schedule has changed
(6) Managing the actual changes as they occur
(2) Project Schedule
(4) Project Calendars
(5) Schedule Data
(1.2) Critical Path Method
(1.3) Critical Chain Method
(1.4) Earned Value Management
(A) Schedule Variance (SV)
(B) Schedule Performance Index
(C) Total Float
(D) Early Finish Variances
(3) Resource Optimization Techniques
(4) Modelling Techniques
(5) Leads and Lags
(6) Schedule Compression
(7) Scheduling Tool
(2) Schedule Forecasts
(3) Change Requests
(4.2) Cost Baseline
(5.1) Schedule Data
(5.2) Project Schedule
(5.3) Risk Register
(6.2) Corrective action chosen & reasons
(6.3) Other types of lessons learned from project schedule
control
Cost
Management
involved in planning,
estimating, budgeting,
financing, funding,
managing, and
controlling costs so
that the project can be
completed within the
approved budget. The
ability to influence cost
is greatest at the early
stages of the project,
making early scope
definition critical.
Project cost
management should
consider the
stakeholder
requirements for
managing costs.
Different stakeholders
will measure project
costs in different ways
and at different times.
7.1 Plan Cost Management
The process establishes the policies, procedures, and documentation
for planning, managing, expending, and controlling project costs.
Benefits: It provides guidance and direction on how the project
costs will be managed throughout the project.
(1.3) Other information
(A) Cost related scheduling
(B) Risk
(C) Communications decisions
(2) Project Charter: provides the summary
budget from which the detailed project costs
are developed. The project charter also defines
the project approval requirements that will
influence the management of the project costs.
(1) Expert Judgment
(2) Analytical Techniques: Developing the
cost management plan may involve
choosing strategic options to fund the
project such as self-funding, funding with
equity, or funding with debt. The cost
management plan may also detail ways to
finance project resources such as making,
purchasing, renting, or leasing. These
decisions, like other financial decisions
affecting the project may affect project
schedule and / or risks.
Organizational policies and procedures may
influence which financial techniques are
employed in these decisions. Techniques
may include (but are not limited to)
payback period, return on investment,
internal rate of return, discounted cash
flow, and net present value.
(3) Meetings
(1) Cost Management Plan: Is a component of the project
management plan and describes how the project costs will
be planned, structured, and controlled. The cost
management processes and their associated tools and
techniques are documented in the cost management plan.
Cost management plan can establish the following
(1.1) Units of measure
(1.2) Level of precision
(1.3) Level of accuracy
(1.4) Organizational Procedure links: The work break
down structure (WBS) provides the framework for the
cost management plan, allowing for consistency with the
estimates, budgets, and control of costs. The WBS
component used for the project cost accounting is called
the control account. Each control account is assigned a
unique code or account numbers that links directly to the
performing organization accounting system.
(1.5) Control thresholds: Variance thresholds for
monitoring cost performance may be specified to indicate
and agreed upon amount of variation to be allowed before
some action needs to be taken. Thresholds are typically
expressed as percentage deviations from the baseline
plan.
(1.6) Rules of performance measurements: Earned Value
Management (EVM) rules for performance measurements
are set.
(A) Define the Points in WBS at which measurement
of Control Accounts will be performed

of 61
For eg, the cost of an
acquired item may be
measured when the
acquisition decision is
made or committed,
the order is placed, the
item is delivered, or
the actual cost is
incurred or recorded
for project accounting
purposes.
Project cost
management is
primarily concerned
with the cost of
resources needed to
complete project
activities. Project cost
management should,
also consider the
effect of project
decisions on the
subsequent recurring
cost of using,
maintaining, and
supporting the project,
services, or result of
the project.
In many organizations,
predicting and
analyzing the
prospective financial
performance of the
project’s product is
performed outside of
the project. In others
such as a capital
facilities project,
project cost
management can
include this work.
When such predictions
and analysis are
included, project cost
management may
address additional
processes and
numerous general
financial management
techniques such as
return on investment,
discounted cash flow,
and investment
payback analysis.
The cost management
planning efforts occurs
early in project
planning and sets the
framework for each of
the cost management
processes so that
performance of the
(B) Establish the Earned Value Measurement
Technique (Fixed Formula, Weighted Milestone,
%Complete, Physical Measurement) to be
employed
(C) Specify tracking methodologies & the EVM
computation equations for calculating project
estimate at completion (EAC) forecasts to provide
a validity check on the bottom up EAC
(1.7) Reporting formats: formats and frequency for
various cost reports
(1.8) Process descriptions
(1.9) Additional details
(A) Description of strategic funding choices
(B) Procedure to account for fluctuations in currency
exchange rates
(C) Procedure for project cost recording
(D)
7.2 Estimate Costs
The process of developing an approximation of the monetary
resources needed to complete project activities
Benefits: It determines the amount of cost required to complete
project work
Cost estimates are a prediction that is based on the information
known at a given point in time. Cost estimates include the
identification and consideration of costing alternatives to initiate and
compete the project. Cost trade-offs and risks should be considered,
such as make versus buy, buy versus lease, and the sharing of
resources in order to achieve optimal costs for the project.
Cost estimates are generally expressed in units of some currency (ie
dollars, euros etc), although in some instances other units of
measure, such as staff hours, or staff days, are used to facilitate
comparisons by eliminating the effects of currency fluctuations
Cost estimates should be revised and refined during the course of
the project to reflect additional detail as it becomes available and
assumptions are tested. The accuracy of a project estimate will
increase as the project progresses through the project life cycle. For
eg a project in the initiation phase may have a “rough order of
magnitude (ROM)” estimates in the range of -25% to +75%. Later in
the project, as more information is known, definitive estimates could
narrow the range of accuracy to -5% to +10%. In some
organizations there are guidelines for when such refinements can be
made and the degree of confidence or accuracy that is expected.
Costs are estimated for all resources that will be charged to the
project. This includes but is not limited to labor, material, equipment,
services, and facilities, as well as special categories such as an
inflation allowance, cost of financing, or contingency cost. A cost
estimate is a quantitative assessment of the likely costs of or
resources required to complete the activity. Can be presented at the
activity level or in summary form.
(1) Cost Management Plan
(2) Human Resource Management Plan:
provides project staffing attributes, personnel
rates, and related rewards/recognition, which
are necessary components for developing the
project cost estimates.
(3) Scope Baseline
(3.1) Project Scope Statement: It also states
whether the estimates will be limited to direct
project costs only or whether the estimates will
also include indirect costs. “Indirect Costs” are
those costs that cannot be directly traced to a
specific project and therefore will be
accumulated and allocated equitably over
multiple projects by some approved and
documented accounting procedure. One of the
most common constraints for many projects is a
limited project budget. Examples of other
constraints are required delivery dates, available
skilled resources, and organizational policies.
(3.2) Work breakdown Structure
(3.3) WBS dictionary
(3.4) Additional information that may be found
in the scope baseline incudes contractual and
legal implications such as health, safety,
performance, environmental, insurance,
intellectual property rights, licenses, and
permits.
(4) Project Schedule: Type, Quantity and
amount of time these resources are applied to
complete the work of the project are major
factors in determining the project cost. Estimate
activity resources involves determining the
availability of staff, the no of staff hours
required, and quantities of material and
equipment needed to perform schedule
activities. It is closely coordinated with cost
estimating. Activity duration estimates will affect
cost estimates on any project where the project
budget includes an allowance for the cost of
financing (including interest charges) and where
resources are applied per unit of time for the
duration of the activity. Activity duration
estimates can also affect the cost estimates that
have time sensitive costs included in them, such
(1) Expert Judgment
(2) Analogous Estimating
(3) Parametric Estimating
(4) Bottom-up Estimating
(5) Three-Point Estimating
(5.1) Triangular Distribution
cE =(cO+cM+cP)/3
(5.2) Beta Distribution
cE = (cO+4cM+cP)/6
(5.3) Beta Dist. S.D : (P-O)/6
(5.4) Beta Dist. Variance :[(P-O)/6]^2
(6) Reserve Analysis: Cost estimates may
include contingency reserves (contingency
allowances) to allow for cost uncertainty.
Contingency reserves are the budget within
the cost baseline that is allocated for
identified risks, which are accepted and for
which contingent or mitigating responses
are developed. Contingency reserves are
often viewed as the part of the budget
intended to address the “known-unknowns”
that can affect a project. For e.g. rework for
some project deliverables could be
anticipated, while the amount of this rework
is unknown. Contingency reserves may be
estimated to account for this unknown
amount of rework. Contingency reserves
can be provided for a specific activity, for
the whole project, or both. The contingency
reserve may be a % of the estimated cost,
a fixed number, or may be developed by
using quantitative analysis methods.
As more precise information about the
project becomes available, the contingency
reserve may be used, reduced, or
eliminated. Contingency should be clearly
identified in cost documentation.
Contingency reserves are part of the cost
baseline and the overall funding
requirements for the project.
Estimates may be produced for the amount
(1) Activity Cost Estimates: are the quantitative
assessments of the probable costs required to complete
project work. Cost estimates can be presented in
summary form or in detail.
(1.1) Direct Labor
(1.2) Materials
(1.3) Equipment
(1.4) Services
(1.5) Facilities
(1.6) Information Technology
(1.7) Cost of Financing + Interest Charges
(1.8) Inflation Allowance
(1.9) Exchange Rates
(1.10) Contingency Reserve
(1.11) Indirect costs if included can be at the activity level
or at higher level.
(2) Basis of Estimates: clear and complete understanding
of how the cost estimate was derived.
(2.1) Documentation of Basis of Estimates
(2.2) Documentation of All Assumptions made
(2.3) Documentation of any Known constraints
(2.3) Indication of the Range of possible estimates
(2.4) Indication of the Confidence level of the final
estimates
(3.1) Risk Register

of 61
processes will be
efficient and
coordinated.
as union labor with regularly expiring collective
bargaining agreements or materials with
seasonal cost variations.
(5) Risk Register: The risk register should be
reviewed to consider the risk response cost. As
a general rule, when the project experiences a
negative risk event the near term cost of the
project will usually increase, and there will
sometimes be a delay in the project schedule.
In a similar way, the project team should be
sensitive to potential opportunities that can
benefit the business either by directly reducing
activity cost or by accelerating the schedule.
(6.1) Market Conditions: These conditions
describe what products, services, and results
are available in the market from whom, and
under what terms and conditions. Regional
and/or global supply and demand conditions
greatly influence costs.
(6.2) Published commercial Information:
Resource cost rate information is often available
from commercial databases that track skills and
human resources costs and provide standard
costs for material and equipment. Published
seller price lists are another source of
information.
(7.1) Cost estimating policies
(7.2) Cost estimating templates
(7.3) Historical information
(7.4) Lessons learned
of management reserve to be funded for
the project. Management reserves are the
amount of management reserves to be
funded for the project. Management
reserves are an amount of the project
budget withheld for management control
purposes and are reserved for unforeseen
work that is within the scope of the project.
Management reserves are intended to
address the “unknown-unknowns” that can
affect a project. The management reserve is
not included in the cost baseline but is part
of the overall project budget and funding
requirements. When an amount of
management reserve is used to fund
unforeseen work, the amount of
management reserve used is added to the
cost baseline, thus requiring an approved
change to the cost baseline.
(6.1) Contingency Reserve (included in Cost
baseline)
(6.2) Management Reserve (excluded from
Cost baseline but part of project budget)
(7) Cost of Quality (COQ)
(7.1) Cost of Non-Conformance
(A) Internal Failure Costs
(B) External Failure Costs
(7.2) Cost of Conformance
(A) Appraisal Costs
(B) Prevention Costs
(9) Vendor Bid Analysis: analysis of what
the project should cost, based on the
responsive bids form qualified vendors.
When projects are awarded under
competitive processes, additional cost
estimating work may be required of the
project team to examine the price of
individual deliverables and to derive a cost
that supports the final project cost.
(10) Group-Decision Making Techniques
7.3 Determine Budget
Is the process of aggregating the estimated costs of individual
activities or work packages to establish an authorized cost baseline
Benefits: It determines the cost baseline against which project
performance can be monitored and controlled
A project budget includes all the funds authorized to execute the
project. The cost baseline is the approved version of the time-phased
project budget, but excludes management reserves.
(2) Scope Baseline
(2.1) Project Scope Statement: Formal
limitations by period for the expenditure of
project funds can be mandated by the
organization, by agreement, or by other entities
such as government agencies. These funding
constraints are reflected in project scope
statement.
(2.2) Work Breakdown Structure
(2.3) WBS Dictionary
(4) Basis of Estimates
(5) Project Schedule: This information can be
used to aggregate costs to the calendar periods
(1) Cost Aggregation: Cost estimates are
aggregated by work packages in accordance
with the WBS. The work package cost
estimates are then aggregated for the
higher component levels of the WBS (such
as control accounts) and ultimately for the
entire project.
(3) Expert Judgment
(4) Historical Relationships: Both the cost
and accuracy of analogous and parametric
models can vary widely. They are most
likely to be reliable when
(4.1) Historical information used to develop
the model is accurate
(1) Cost Baseline: is the approved version of the time-
phased project budget, excluding any management
reserves, which can only be changed through formal
change control procedures and is used as a basis for
comparison to actual results. It is developed as a
summation of the approved budgets for the different
schedule activities.
(1.1) Activity cost estimates for the various project
activities along with any contingency reserves for these
activities are aggregated into their associated work
packages costs.
Activity cost estimates + Activity Contingency reserve =
Work Package Cost Estimate
(1.2) The work package cost estimates along with any
contingency reserves estimated for the work packages are
aggregated into control accounts.
Work Package Cost Estimate + Contingency Reserve =
Control Accounts
(1.3) The summation of control accounts make up the

of 61
in which the costs are planned to be incurred.
(6) Resource Calendars: This information can be
used to indicate resource costs over the
duration of the project.
(7) Risk Register: The risk register should be
reviewed to consider how to aggregate the risk
response cost.
(8) Agreements: Applicable agreement
information and costs relating to products,
services or results that have been or will be
purchased are included when determining the
budget.
(9.1) Existing formal and informal cost
budgeting related policies and guidelines
(9.2) Cost budgeting tools
(9.3) Reporting methods
(4.2) Parameters used in the model are
readily quantifiable
(4.3) Models are scalable, such that they
work for large projects, small projects, and
phases of a project.
(5) Funding Limit Reconciliation: The
expenditure of funds should be reconciled
with any funding limits on the commitment
of funds for the project. A variance between
the funding limits and planned expenditure
will sometimes necessitate the rescheduling
of work to level out the rate of expenditure.
This is accomplished by placing imposed
date constraints for work into the project
schedule.
cost baseline. Since the cost estimates that make up the
cost baseline are directly tied to the schedule activities this
enables a time phase view of the cost baseline, which is
typically displayed in the form of an S-Curve.
Summation of Control accounts = Cost Baseline
(1.4) Management reserves are added to the cost baseline
to produce the project budget. As changes warranting the
use of management reserve arise, the change control
process is used to obtain approval move the applicable
management reserves funds into the cost baseline.
Cost Baseline + Management Reserve = Project Budget
(2) Project Funding Requirements: Total funding
requirements and periodic funding requirements (eg
quarterly, annually) are derived from the cost baseline.
The cos baseline will include projected expenditures plus
anticipated liabilities. Funding often occurs in incremental
amounts that are not continuous, and may not be evenly
distributed and may appear as steps in the s curve. The
total funds required are those included in the cost
baseline, plus management reserves, if any. Funding
requirements may include the source(s) of funding.
(3.1) Risk Register
(3.2) Activity Cost Estimates
7.4 Control Costs
Is the process of monitoring the status of the project to update the
project costs and managing changes to the cost baseline
Benefits: It provides the means to recognize variance from the plan
in order to take corrective action and minimize risk.
Updating the budget requires knowledge of the actual costs spent to
date. Any increase to the authorized budget can only be approved
through the PICC process. Monitoring the expenditure of the funds
without regard to the value of work being accomplished for such
expenditures has little value to the project, other than to allow the
project team to stay within the authorized funding. Much of the
effort of cost control involves analyzing the relationship between the
consumption of project funds to the physical work being
accomplished for such expenditures. The key to the effective cost
control is management of the approved cost baseline and the
changes to that baseline. Project cost control includes
(1) Influencing the factors that create changes to the authorized cost
baseline.
(2) Ensuring that all changes are acted on in a timely manner.
(3) Managing the actual changes when and as they occur.
(4) Ensuring that cost expenditure do not exceed the authorized
funding by period, by WBS component, by activity, and in total for
the project.
(5) Monitoring cost performance to isolate and understand variances
from the approved cost baseline.
(6) Monitoring work performance against funds expended
(1.1) Cost Baseline
(2) Project Funding Requirements
(1) Earned Value Management (EVM): EVM
is a methodology that combines scope,
schedule, and resource measurements to
assess project performance and progress. It
integrates the scope baseline with the cost
baseline, along with the schedule baseline,
to form the performance measurement
baseline, which helps the project
management team assess and measure
project performance and progress. It is a
project measurement technique that
requires the formation of an integrated
baseline against which performance can be
measured for the duration of the project.
The principles of EVM can be applied to all
projects in any industry. EVM develops and
monitors three key dimensions for each
work package and control account.
(1.1) Planned Value (PV): Is the authorized
budget assigned to scheduled work . It is
the authorized budget planned for the work
to be accomplished for an activity or WBS
component, not including management
reserve. The budget is allocated by phase
over the life of the project, but at a given
moment, planned value defines the physical
work that should have been accomplished.
The total of the PV is sometimes referred as
the performance measurement baseline
(PMB). The total planned value for the
project is also known Budget at Completion
(BAC)
(1.2) Earned Value: is the measure of work
performed expressed in terms of the budget
authorized for that work. It is the budget
associated with the authorized work that
has been completed. The EV being
(2) Cost Forecasts
(3) Change Requests
(4.1) Cost Baseline
(5.1) Activity Cost Estimates
(5.2) Basis of Estimates
(6.2) Corrective Action Chosen and the reasons
(6.3) Financial Databases
(6.4) Other Types of lessons learned from project cost
control

of 61
(8) Preventing unapproved changes from being included in the
reported cost or resource usage
(9) Informing appropriate stakeholders of all approved changes and
associated cost.
(10) Bringing acceptable cost overruns within acceptable limits.
measured needs to be related to the PMB,
and the EV measured cannot be greater
than the authorized PV budget for a
component. The EV is often used to
calculate the percent complete of a project.
Progress measurement criteria should be
established for each WBS component to
measure work in progress. Project
Managers monitor EV, both incrementally to
determine current status and cumulatively
to determine the long-term performance
trend.
(1.3) Actual Cost: is the realized cost
incurred for work performed on an activity
during a specific time period. It is the total
cost incurred in accomplishing the work that
the EV measured. The AC needs to
correspond in definition to what was
budgeted in PV and measured in the EV
(eg. Direct hours only, direct costs only, or
all costs including indirect costs). The AC
will have no upper limit; Whatever is spent
to achieve the EV will be measured.
(1.4) SV = EV-PV
(A) SV > 0 => Ahead of Schedule
(B) SV < 0 => Behind Schedule
(C) SV = 0 => Baseline schedule
(D) The EVM schedule variance will
ultimately equal zero when the
project is completed because of all
the planned value will have been
earned.
(1.5) SPI = EV/PV
(A) SPI > 1 => Ahead of Schedule
(B) SPI < 1 => Behind Schedule
(C) SPI = 0 => Baseline Schedule
(1.6) CV = EV-AC
(A) CV > 0 => Under Budget
(B) CV < 0 => Over Budget
(C) CV = 0 => Baseline
(D) The Cost variance at the end of the
project will be difference between
budget at completion (BAC) and the
actual amount spent.
(1.7) CPI = EV/AC
(A) CPI > 1 => Under Budget
(B) CPI < 1 => Over Budget
(C) CPI = 1 => Baseline
(2) Forecasting
(2.1) EAC forecast for ETC work performed
when initial plan is no longer valid
• EAC = AC + Bottom Up ETC
at budgeted rate
• EAC = AC + (BAC – EV)
at the present CPI
• EAC = BAC/CPI
(2.5) EAC forcast for ETC work considering
both CPI & SPI
• EAC = AC +[(BAC – EV)/(CPIxSPI)]
(2.6) ETC = EAC – AC => Assuming work is
proceeding on plan
Project Team: Includes the project manager and the group of individuals who act together in performing the work of the project to achieve
its objectives. The structure and characteristics of a project team can vary widely, but one constant is the project manager’s role as the leader
of the team, regardless of what authority the project manager may have over it members. Project teams include roles such as
Project Management Staff: The members of the team who perform project management activities such as scheduling, budgeting, reporting and
control, communications, risk management and administrative support. The role may be performed or supported by a project management
office (PMO)
Project Staff: The members of the team who carry out the work creating the project deliverables
Supporting experts: develop or execute the project management plan. This can include roles such as contracting, financial management,
logistics, legal, safety, engineering, test or quality control.
User or Customer Representatives: members of the organization who will accept the deliverables or products of the project may be assigned to
act as representatives of liaisons to ensure proper coordination, advise on requirements, or validate the acceptability of the project results
Sellers, Business Partners, Business Partner members
Composition of the project team: (1) Dedicated (2) Part time

of 61
(2.7) ETC = Re-estimate => Re-estimate
the remaining work from the bottom up
(3) To Complete Performance Index (TCPI):
is a measure of the cost performance that is
required to be achieved with remaining
resources in order to meet a specified
management goal (BAC or EAC), expressed
as a ratio of cost to finish the outstanding
work to the remaining budget
TCPI = Work Remaining / Funds Remaining
(3.1) Based on BAC
• (BAC - EV)/(BAC - AC)
• TCPI > 1 => Harder to Complete
• TCPI < 1 => Easier to Complete
• TCPI = 1 => Same to Complete
(3.2) Based on EAC
• (BAC – EV)/(EAC – AC)
• TCPI > 1 => Harder to Complete
• TCPI < 1 => Easier to Complete
• TCPI = 1 => Same to Complete
(4) Performance Reviews
(4.1) Variance Analysis: as used in the EVM
is the explanation (cause, impact, and
corrective actions) for cost (CV = EV-AC),
schedule (SV = EV-PV) and variance at
completion (VAC = BAC – EAC) variances.
An important aspect of project cost control
includes determining the cause and degree
of variance relative to the cost baseline and
deciding whether corrective or preventive
action is required. The percentage range of
acceptable variances will tend to decrease
as more work is accomplished.
(4.3) Earned Value Performance
Quality
Management
Project quality
management uses
policies and
procedures to
implement, with in the
project’s context, the
organization’s quality
management system
and, as appropriate, it
supports continuous
process improvement
activities as
undertaken on behalf
of the performing
organization. Project
quality management
works to ensure that
the project
requirements,
including product
8.1 Plan Quality Management
It is the process of identifying quality requirements and/or standards
for the project and its deliverables, and documenting how the project
will demonstrate compliance with relevant quality requirements
and/or standards.
Benefits: It provides guidance and direction on how quality will be
managed and validated throughout the project
(1.1) Scope baseline
(A) Project scope statement
(B) WBS
(C) WBS dictionary
(1.2) Schedule baseline
(1.3) Cost baseline
(1.4) Other Management Plans
(3) Risk Register
(1) Cost-Benefit Analysis
(2) Cost of Quality
(2.1) Cost of Non-Conformance: Money
spent during and after the project because
of failures
(A) Internal Failure Costs (Failures
found by the project)
• Rework, Scrap
(B) External Failure Costs (failures
found by the customer)
• Liabilities, Warranty work, Lost
business
(C) Failure costs are also called cost of
poor quality
(2.2) Cost of Conformance: Money spent
during the project to avoid failures
(A) Prevention Costs (Build a quality
product)
• Training, Document processes,
Equipment, Time to do it right
(B) Appraisal Costs (Assess the quality)
• Testing, Destructive testing loss,
(1) Quality Management Plan: is a component of the
project management plan that describes how the
organization’s quality policies will be implemented. It
describes how the project management team plans to
meet the quality requirements set for the project.
The quality management plan may be formal or informal,
detailed or broadly framed. The style and detail of the
quality management plan are determined by the
requirements of the project. The quality management plan
should be reviewed early in the project to ensure that
decisions are based on accurate information. The benefits
of this review can include a sharper focus on the project’s
value proposition and reductions in costs and the
frequency of schedule overruns that are caused by
rework.
(2) Process improvement Plan: a subsidiary or a
component of project management plan. The process
improvement plan details the steps for analyzing project
management and product development processes to
identify activities that enhance their value. Areas to
consider include

of 61
requirements, are met
and validated
Project Quality
Management
addresses the
management of the
project and the
deliverables of the
project. It applies to all
projects, regardless of
the nature of the
deliverables. Quality
measures and
techniques are specific
to the type of
deliverables being
produced by the
project. Failure to
meet the quality
requirements can have
serious, negative
consequences for any
or all the project
stakeholders. For e.g.
Meeting customer
requirements by
overworking the
project team may
result in decreased
profits and increased
project risks, employee
attrition, errors and
rework.
Meeting project
schedule objectives by
rushing planned
quality inspections
may result in
undetected errors,
decreased profits, and
increased post-
implementation risks.
Project quality
management uses
policies and
procedures to
implement, within the
project’s context, the
organization’s quality
management system
and, as appropriate, it
supports continuous
process improvement
activities as
undertaken on behalf
of the performing
organization.
Quality: as a delivered
performance or result
is “the degree to which
Inspections
(3) Seven Basic Quality Tools
(3.1) Cause-and-Effect Diagram (Fish Bone
/ Ishikawa Diagrams): The problem
statement placed at the head of the
fishbone is used as a starting point to trace
the problem’s source back to its actionable
root cause. The problem statement typically
describes the problem as a gap to be closed
or as an objective to be achieved. The
causes are found by looking at the problem
statement and asking “Why” until the
actionable root cause has been identified or
until the reasonable possibilities have been
exhausted. Fishbone diagrams often prove
useful in linking the undesirable effects seen
as special variation to the assignable cause
upon which project teams should implement
corrective actions to eliminate the special
variation detected in a control chart
(3.2) Flowcharts (Process Maps): they
display the sequence of steps and the
branching possibilities that exist for a
process that transforms one or more inputs
into one or more outputs. Flow charts show
the activities, decision points, branching
loops, parallel paths, and the overall order
of processing by mapping the operational
details of procedures that exists within a
horizontal value chian of a Supplier Input
Output, Customer (SPIOC) model. Flow
charts may prove useful in understanding
and estimating the cost of quality in a
process. This is obtained by using the
workflow branching logic and associated
relative frequencies to estimate expected
monetary value for the conformance and
non-conformance work required to deliver
the expected conforming output
(3.3) Check Sheets (Tally Sheets): may be
used as a checklist when gathering data.
Check sheets are used to organize facts in a
manner that fill facilitate the effective
collection of useful data about a potential
quality problem. They are especially useful
for gathering attributes data while
performing inspections to identify defects.
Foe eg data about the frequencies or
consequences of defects collected in check
sheets are often displayed using pareto
diagrams
(3.4) Pareto diagrams: exists as a special
forms of vertical bar chart and are used to
identify the vital few sources that are
responsible for causing most of a problem’s
effects. The categories shown on the
horizontal axis exist as a valid probability
distribution that accounts for 100% of the
possible observations. The relative
frequencies of each specified cause listed
on the horizontal axis decrease in
magnitude until the default source named
“other” accounts for any non-specified
causes. Typically, the Pareto diagram will be
(2.1) Process Boundaries: Describe the purpose of the
process, the start and end of the process, its inputs and
outputs, the process owner, and the stakeholder of the
process
(2.2) Process Configuration: Provides a graphic depiction
of processes, with interfaces identified, used to facilitate
anaysis
(2.3) Process metrics: Along with control limits, allows
analysis of process efficiency.
(2.4) Targets for improved performance
(3) Quality Metrics: A quality metric specifically describes a
project or product attribute and how the control quality
process will measure it. A measurement is an actual value.
The tolerance defines the allowable variations to the
metric. Quality metrics are used in the perform quality
assurance and control quality processes. Some examples
of quality metrics include on-time performance, Cost
control, defect frequency, failure rate, availability,
reliability, and test coverage
(4) Quality Checklists: A checklist is a structured tool,
usually component – specific, used to verify that a set of
required steps has been performed. Based on the project’s
requirements and practices, checklists may be simple or
complex. Many organizations have standardized checklist
available to ensure consistency in frequently performed
tasks. In some application areas, checklists are also
available from professional associations or commercial
service providers. Quality checklists should incorporate the
acceptance criteria included in the scope baseline
(5.1) Stakeholder Register
(5.2) Responsibility Assignment Matrix
(5.3) WBS
(5.4) WBS Dictionary
Project Governance: The alignment of the project with stakeholders’ needs or objectives. Is critical to successful
management of stakeholder engagement and the achievement of organizational objectives. Project governance
enables organizations to consistently manage projects and maximize the value of project outcomes and align the
projects with business strategy. It provides a frame work in which the project manager and sponsors can make
decisions that satisfy both the stakeholders needs and expectations and organizational strategic objectives or address
circumstances that where these may not be in alignment. It is an oversight function that is aligned with the
organization’s governance model and that encompasses the project life cycle. Project governance framework provides
the project manager and the team with structure, processes decision-making models and tools for managing the
project, while supporting and controlling the project successful delivery. It provides a comprehensive, consistent
method of controlling the project and ensuring its success by defining and documenting and communicating reliable,
repeatable project practices. It includes a framework for making project decisions, defining roles, responsibilities and
accountabilities for the success of the project; and determines the effectiveness of the project manager. A project
governance is defined by and fits within the larger context of the portfolio, program, or organization sponsoring it but
is separate from organization governance. Eg of elements of project governance framework include
(1) Project success and deliverable acceptance criteria
(2) Process to identify, escalate, and resolve issues that arise during the project
(3) Relationship among the project team, organizational groups, and external stakeholders
(4) Project identification chart that identifies project roles
(5) Processes and procedures for the communication of information.
(6) Project decision making process
(7) Guidelines for aligning project governance and organizational strategy
(8) Project lifecycle approach
(9) Process for stage gate or phase reviews
(10) Process for review and approval for changes to budget, scope, quality, and schedule which are beyond the
authority of the project manager.
(11) Process to align internal stakeholders with project process requirements

of 61
a set of inherent
characteristics fulfill
requirements.”
Grade: as a design
intent is a category
assigned to
deliverables having the
same functional use
but different technical
characteristics.
The project manager
and the project
management team are
responsible for
managing the
tradeoffs associated
with delivering the
required levels of both
quality and grade.
Quality level that fails
to meet quality is
always a problem; a
low grade to quality
may not be a problem.
Precision: is a measure
of exactness
Accuracy: is an
assessment of
correctness
Precise measurements
are not necessarily
accurate
measurements, and
accurate
measurements are not
necessarily precise
measurements.
Every project should
have a quality
management plan.
Project teams should
follow the quality
management plan and
should have data to
demonstrate
compliance with the
plan.
Modern quality
management
approaches seek to
minimize variation and
to deliver results that
meet defined
requirements. These
approaches recognize
the importance of
organized into categories that measure
either frequencies or consequences.
(3.5) Histograms: are a special form of bar
chart and are used to describe the central
tendency, dispersion, and shape of a
statistical distribution. Unlike the control
chart, the histogram does not consider the
influence of time on the variation that exists
within a distribution.
(3.6) Control Charts: are used to determine
whether or not a process is stable or has
predictable performance. Upper and lower
specification limits are based on
requirements of the agreement. They
reflect the maximum and minimum values
allowed. There may be penalties associated
with exceeding the specification limits.
Upper and lower control limits are different
from specification limits. The control limits
are determined using standard statistical
calculations and principles to ultimately
establish the natural capability for a stable
process. The project manager and
appropriate stakeholders may use the
statistically calculated control limits to
identify the points at which corrective action
will be taken to prevent unnatural
performance. The corrective action typically
seeks to maintain the natural stability of a
stable and capable process. For repetitive
process, the control limits are generally set
at +/- 3s around a process mean that has
been set at 0s. A process is considered out
of control when (1) a data point exceeds a
control limit; (2) seven consecutive plot
points are above the mean; (3) seven
consecutive plot points are below the mean.
Control charts can be used to monitor
various types of output variables. Although
used most frequently to track repetitive
activities required for producing
manufactured lots, control charts may also
be used to monitor cost and schedule
variances, volume, and frequency of scope
changes, or other management results to
help determine if the project management
processes are in control
(3.7) Scatter Diagrams (Correlation Charts):
they seek to explain a change in the
dependent variable, Y, in relation to a
change observed in the corresponding
independent variable, X. The direction of
correlation may be proportional (Positive
Correlation), inverse (negative correlation),
or a pattern of correlation may not exist
(zero correlation). If correlation can be
established, a regression line can be
calculated and used to estimate how a
change to the independent variable will
influence value of dependent variable.
(4) Benchmarking: Comparing actual or
planned project practices to those of
comparable projects to identify best
practices, generate ideas for improvement,
Project Life Cycle: Project life cycle is the series of phases that a project passes through from its initiation to its
closure. A life cycle can be documented within a methodology. The life cycle provides the basic framework for
managing the project, regardless of the specific work involved.
Characteristics of Project Life Cycle: Generic life cycle structure
(1) Starting the project
(2) Organizing and preparing
(3) Carrying out the project work
(4) Closing the project
Life cycle should not be confused with project management process groups, because the processes in a process
group consists of activities that may be performed and recur within each phase of a project as well as the project as a
whole.

of 61
(1) Customer
Satisfaction:
Understanding,
evaluating, defining,
and managing
requirements so that
customer expectations
are met. This requires
a combination of
conformance to
requirements (to
ensure the project
produces what it was
created to produce)
and fitness for use
(the product or service
needs to satisfy the
real needs)
(2) Prevention over
inspection: Quality
should be planned,
designed, and built
into – not inspected
into the project’s
management or the
project deliverables.
The cost of preventing
mistakes is generally
much less than the
cost of correcting
mistakes when they
are found by
inspection or usage
(3) Continuous
Improvement: The
PDCA (plan-do-check-
act) cycle is the basis
for quality
improvement as
defined by Schewhart
and modified by
Deming. In addition,
quality improvement
initiatives such as
Total Quality
Management (TQM),
six sigma, lean sigma
could improve the
quality of the project’s
product. Commonly
used process
improvement models
include Malcolm
Baldrige,
Organizational Project
Management Maturity
Model (OPM3), and
Capability Maturity
Model Integration
(CMMI)
(4) Management
Responsibility: Success
and provide a basis for measuring
performance. Benchmarked projects may
exist within the performing organization or
outside of it, or can be with in the same
application area. Benchmarking allows for
analogies from projects in a different
application area to be made.
(5) Design of Experiments (DOE): is a
statistical method for identifying which
factors may influence specific variables of a
product or process under development or in
production. DOE may be used during the
plan quality management process to
determine the number and type of test and
their impact on cost of quality. DOE also
plays a role in optimizing products or
processes. DOE is used to reduce the
sensitivity of product performance to
sources of variations caused by
environmental or manufacturing
differences. One important aspect of the
technique is that it provides a statistical
framework for systematically changing all of
the important factors, rather than changing
the factors one at a time. Analysis of the
experimental data should provide the
optimal conditions for the product or
process highlight the factors that influence
the results, and reveal the presence of
interactions and synergy among the factors.
For eg automotive designers use this
technique to determine which combination
of suspension and tires will produce the
most desirable ride characteristics at a
reasonable cost.
(6) Statistical Sampling: involves choosing
part of a population of interest for
inspection. Sample frequency and sizes
should be determined during the plan
quality management process so that the
cost of quality will include the number of
tests, expected scrap, etc.
(7) Additional Quality Planning Tools
(7.1) Brainstorming
(7.2) Force Field Analysis: Diagram of forces
for and against the change
(7.3) Nominal Group Techniques: is used to
allow ideas to be brainstormed in small
groups and then reviewed by a larger group
(7.4) Quality Management and Control
Tools
(8) Meetings
Process Group: Execution
8.2 Perform Quality Assurance
It is the process of auditing the quality requirements and the results
from quality control measurements to ensure that appropriate quality
standards and operational definitions are used.
(1) Quality Management Plan
(2) Process Improvement Plan
(3) Quality Metrics
(4) Quality Control Measurements: are the
results of control quality activities. They are
(1) Quality Measurement and Control Tools:
The perform quality assurance process uses
the tools and techniques of the plan quality
management and control quality processes.
In addition, other tools that available
include
(1.1) Affinity Diagrams: The affinity diagram
is similar to mind-mapping techniques in
(1) Change Requests

of 61
requires participation
of all members of the
project team.
Nevertheless,
management retains,
within its responsibility
for quality, a related
responsibility to
provide suitable
resources at adequate
capacities.
(5) Cost of Quality:
Refers to total cost of
the conformance work
and the non-
conformance work that
should be done as a
compensatory effort
because, on the first
attempt to perform
that work, the
potential exists that
some portion of the
required work effort
may be done or has
been done incorrectly.
The costs for quality
work may be incurred
throughout the
deliverable’s life cycle.
Benefits: It facilitates the improvement of quality process
The quality assurance process implements a set of planned and
systematic acts and processes defined within the project’s quality
management plan. Quality assurance seeks to build confidence that a
future output or an unfinished output, also known as work in
progress, will be completed in a manner that meets the specified
requirements and expectations. Quality assurance contributes to the
state of being certain about quality by preventing defects through
the planning processes or by inspecting out defects during the work-
in-progress stage of implementation. Perform quality assurance is an
execution process that uses data created during plan quality
management and control quality processes
In project management, the prevention and inspection aspects of
quality assurance should have a demonstrable influence on the
project. A quality assurance work will fall under the conformance
work category in the cost of quality framework
Perform quality assurance also provides an umbrella for continuous
process improvement, which is an iterative means for improving the
quality of all processes. Continuous process improvement reduces
waste and eliminates activities that do not add value. This allows
processes to operate At increased level of efficiency and
effectiveness.
used to analyze and evaluate the quality of the
processes of the project against the standards
of the performing organization or the
requirements specified. Quality control
measurements can also compare the processes
used to create the measurements, and validate
actual measurements to determine their level of
correctness.
(5) Project Documents
that they are used to generate ideas that
can be linked to form organized patterns of
thought about a problem. In project
management, the creation of the WBS may
be enhanced by using the affinity diagram
to give structure to the decomposition of
scope.
(1.2) Process Decision Program Charts
(PDPC): Used to understand a goal in
relation to the steps for getting to the goal.
The PDPC is useful as a method for
contingency planning because it aids teams
in anticipating intermediate steps that could
derail achievement of the goal.
(1.3) Interrelationship Digraphs: An
adaptation of relationship diagrams. The
interrelationship digraphs provide a process
for creative problem solving in moderately
complex scenarios that possess intertwined
logical relationships for up to 50 relevant
items. The interrelationship digraph may be
developed from data generated in other
tools such as the affinity diagram, the tree
diagram, or the fish bone diagram.
(1.4) Tree Diagrams: Also known as
systematic diagrams and may be used to
represent decomposition hierarchies such as
the WBS, RBS (Risk Breakdown Structure),
and OBS (Organizational Breakdown
Structure). In project management, tree
diagrams are useful in visualizing the
parent-to-child relationships in any
decomposition hierarchy that uses a
systematic set of rules that define a nesting
relationship. Tree diagrams can be depicted
horizontally (such as risk breakdown
structure) or vertically (such as team
hierarchy or OBS). Because tree diagrams
permit the creation of nested branches that
terminate into a single decision point, they
are useful as decision trees for establishing
an expected value for a limited no. of
dependent relationships that have been
diagramed systematically.
(1.5) Prioritization Matrices: Identify the key
issues and the suitable alternatives to be
prioritized as a set of decisions for
implementation. Criteria are prioritized and
weighted before being applied to all
available alternatives to obtain a
mathematical score that ranks the options
(1.6) Activity Network Diagrams: Previously
known as arrow diagrams. They include
both the AOA (Activity on Arrow) and, most
commonly used, AON (Activity on Node)
formats of a network diagram. Activity
network diagrams are used with project
scheduling methodologies such as program
evaluation and review technique (PERT),
critical path method (CPM), and precedence
diagraming method (PDM)
(1.7) Matrix Diagrams: A quality
management and control tool used to
perform data analysis within the
organizational structure created in the
(3.1) Quality Audit Reports
(3.2) Training Plans
(3.3) Process Documentation
Project Phases: A project may be divided into a no of phases. A project phase is a collection of logically related project activities that
culminates in the completion of one or more deliverables. Project phases are used when the nature of the work to be performed is unique to
a portion of the project, and are typically linked to the development of a specific major deliverable. The high level nature of project phases
makes them an element of the project life cycle. The phase structure allows the project to be segmented into logical subsets for ease of
management, planning, and control. The number of phases, the need for phases, and the degree of control applied depend on the size,
complexity and potential impact of the project.
Characteristics of Project Phases:
(1) The work has a distinct focus that differs from any other phase. This often involves different organizations, locations and skill set
(2) Achieving the primary deliverable or objective of the phase requires controls or processes unique to the phase or its activities
(3) The closure of a phase ends with some form of transfer or hand-off of the work product produced as the phase deliverable. This phase
end represents a natural point to reassess the activities underway and to change or terminate the project if necessary. This point may be
referred to as stage gate, milestone, phase review, phase gate or kill point. In many cases, the closure of a phase is required to be approved
in some form before it can be considered closed.

of 61
matrix. The matrix diagram seeks to show
the strength of relationships between
factors, causes, and objectives that exist
between the rows and columns that form
the matrix
(2) Quality Audits: A quality audit is a
structured, independent process to
determine if project activities comply with
organizational and project policies,
processes, and procedures. The objectives
of quality audit many include
(2.1) Identify all good and best practices
being implemented
(2.2) Identify all nonconformity, gaps, and
short comings
(2.3) Share good practices introduced or
implemented in similar projects in the
organization and / or industry
(2.4) Proactively offer assistance in a
positive manner to improve implementation
of processes to help the team raise
productivity.
(2.5) Highlight contribution of each audit in
the lessons learned repository of the
organization.
The subsequent effort to correct any
deficiencies should result in a reduced cost
of quality and in increase in sponsor or
customer acceptance of the project’s
product. Quality audits may eb scheduled or
random, and may be conducted by internal
or external auditors.
Quality audits can confirm the
implementation of approved change
requests including updates, corrective
actions, defect repairs, and preventive
actions.
(3) Process Analysis: follows the steps
identified in the process improvement plan
to identify needed improvements. This
analysis also examines problems
experienced, constraints experienced, and
non-value-added activities identified during
process operation. Process analysis includes
root cause analysis - a specific technique
used to identify a problem, discover the
underlying causes that lead to it, and
develop preventive action.
8.3 Control Quality
Is the process of monitoring and recording results of executing the
quality activities to assess performance and recommend necessary y
changes
Benefits: (1) identifying the causes of poor process or product
quality and recommending and/or taking action to eliminate them
(2) Validating that project deliverables and work meet the
requirements specified by key stake holders necessary for final
acceptance
(2) Quality Metrics: A quality metric describes a
project or product attribute and how it will be
measured. E.g.
(2.1) Function Points
(2.2) Mean Time Between Failure (MTBF)
(2.3) Mean Time to Repair (MTTR)
(3) Quality Checklists
(1) Seven Basic Quality Tools
(2) Statistical Sampling
(3) Inspection: An inspection is the
examination of work product to determine if
it confirms to documented standards. The
result of an inspection generally include
measurements and may be conducted at
any level. For e.g. the result of a single
activity can be inspected, or the final
product of the project can be inspected.
Inspection may be called reviews, peer
(1) Quality Control Measurements: are the documented
results of the control quality activities. They should be
captured in the format that was specified through the Plan
Quality Management process.
(2) Validated Changes
(3) Verified Deliverables: A goal of the control quality
process is to determine the correctness of deliverables.
The results of performing the control quality process are
verified deliverables. Verified deliverables are an input to
Validate scope for formalized acceptance.

of 61
The control quality process uses a set of operational techniques and
tasks to verify that the delivered output will meet the requirements
Quality Assurance should be used during the project’s planning and
executing phases to provide confidence that the stakeholder’s
requirements will be met.
Quality Control should be used during the project executing and
closing phases to formally demonstrate, with reliable data, that the
sponsor and/or customer’s acceptance criteria have been met.
Prevention: keeping errors out of the process
Inspection: Keeping errors out of the hands of the customer
Attribute Sampling: the result either conforms or does not confirm
Variable Sampling: the result is rated on a continuous scale that
measures the degree of conformity.
Tolerances: specified range of acceptable results
Control limits: that identifies the boundaries of common variation in a
statistically stable process or process performance.
(6) Deliverables
(7.1) Agreements
(7.2) Quality Audit Reports & change Logs
supported with CA plans
(7.3) Training plans & Assessment of
effectiveness
(7.4) Process documentation using either the 7
basic QC tools or Quality Management or
Control tools
reviews, audits, or walk through. In some
application areas, these terms have narrow
and specific meanings. Inspections are also
used to validate defect repair.
(4) Approved Change Requests Review
(4) Work Performance Information: is the performance
data collected from various controlling processes, analyzed
in context and integrated based on relationships across
areas. E.g. include information about the project
requirements fulfillment such as causes for rejections,
rework required, or the need for process adjustments.
(5) Change Requests
(7.1) Quality Standards
(7.2) Agreements
(7.3) Quality Audit reports & Change logs supported with
corrective action plans
(7.4) Training plans & assessments of effectiveness
(7.5) Process docs such as information obtained using 7
basic Quality tools or the quality management and control
tools
(8.1) Completed Checklists
(8.2) Lessons learned documentation
Human Resource
Management
that organize, manage,
and lead the project
team. The project
team is comprised of
the people with
assigned roles and
responsibilities for
completing the project.
Project team members
may have varied skill
sets, may be assigned
full or par-time, and
may be added or
removed from the
team as project
progresses. Project
team members may
also be referred to as
the project’s staff.
Although specific roles
& responsibilities for
the project team
members are
assigned, the
involvement of all
team members in
project planning and
decision making is
beneficial. Participation
of team members
during planning adds
their expertise to the
process and strengths
their commitment to
9.1 Plan Human Resource Management
Is the process of Identifying and documenting project roles,
responsibilities required skills, reporting relationships, and creating a
staff management plan.
Benefits: It establishes project roles and responsibilities, project
organization charts, and the staffing management plan including the
timetable for staff acquisition and release.
Human resource planning is used to determine and identify human
resources with necessary skills required for project success. The
human resource management plan describes how the roles and
responsibilities, reporting relationships, and staffing management will
be addressed and structured within a project. It also contains the
staffing management plan including time tables for staff acquisition
and release, identification of training needs, team building strategies,
plan for recognition and reward programs, compliance
considerations, safety issues and the impact of the staffing
management plan on the organization.
Team Building; Team building is the process of helping a group of
individuals, bound by a common purpose, to work with each other,
the leader, external stakeholders, and the organization. The result of
good leadership and good team building is team work.
Team building activities consists of tasks (establish goals, define and
negotiate roles, responsibilities and procedures) and processes
(interpersonal behavior with emphasis on communication, conflict
management, motivation, and leadership). Developing a team
environment involves handling project team problems and discussing
these as team issues without placing blame on individuals. Team
building can be further enhanced by obtaining top management
support; encouraging team member commitment; introducing
appropriate rewards, recognition, and ethics; creating a team
identity; managing conflicts effectively; promoting trust and open
(1.1) The project life cycle and the processes
that will be applied to each phase
(1.2) How work will be executed to accomplish
the project objectives
(1.3) A change management plan that
documents how changes will be monitored and
controlled
(1.4) A configuration management plan that
documents how configuration management will
be performed.
(1.5) How integrity of project baseline will be
maintained
(1.6) Needs and methods of communication
among stake holders
(3.1) Existing Human Resources
(4.1) Organizational standard processes,
policies, and role descriptions
(4.2) Templates for organizational charts and
positions descriptions
(4.3) Lessons learned on organizational
structures that have worked in previous projects
(4.4) Escalation procedures for handling issues
within the team and within the performing
organization.
(1) Organization Charts and Position
Description: Regardless of the method
utilized, the objective is to ensure that each
work package has an unambiguous owner
and that all team members have a clear
understanding of the roles and
responsibilities.
(1.1) Hierarchical-type charts
(A) Organizational Breakdown Structure
(OBS): The traditional organization
chart structure can be used to show
positions and relationships in a
graphical top-down format. The
OBS is arranged according to
existing depts. with project
activities or work packages listed
under each dept., units or teams
(B) Resource Breakdown Structure
(RBS): Is a hierarchical list of
resources related by category and
resource type that facilitates
planning and controlling of project
work, helpful in tracking project
costs and can be aligned with org’s
accounting system can contain
resources other than human
resources.
(1.2) Matrix-based charts
(A) Responsibility Assignment Matrix
(RAM): Is a Grid that shows project
resources assigned to each work
package, it illustrates the
connection b/w work packages or
activities and project team
members. The matrix format shows
all activities associated with one
person and all people associated
with one activity. Eg RACI Chart
(1) Human Resource Management Plan
(1.1) Roles and Responsibilities
(A) Role: The function assumed by or assigned to a
person in the project. E.g. testing coordinator,
civil engineer, business analyst
(B) Authority: The right to apply project resources,
make decisions, sign approvals, accept
deliverables, and influence others to carry out the
work of the project. E.g. of decisions that need a
clear authority include selection of a method for
completing an activity, quality acceptance, and
how to respond to project variances. Team
members operate best when their individual levels
of authority match their individual responsibilities
(C) Responsibility: The assigned duties and work that
a project team member is expected to perform in
order to complete the project’s activities
(D) Competency: The skill and capacity required to
complete assigned activities within the project
constraints. If project team members do not
possess required competencies, performance can
be jeopardized. When such mismatches are
identified, proactive responses such as training,
hiring, schedule changes, or scope changes are
identified.
(1.2) Project Organization Charts
(1.3) Staffing Management Plan: describes when and how
project team members will be acquired and how long they
will be needed.
(A) Staff acquisition:
• Whether the human resources come from within
the organization or from external contracted sources
• Whether the team members need to work in
central locations or may work from distant locations
• Costs associated with each level of expertise
needed for the project
• Level of assistance that the organization’s human
resource department and functional managers are

of 61
the project.
The project
management team is a
subset of the project
team and is
responsible for the
project management
and leadership
activities such as
initiating, planning,
executing, monitoring,
controlling, and
closing. For smaller
projects the project
management
responsibilities may be
shared, by the entire
team or administered
solely by the project
manager. The project
sponsor works with the
project management
team, typically
assisting with matters
such as project
funding, clarifying
scope, monitoring
progress, and
influencing
stakeholders in both
the requesting and
performing
organization for the
project benefit.
Managing and leading
the project team
includes
(1) Influencing the
project team: The
project manager needs
to be aware of and
influence, when
possible, human
resource factors that
may impact the
project. These factors
include team
environment,
geographical locations
of team members,
communications
among stakeholders,
internal and external
politics, cultural issues,
organizational
uniqueness, and other
factors that may alter
project uniqueness
(2) Professional &
Ethical behavior: The
project management
team should be aware
communication among team members; and providing leadership.
While team building is essential during the front end of the project, it
is an ongoing process. Changes in a project environment are
inevitable. To manage these changes effectively, a continued and
renewed team-building effort is required. Outcomes of team building
include mutual trust, high quality of information exchange, better
decision making, and effective decision making
Influencing: is a strategy of sharing power and relying on
interpersonal skills to get others to cooperate towards common
goals. Using the following guidelines can influence team members
(1) Lead by example, and follow through with commitments
(2) Clarify how a decision will be made
(3) Use a flexible interpersonal style and adjust the style to the
audience
(4) Apply your power skillfully and cautiously. Think of long-term
collaboration.
Trust Building: The ability to build trust across the project team and
other key stakeholders is a critical component in effective team
leadership. Trust is associated with cooperation, information sharing
and effective problem resolution. Without trust it is difficult to
establish the positive relationships necessary between the various
stakeholders engaged in the project. When trust is compromised,
relationships deteriorate, people disengage, and collaboration
becomes more difficult, if not impossible. Some actions project
managers can take to help build trust
(1) Engage in open and direct communication to resolve problems
(2) Keep all stakeholders informed, especially when fulfilling
commitments is at risk
(3) Spend time directly engaged with the team asking non-
assumptive questions to gain a better understanding of the situations
affecting the team
(4) Be direct and explicit about what you need or expect
(5) Do not withhold information out of a fear of being wrong but be
willing to share information even if you may be wrong
(6) Be receptive to innovation and address any issue or concerns in a
forthright manner
(7) Look beyond your own interest
(8) Demonstrate a true concern for others and avoid engaging in
pursuits that could be viewed as being detrimental to the interest of
others
Leadership: Leadership involves focusing the efforts of a group of
people toward a common goal and enabling them to work as a team.
In general terms, leadership is the ability to get things done through
others. Respect and trust, rather than fear and submission, are the
key elements of effective leadership. Although important throughout
all project phases, effective leadership is critical during the beginning
phases of a project when the emphasis is on communicating the
vision and motivating and inspiring project participants to achieve
high performance.
(Responsible, Accountable, Consult,
Inform). The work to be
accomplished is mentioned in the
left column as activities. The
assigned resources can be shown
as individual or groups. A RACI
chart is a useful tool use when the
team consisits of internal and
external resources in order to
ensure clear divisions of roles and
expectations.
(1.3) Text Oriented formats: Also known as
position descriptions and role-responsibility-
authority-forms.
(2) Networking: Formal and informal
interaction with other in an organization,
industry or professional environment.
(3) Organizational Theory
(3.1) Expectancy Theory (VROOM):
Employee is motivated to exert high level of
efforts when he believes that efforts will
lead to good performance and therefore
organizational rewards that will satisfy
achievements of personal goal.
(3.2) McGregor’s Theory X and Y: Theory X
states that people would be passive
therefore management must persuade,
reward, and punish the worker to achieve
the desired behavior of workers. Theory Y
States that people can be self-directed and
creative at work, people display extreme
degree of self-control which is necessary for
achieving goals, work is natural as play, the
capacity of creativity in solving
organizational problems is widely distributed
in the population
(3.3) Maslow’s Hierarchy of Needs:
Physiological (bottom of pyramid) > safety
> social > Esteem > Self-actualization (top
of Pyramid)
(3.4) David McClelland’s Theory of Needs:
(Acquired-Needs Theory) According to this
theory, individuals acquire three types of
needs as a result of their life experiences.
These needs are, the need for achievement,
the need for affiliation, and the need for
power. All individuals possess a combination
of these needs, and the dominant needs are
thought to drive employee behavior
(3.5) Herzberg’s Theory: Factors causing
dissatisfaction of workers as “hygiene
factors” because these factors were part of
the context in which the job was performed,
as opposed to the job itself. Hygiene factors
include company policies, supervision,
working conditions, salary, safety, and
security on the job. “Motivators” are factors
that are intrinsic to the job which truly
encourage employees to try harder such as
achievement, recognition, interesting work,
increased responsibilities, advancements,
and growth opportunities.
(3.6) ERG Theory of Motivation: E =
able to provide to the project management team.
(B) Resource Calendars: Calendars that identify the
working days and shifts on which each specific
resource is available.
• Resource Histograms: This illustrates the no of
hours a person, department, or entire project team
that will be needed each week or month over the
course of the project. The chart can include a
horizontal line that represents the maximum no of
hours available form a particular resource.
(C) Staff release plan: Determining the method and
timing of releasing team members benefits both
the project and team members. When team
members are released from a project, the costs
associated with those resources are no longer
charged to the project, thus reducing project
costs. Morale is improved when smooth transitions
to upcoming projects are already planned. A staff
release plan also helps mitigate human resources
risks that may occur during or at the end of a
project.
(D) Training Needs
(E) Recognition and rewards
(F) Compliance
(G) Safety

of 61
of, subscribe to, and
ensure that all team
members follow
professional and
ethical behavior
Existence need, R = Relatedness, G =
Growth
(3.7) Porter And Lawler Model Of
Motivation: Valve of rewards > Efforts >
Perceived Efforts – Reward Probability >
Performance > Satisfation
(4) Expert Judgment: is used to
(4.1) List the preliminary requirements for
the required skills
(4.2) Assess the roles required for the
project based on standardized role
descriptions within the organization
(4.3) Determine the preliminary effort level
and number of resources needed to meet
project objectives.
(4.4) Determine reporting relationships
needed based on the organizational culture
(4.5) Provide guidelines on lead time
required for staffing, based on lessons
learned and market conditions
(4.6) Identify risks associated with staff
acquisition, retention and release plan.
(4.7) Identify and recommend programs for
complying with government and union
contracts.
(5) Meetings
Process Group: Executing
9.2 Acquire Project Team
It is the process of confirming human resource availability and
obtaining the team necessary to complete project activities
Benefits: Consists of outlining and guiding the team selection and
responsibility assignment to obtain a successful team
The project management team may or may not have direct control
over team member selection because of collective bargain
agreements, use of subcontractor personnel, matrix project
environment, internal or external reporting relationships, or other
various reasons. It is important that following factors are considered
during the process of acquiring the project team
(1) The project manager or project management team should
effectively negotiate and influence others who are in a position to
provide the required human resources for the project.
(2) Failure to acquire the necessary human resources for the project
may affect project schedules, budgets, customer satisfaction, quality
and risks. Insufficient human resources or capabilities decrease the
probability of success and, in a worst case scenario, could result in
project cancellation.
(3) If the human resources are not available due to constraints, such
as economic factors or previous assignments to other projects, the
project manager or project team may be required to assign
alternative resources, perhaps with lower competencies, provided
there is no violation of legal, regulatory, mandatory, or other specific
criteria.
(1) Pre-Assignment: When project team
members are selected in advance, they are
considered pre-assigned. This situation can
occur if the project is the result of specific
people being identified as part of a
competitive proposal, if the project is
dependent upon the expertise of particular
persons, or if some staff assignments are
defined within the project charter.
(2) Negotiation: The project management
team may need to negotiate with
(2.1) Functional Managers to ensure that
the project receives appropriately
competent staff in the required time frame
& that the project team members will be
able, willing, and authorized to work on the
project until their responsibilities are
completed.
(2.2) Other project management teams
within the performing organization, to
appropriately assign scarce or specialized
human resources
(2.3) External organizations, vendor,
suppliers, etc, for appropriate, scarce,
specialized, qualified, certified, or other
such specified human resources. Special
consideration must be given to external
negotiation policies, practices, processes,
guidelines, legal and other such criteria.
(3) Acquisition: When the performing
organization is unable to provide the staff
needed to complete a project, the required
services may be acquired from oside
source. This can involve hiring individual

of 61
consultants or subcontracting work to
another organization.
(4) Virtual Teams: Can be defined as groups
of people with a shared goal who fulfill their
roles with little or no time spent meeting
face to face. The virtual teams model make
it possible to
(4.1) Form teams of people from the same
organization who live in widespread
geographic areas.
(4.2) Add special expertise to the project
team even though the expert is not in the
same geographic area.
(4.3) Incorporate employees who work from
home offices
(4.4) Form teams of people who different
shifts, hours or days.
(4.5) Include people with mobility
limitations or disabilities
(4.6) Move forward with the projects that
would have been ignored due to travel
expenses.
There are some disadvantages related to
virtual teams, such as possibility for
misunderstanding, feeling of isolation,
difficulties in sharing knowledge and
experience between team members, and
cost of appropriate technology.
Communication planning becomes
increasingly important in a virtual team
environment. Additional time may be
needed to set clear expectations, facilitate
communications, develop protocols for
resolving conflict, include people in decision
making, understand cultural differences,
and share credit in success.
(5) Multi-Criteria Decision Analysis: By use
of multi-criteria decision analysis tool,
criteria are developed and used to rate or
score potential team members. The criteria
are weighted according to the relative
importance of the needs within the team.
Some of the selection criteria are
(5.1) Availability,
(5.2) Cost
(5.3) Experience
(5.4) Ability
(5.5) Knowledge
(5.6) Skills
(5.7) Attitude
(5.8) International Factors
9.3 Develop Project Team
It is the process of improving competencies, team member
interaction, and overall team environment to enhance project
performance
Benefits: It results in improved team work, enhanced people skills
and competencies, motivated employees, reduced staff turnover
rates, and improved overall project performance
(1) Interpersonal Skills (Soft Skills)
(1.1) Leadership
(1.2) Team Building
(1.3) Motivation
(1.4) Communication
(A) Team Member Comm. Styles
• Directive
• Collaborative
• Logical
• Explorer
(B) Listening Techniques
(1) Team Performance Assessment: The performance of a
successful team is measured in terms of technical success
according to agreed- upon project objectives (including
quality levels), performance on project schedule (finished
on time), and performance on budget (finished within
financial constraints). High-performance teams are
characterized by these task- oriented and result-oriented
outcomes. As a result of conducting an evaluation of the
team’s overall performance, the project management
team can identify specific training, coaching, mentoring,
assistance, or changes required to improve the team’s

of 61
Project managers should acquire skills to identify, build, maintain,
motivate, lead, and inspire project teams to achieve high team
performance and to meet the project objectives. Team work is a
critical factor for project success, and developing effective project
teams is one of the primary responsibility of project manager. Project
manager should create an environment that facilitates team work.
Project manager should continually motivate their team by providing
challenges and opportunities, by providing timely feedback and
support as needed and by recognizing and rewarding good
performance. High team performance can be achieved by using open
and effective communication, creating team building opportunities,
developing trust among team members, managing conflicts in
constructive manner, and encouraging collaborative problem solving
and decision making. The project manager should request
management support and / or influence the appropriate stakeholders
to acquire the resources needed to develop effective project teams.
Project managers operate in global environment and work on
projects characterized by cultural diversity. Team members often
have diverse industry experience, known multiple languages and
sometimes operate in the ‘team language” that may be a different
language or norm than the native one. The project team should
capitalize on cultural differences, focus on developing and sustaining
the project team throughout the life cycle, and promote working
together inter dependent to in a climate of mutual trust. Developing
the project team improves the people skills, technical competencies,
and overall team environment and project performance. It requires
clear, timely, effective and efficient communication between team
members throughout the life of the project. Objectives of developing
a project team include.
(1) Improving knowledge and skills of team members to increase
their ability to complete project deliverables, while lowering costs,
reducing schedules, and improving quality
(2) Improving feelings of trust and agreement among team members
to raise morale, lower conflict, and increase team work
(3) Creating a dynamic, cohesive and collaborative team culture to
(1) improve individual and team productivity, team spirit, and
cooperation and (2) allow cross training and mentoring between
team members to share knowledge and expertise.
• Active
• Passive
(1.5) Influencing
(1.6) Decision Making
(A) Decision Making Styles
• Command
• Consultation
• Consensus
• Coin flip (random)
(B) Factors that affect the decision style
• Time constraints
• Trust
• Quality
• Acceptance
(C) Decision Making Model
• Problem Definition
• Problem Solution Generation
• Ideas to Action
• Solution Action Planning
• Solution Evaluation Planning
• Evaluation of the outcome &
processes
(1.7) Political & Cultural Awareness
(1.8) Negotiation
(1.9) Trust Building
(1.10) Conflict Management
(A) Main Sources
• Incongruent requirements
• Competition for resources
• Breakdown in communications
(B) Handling Styles
• Collaborative
• Assertiveness
• Accommodation
• Avoidance or Compromise
(1.11) Coaching
(1.12) Emotional Intelligence
(2) Training: It includes all activities
designed to enhance the competencies of
the project team members. Training can be
formal or informal. E.g. of training methods
include classroom, online, computer-based,
on-the-job training from another project
team member, mentoring and coaching. If
project team members lack the necessary
management or technical skills, such skills
can be developed as part of the project
work. Schedule training takes place as
stated in the human resource management
plan. Unplanned training takes place as a
result of observation, conversation, and
project performance appraisals conducted
during the controlling processes of
managing the project team. Training cost
could be included in the project budget, or
supported by the performing organization if
the added skills may be useful for future
projects. It could be performed by in-house
or external trainers.
(3) Team-building activities: The Tuckman
ladder (Tuckman 1965; Tuckman & Jensen,
1977), which includes five stages of
development that teams, may go through.
performance. This should also include identification of the
appropriate or required resources necessary
The evaluation of team’s effectiveness may include
indicators such as
(A) Improvements in skills that allow individuals to
perform assignments mere effectively
(B) Improvements in competencies that help the
team perform better as a team
(C) Reduced staff turnover rate
(D) Increased team cohesiveness where team
members share information and experiences
openly and help each other to improve the overall
project performance.
(2.1) Personnel Administration
(2.2) Employee training records
(2.3) Skill assessments
Phase-to-Phase Relationship:
(1) Sequential Relationship: A phase starts only when the previous relationship is complete. Step by step nature of the approach reduces
uncertainty, but may eliminate options for reducing the overall schedule.
(2) Overlapping Relationship: A phase starts prior to completion of previous one. Eg. Of schedule compression technique called fast tracking.
Overlapping phases may require additional resources to allow work to be done in parallel, may increase risk, and can result in rework if a
subsequent phase progresses before accurate information is available from the previous phase.

of 61
(3.1) Forming: This phase is when the team
meets and learns about the project and
their formal roles and responsibilities. Team
members tend to be independent and not
as open in this phase
(3.2) Storming: During this phase, the team
begins to address the project work,
technical discussions, and the project
management approach. If team members
are not collaborative and open to differing
ideas and perspective, the environment can
become counterproductive.
(3.3) Norming: In this phase, team
members begin to work together and adjust
their work habits and behaviors to support
the team. The team learns to trust each
other.
(3.4) Performing: Teams that reach the
performing stage function as a well-
organized unit. They are interdependent
and work through issues smoothly and
effectively.
(3.5) Adjourning: In this phase, the team
completes the work and moves on from the
project. This typically occurs when staff is
released from the project as deliverables
are completed or as part of carrying out the
close Project or Phase process
(4) Ground Rules: establishes clear
expectations regarding acceptable behavior
by project team members. Early
commitment to clear guidelines decreases
misunderstandings and increases
productivity. Discussing ground rules in
areas such as code of conduct,
communication, working together, or
meeting etiquette allows team members to
discover values that are important to one
another. All project team members share
responsibility for enforcing the rules omnce
they are established.
(5) Colocation: Also referred to as “tight
matrix”, involves placing many or all of the
most active project team members in the
same physical location to enhance their
ability to perform as a team. Colocation can
be temporary, such as at strategically
important times during the project, or for
the entire project. Colocation strategies can
include a team meeting room (sometimes
called “war room”), places to post
schedules, and other conveniences that
enhance communication and a sense of
community.
(6) Recognition and Rewards: Part of the
team development process involves
recognizing and rewarding desirable
behavior. The original plans concerning
ways in which to reward people are
developed during the plan human resource
management process. Award decisions are
made, formally or informally, during the
Predictive lifecycles: Also known as fully plan-driven are ones in which the project scope, and the time and cost required to deliver that
scope are determined as early in the project life cycle as practically possible. These projects proceed through a series of sequential or
overlapping phases, with each phase generally focusing on a subset of project activities and project management processes. The work
performed in each phase is usually different in nature to that in the preceding and subsequent phases, therefore, the makeup and skills
required of the project team may vary from phase to phase. Preferred when the product to be delivered is well understood, there is
substantial base of industry practice or when the product is required to be delivered in full to have value to stakeholder groups.

of 61
process of managing the project team
through project performance appraisals.
Cultural differences should be considered
while determining recognition and rewards.
Most project team members are motivated
by an opportunity to grow, accomplish, and
apply their professional skills to meet new
challenges. A good strategy for project
managers is to give the team recognition
throughout the lifecycle of the project
rather than waiting until the project is
completed
(7) Personnel Assessment Tools: Give
Project Managers & the project team insight
into areas of strength & weaknesses. These
tools help project managers assess the
team preferences, aspirations, how they
process and organize information, how they
tend to make decisions, and how they
prefer to interact with people. These tools
can provide improved understanding, trust,
commitment, and communications among
team members and facilitate more
productive teams throughout the project.
Various tools are available such as
(7.1) Attitudinal surveys
(7.2) Specific assessments
(7.3) Structured interviews
(7.4) Ability tests
(7.5) Focus groups
9.4 Manage Project Team
It is the process of tracking team member performance, providing
feedback, resolving issues, and managing team changes to optimize
project performance.
Benefits: It influences team behavior, manages conflict, resolves
issues, and appraises team member performance.
Managing the project team requires a variety of management skills
for fostering team work and integrating the efforts of team members
to create high performance teams. Team management involves a
combination of skills with special emphasis on communication,
conflict management, negotiation, and leadership. Project Managers
should provide challenging assignments to team members and
provide recognition for high performance.
(3) Team Performance Assessments
(4) Issue log
(1) Observation and Conversation
(2) Project Performance Appraisals:
Objectives for conducting performance
appraisals during the course of the project
can include clarification of roles and
responsibilities, constructive feedback to
team members, discovery of unknown or
unresolved issues, development of
individual training plans, and the
establishment of specific goals for further
time periods. The need for formal or
informal project performance appraisal
depends on the length of the project,
complexity of the project organization
policy, labor contract requirements, and the
amount and quantity of regular
communication.
(3) Conflict Management: Conflict is
inevitable in project environment. Sources
of conflict include scarce resources,
scheduling priorities, and personal work
styles. Team ground rules, group norms,
and solid project management practices,
like communication planning and role
definition, reduce the amount of conflict.
Successful conflict management results in
greater productivity and positive working
relationships. When managed properly,
difference in opinion can lead to increased
productivity and better decision making. If
the differences become negative factor,
(1) Change Requests
(2.1) HR Management Plan
(3.1) Issue logs
(3.2) Roles description
(3.3) Project Staff Assignments
(4) Enterprise Environmental Factors Updates
Adaptive Lifecycles: Also known as change-drive or agile methods are intended to respond to high levels of change and ongoing
stakeholder involvement. Adaptive methods are also iterative and incremental, but differ in that iterations are very rapid (usually with
duration of 2 to 4 weeks) and are fixed in time and cost. Adaptive projects generally perform several processes in each iteration, although
early iterations may concentrate more on planning activities.
The overall scope of the project will be decomposed into a set of requirements and work to be performed, sometimes referred to as a
product backlog. At the beginning of the iteration, the team will work to determine how many of the highest priority items on the backlog
list can be delivered within the next iteration. At the end of each iteration, the product should be ready for review by the customer. This
does not mean that the customer is required to accept the delivery, just that the product should not include unfinished, incomplete, or
unusable features. The sponsor and customer representatives should be continuously engaged with the project to provide feedback on
deliverables as they are created and to ensure that the product backlog reflects their current needs.
Generally preferred when dealing with a rapidly changing environment, when requirements and scope are difficult to define in advance,
and when it is possible to define small incremental improvements that will deliver value to stakeholders

of 61
project team members are initially
responsible for their resolution. If conflicts
escalate, the project manager should help
facilitate a satisfactory resolution. Conflict
should be addressed early and usually in
private, using a direct collaborative
approach. If disruptive conflict continues,
formal procedures may be used, including
disciplinary actions.
The success of project managers in
managing their project teams often
depends a great deal on their ability to
resolve conflict. Different project managers
may utilize different conflict resolution
methods. Factors that influence conflict
resolution methods include
(3.1) Relative importance and intensity of
conflict
(3.2) Time pressure for resolving the
conflict
(3.3) Positions taken be persons involved
(3.4) Motivation to resolve conflict on a
long-term or a short term basis
There are five general techniques for
resolving conflicts
(3.5) Withdraw/Avoid: Retreating from an
actual or potential conflict situation;
postponing the issue to be better prepared
or to be resolved by others
(3.6) Smooth/Accommodate: Emphasizing
areas of agreement rather than areas of
difference; conceding one’s position to the
needs of others to maintain harmony and
relationships
(3.7) Comprise/Reconcile: Searching for
solutions that bring some degree of
satisfaction to all parties in order to
temporarily or partially resolve the conflict
(3.8) Force/Direct: Pushing one’s view point
at the expense of the others; offering only
win-lose solutions, usually enforced through
a power position to resolve an emergency
(3.9) Collaborate/problem Solve:
Incorporating multiple view points and
insights from differing perspectives;
requires a cooperative attitude and open
dialogue that typically leads to consensus
and commitment.
(4) Interpersonal Skills
(4.1) Leadership,
(4.2) Influencing: Key influencing skills
include
(A) Ability to be persuasive and clearly
articulate points and positions
(B) High levels of active and effective
listening skills
(C) Awareness of, and consideration
for, the various perspectives in any
situation
(D) Gathering relevant and critical
information to address important
issues and reach agreements while
maintaining mutual trust
Iterative & Incremental Lifecycles: Iterative and incremental life cycle are ones in which project phases (also called iterations)
intentionally repeat one or more project activities as the project team’s understanding of the product increases. Iterations develop the
product through a series of repeated cycles, while increments successively add to the functionality of the product. These life cycles
develop products both iteratively and incrementally. Iterative and incremental projects may proceed in phases, and the iterations
themselves will be performed in a sequential of overlapping. During an iteration activities from all project management process groups will
be performed. At the end of each iteration, a deliverable or set of deliverables will be completed. Future iterations may enhance those
deliverables or create new ones. Each iteration incrementally builds the deliverables until the exit criteria for the phase are met, allowing
the project team to incorporate feedback.
In most iterative lifecycles, a high level vision will be developed for the overall undertaking, but the detailed scope is elaborated one
iteration at a time. Often the planning for the next iteration is carried out as work progresses on the current iteration’s scope and
deliverables. The work required for a given set of deliverables may vary in duration and effort, and the project team may change between
or during iterations.
Those deliverables that are not addressed with in the scope, of the current iteration are typically scoped at a high level only and may be
tentatively assigned to a specific future iteration. Changes to the scope are carefully managed once work begins. Generally preferred
when an organization needs to manage changing objectives and scope, to reduce the complexity of a project, or when the partial delivery
of a product is beneficial and provides value for one or more stakeholder groups without impact to the final deliverable or set of
deliverables. Large and complex projects are frequently executed in an iterative fashion to reduce risk by allowing the team to incorporate
feedback.

of 61
(4.3) Effective Decision making: Guidelines
for decision making include
(A) Focus on goals to be served
(B) Follow a decision making process
(C) Study the environment factors
(D) Analyze available information
(E) Develop personal qualities of the
team members
(F) Stimulate team creativity
(G) Manage risks
Communications
Management
that are required to
ensure timely and
appropriate planning,
collection, creation,
distribution, storage,
retrieval,
management, control,
monitoring and the
ultimate disposition of
project information.
Project Managers
spent most of their
time communicating
with team members
and other project
stakeholders, whether
they are internal (at all
organization levels) or
external to the
organization. Effective
communication creates
a bridge between
diverse stakeholders
who may have
different cultural and
organizational
backgrounds, different
levels of expertise, and
different perspective
and interests, which
impact or have an
influence upon the
project execution or
outcome.
The communication
activities involved in
these processes may
have often many
potential dimensions
that need to be
considered, including
but not limited to
(1) Internal (within the
project) and external
(customer, vendor,
other projects,
organizations, the
public)
10.1 Plan Communications Management
It is the process of developing an appropriate approach and plan for
project communications based on stakeholder’s information needs
and requirements, and available organizational assets.
Benefits: It identifies and documents the approach to communicate
most effectively and efficiently with stakeholders
Planning the project communications is important to the ultimate
success of any project. Inadequate communications planning may
lead to problems such as delay in message delivery, communication
of information to the wrong audience, or insufficient communication
to the stakeholders and misunderstanding or misinterpretation of the
message communicated.
On most projects, communication planning is performed very early,
such as during project management plan development. This allows
appropriate resources, such as time and budget, to be allocated to
activities.
Effective communication means that the information is provided in
the right format, at the right time, to the right audience, and with
the right impact.
Efficient communication means providing only the information that is
needed
Important consideration that need to be taken into account include
(1) Who needs what information, and who is authorized to access
that information
(2) When they will need the information
(3) Where the information should be stored
(4) How the information should be retrieved
Whether time zone, language barriers, and corss cultural
considerations needed to be taken into account.
(1) Communication Requirements Analysis:
The analysis of the communication
requirements determines the information
needs of the project stakeholders. These
requirements are defined by combining the
type and format of information needed with
an analysis of the value of that information.
Project resources should be expended only
on communicating information that
contributes to the success of the project or
where a lack of communication can lead to
failure.
The project manager should also consider
the number of potential communication
channels or paths as an indicator of the
complexity of a project’s communications.
The total number of potential
communication channel is [n(n-1)]/2, where
n represents the number of stakeholders.
As a result, a key component of planning
the project’s actual communications is to
determine and limit who will communicate
with whom and who will receive what
information.
(1.1) Organizational Charts
(1.2) Project Organization & Stakeholder
responsibility relationships
(1.2) Disciplines, Departments & Specialties
involved in the project
(1.3) Logistics of how many persons will be
involved in the project & at which locations
(1.4) Internal information Needs
(1.5) External information Needs
(1.6) Stakeholder information &
communication requirements from within
the stakeholder register
(2) Communication Technology: Methods
used to transfer information among project
stakeholders may vary significantly. Factors
that affect choice of communication
technology include
(2.1) Urgency of the need for information:
Urgency, frequency and format
(2.2) Availability of technology
(2.3) Ease of Use
(2.4) Project Environment
(2.5) Sensitivity and Confidentiality of the
information
(3) Communication Models: Basic
communication model consist of sender and
receiver. Medium is technology medium and
includes the mode of communication while
(1) Communications Management Plan
(1.1) Stakeholder communications requirements
(1.2) Information to be communicated, including
language, format, content, and level of detail
(1.3) Reason for the distribution of the information
(1.4) Time frame & the frequency for the distribution of
required information & receipt of acknowledgement or
response if applicable
(1.5) Person responsible for communicating the
information
(1.6) Person responsible for authorizing release of
confidential information
(1.7) Person or groups who will receive the information
(1.8) Methods or technologies used to convey the
information, such as memos, email, and /or press
releases.
(1.9) Resources allocated for communication activities
including time and budget
(1.10) Escalation process identifying time frames &
management chain (names) for escalation of issues that
cannot be resolved at a lower staff level.
(1.11) Method of updating & refining the communications
management plan as the project progresses & develops
(1.12) Glossary of common terminology
(1.13) Flow charts of the information flow in the project,
workflows with possible sequence of authorization, list of
reports, & meeting plans
(1.14) Communication constraints usually derived from a
specific legislation or regulation, technology &
organization policies.

of 61
(2) Formal (reports,
minutes, briefings) and
informal (emails,
memos, ad-hoc
discussions)
(3) Vertical (up &
down the organization)
and horizontal (with
peers)
(4) Official (news
letters, annual reports)
and unofficial (off the
record
communications)
(5) Written and Oral,
and verbal (voice
inflections) and no
verbal body language
Most communications
skills are common for
both general
management and
project management
(1) Listening actively
and effectively
(2) Questioning and
probing ideas and
situations to ensure
better understanding
(3) Educating to
increase team’s
knowledge so that
they can be more
effective
(4) Fact finding to
identify and confirm
information
(5) Setting and
managing expectations
(6) Persuading a
person, a team, or an
organization to
perform and action
(7) Motivating to
provide
encouragement or
reassurance
(8) Coaching to
improve performance
and achieve desired
results
(9) Negotiating to
noise includes any interference or barriers
that might compromise the delivery of the
message for e.g. distance, unfamiliar
technology, inadequate infrastructure,
cultural difference, and lack of back ground
information. The sequence of steps in a
basic communication model is
(3.1) Encode
(3.2) Transmit Message
(3.3) Decode
(3.4) Acknowledge
(3.5) Feedback/Response
The sender is responsible for the
transmission of the message, ensuring that
the information being communicated is
clear and complete, and conforming the
communication is clearly understood. The
receiver is responsible for ensuring that the
information is received in its entirety,
understood correctly, and acknowledged or
responded to appropriately.
(4) Communication Methods
(4.1) Interactive Communication: Between
two or more parties performing a
multidirectional exchange of information. It
is the most efficient way to ensure a
common understanding by all participants
on specified topics, and includes meetings,
phone calls, instant messaging, and video
conferencing.
(4.2) Push Communication: Sent to specific
recipients who intend to receive the
information. This ensures that the
information is distributed but does not
ensure that it actually reached or was
understood by the intended audience. E.g.
letters, memos, reports, emails, faxes, voice
mails, blogs, press releases
(4.3) Pull Communication: Used for very
large volumes of information, or for very
large audiences, and requires the recipients
to access the communication content at
their own discretion. E.g. intranet sites, e-
learning, lessons learned databases,
knowledge repository.
The choice of communication methods that
are used for a project may need to be
discussed and agreed upon by the project
stakeholders based on communication
requirements; cost and time constraints;
and familiarity and availability of the
required tools and resources that may be
applicable to the communication process
(5) Meetings
10.2 Manage Communications
It is the process of creating, collecting, distributing, storing,
retrieving, and the ultimate disposition of project information in
accordance to the communications management plan
(1) Communications Technology
(2) Communications Model
(3) Communications Methods
(4) Information Management Systems
(4.1) Hard Copy Document Management
(1) Project Communications: involves the activities that
are required for information to be created, distributed,
received, acknowledged, and understand. Project
communications may include
(1.1) Performance reports
(1.2) Deliverables status
(1.3) Schedule Progress
(1.4) Cost incurred

of 61
achieve mutually
acceptable agreement
between parties
(10) Resolving
conflicts to prevent
disruptive impacts
(11) Summarizing,
recapping, and
identifying the next
steps.
Benefits: It enables an efficient and effective communications flow
between project stakeholders
This process goes beyond the distribution of relevant information and
seeks to ensure that the information being communicated to project
stakeholders has been appropriately generated, as well as received
and understood. It also provides opportunities for stakeholders to
make requests for further information, clarification, and discussion.
Techniques and considerations for effective communication
management include
(1) Sender-receiver models: Incorporating feedback loops to provide
opportunities for interaction / participation and remove barrier to
communication
(2) Choice of media: Situation specifies as to when to communicate
in writing versus orally, when to prepare an informal memo vs a
formal report, and when to communicate face to face vs by email.
(3) Writing Style: Appropriate use of active vs passive voice,
sentence structure, and word choice
(4) Meeting Management Techniques: Preparing an agenda and
dealing with conflicts
(5) Presentation Techniques: Awareness of the impact of body
language and design of visual aids
(6) Facilitation Techniques: Building consensus and overcoming
obstacles
(7) Listening Techniques: Listening actively (acknowledging,
clarifying, and confirming understanding) and removal of barriers
that adversely affect comprehension
(4.2) Electronic Communications
Management
(4.3) Electronic Project Management Tools
(5) Performance Reporting: Act of collecting
and distributing performance information,
including status reports, progress
measurements, and forecasts. Performance
reporting involves the periodic collection
and analysis of baseline vs actual data to
understand and communicate the project
progress and performance as well as to
forecast the project results. Performance
reporting may include
(5.1) Analysis of past performance
(5.2) Analysis of project forecasts (including
time and cost)
(5.3) Current status of risk and issues
(5.4) Work completed during the period
(5.5) Work to be completed in the next
period
(5.6) Summary of changes approved in the
period
(5.7) Other relevant information, which is
reviewed and discussed.
Project communications vary significantly and are
influenced by factors such as,
(1.5) Urgency and impact
(1.6) method of delivery
(1.7) level of confidentiality
(2) Project Management Plan Updates: The project
management plan provides information on project
baselines, communications management, and stakeholder
management. Each of these areas may require updates
based upon the current performance of the project against
the performance measurement baseline (PMB). The
performance measurement baseline is an approved plan
for the project work to which the project execution is
compared, and deviations are measured for management
control. The performance measurement baseline typically
integrates scope, schedule, and cost parameters of a
project, but may also include technical and quality
parameters.
(3.1) Issue Log
(3.4) Project Funding Requirement
(4.1) Stakeholder Notifications
(4.2) Project Reports
(4.3) Project Presentations
(4.4) Project Records
(4.5) Feedback from stakeholders
(4.6) Lessons Learned Documentation
Process Group: Controlling
10.3 Control Communications
It is the process of monitoring and controlling communications
throughout the entire project life cycle to ensure that the information
needs of the project stakeholders are met
Benefits: It ensures and optimal information flow among all
communication participants, at any moment in time
The control communications process can trigger an interaction of the
plan communications management and / or manage communications
processes. This iteration illustrates the continuous nature of the
project communications management processes. Specific
communication elements, such as issues or key performance
indicators (eg actual vs planned schedule, cost, and quality) may
trigger an immediate revision, while others may not. The impact and
repercussions of project communications should be carefully
evaluated and controlled to ensure that the right message is
delivered to the right audience at the right time.
(1.1) Stakeholder communication requirement
(1.2) Reason for the distribution of the
information
(1.3) Time frame & Frequency for the
distribution of required information
(1.4) Individual or group responsible for
communication of the information
(1.5) Individual or group receiving the
information
(2) Project Communications
(2.1) Deliverables status
(2.3) Cost Incurred
(3) Issue log: An issue log is used to document
and monitor the resolution of issues. It may be
used to facilitate communication and ensure a
common understanding of issues. A written log
documents and helps to monitor who is
responsible for resolving specific issues by a
target date. Issue resolution addresses
obstacles that can block the team from
achieving its goals. This information is
important to the control communications
process as it provides both a repository for what
has already happened in the project and a
platform for subsequent communications to be
delivered.
(2) Expert Judgment
(3) Meetings
(2) Change Requests
(2.1) New or revised cost estimates, activity sequences,
schedule dates, resource requirements, and analysis of
risk response alternatives
(2.2) Adjustments to the project management plan and
documents
(2.3) Recommendations of corrective actions that may
bring the expected future performance of the project back
in line with the project management plan
(2.4) Recommendations of preventive actions that may
reduce the probability of incurring future negative project
performance
(4.1) Forecasts
(4.2) Work Performance Reports
(4.3) Issue log

of 61
(5.1) Report templates
(5.2) Policies, standards, and procedures that
define communications
(5.3) Specific communication technologies
available
(5.4) Allowed communication media
(5.5) Record retention policies
(5.6) Security requirements
Risk
Management
of conducting risk
management planning,
identification, analysis,
response planning,
and controlling risk on
a project
Project risk is an
uncertain event or
condition that, if it
occurs, has a positive
or negative effect on
one or more project
objectives such as
scope, schedule, cost,
and quantity. A risk
may have one or more
causes and if it occurs,
it may have one or
more impacts. A cause
may be a given or
potential requirement,
assumption,
constraint, or condition
that creates the
possibility of negative
or positive outcomes.
Risk conditions may
include aspects of the
project’s or
organization’s
environment that
contribute to project
risk, such as immature
project management
practices, lack of
integrated
management systems,
concurrent multiple
projects, or
dependency on
external participants
who are outside the
project’s direct control.
Project risk has its
origins in the
uncertainty present in
all projects. Known
risks are those that
11.1 Plan Risk Management
It is the process of defining how to conduct risk management
activities for a project.
Benefits: It ensures that the degree, type, and visibility of risk
management are commensurate with both the risks and the
importance of project to the organization.
The risk management plan is vital to communicate with and obtain
agreement and support from all stakeholders to ensure the risk
management process is supported and performed effectively over
the project life cycle.
Careful and explicit planning enhances the probability of success for
other risk management processes. Planning is also important to
provide sufficient resources and time for risk management activities
and to establish an agreed – upon basis for evaluating risks. The
plan risk management process should begin when a project is
conceived and should be completed early during project planning.
(2) Project Charter
(1) Analytical Techniques: are used to
understand and define the overall risk
management context of the project. Risk
Management Context is a combination of
Stakeholder risk attitude and the Strategic
Risk Exposure. For e.g. Stakeholder Risk
Profile Analysis may be performed to grade
and qualify the project stakeholder risk &
appetite and tolerance. Other techniques,
such as the use of strategic risk scoring
sheets, are used to provide a high-level
assessment of the risk exposure of the
project based on the overall project context
Depending on these assessments; the
project team can allocate appropriate
resources and focus on the risk
management activities.
(2) Expert Judgment
(3) Meetings
(1) Risk Management Plan
(1.1) Methodology: approaches, tools, and data sources
that will be used to perform risk management on the
project.
(1.2) Roles and Responsibilities:
(1.3) Budgeting
(1.4) Timing
(1.5) Risk Categories: Provide a means for grouping
potential cause of risk. Several approaches can be used,
for e.g. a structure based on project objectives by
category. A Risk Breakdown Structure (RBS) helps the
project team to look at many sources from which project
risk may arise in a risk identification exercise. The RBS is a
hierarchical representation of risks according their risk
categories.
(1.6) Definitions of risk probability and impact: The quality
and credibility of the risk analysis requires that different
levels of risk probability and impact be defined that are
specific to the project context. General definitions of
probability levels and impact levels are tailored to the
individual project during the plan risk management
process for use in subsequent processes. Risk Impact
definitions on different project objectives should be
tailored in the Risk Management Planning process to the
individual project and to the organization’s risk thresholds.
Impact definitions can be developed for opportunities in a
similar way
(1.7) Probability and Impact Matrix: is a grid for mapping
the probability of each risk occurrence and its impact on
project objectives if that risk occurs. Risks are prioritized
according to their potential implications for having an
effect on the project’s objectives. A typical approach to
prioritized risks is to use a lookup table or a probability
and impact matrix. The specific combinations of
probability and impact that lead to a risk being rated as
“high”, “moderate”, or ‘low” importance are usually set by
the organizations
(1.8) Revised stakeholder tolerances:
(1.9) Reporting formats
(1.10) Tracking
11.2 Identify Risks
It is the process of identifying which risk may affect the project and
documenting their characteristics
Benefits: The documentation of existing risks and the knowledge
and ability it provides to the project team to anticipate events.
Identify risks is an iterative process, because new risks may evolve
or become known as the project progresses through its life cycle.
(1.1) Roles & Responsibilities
(1.2) Cost/Schedule Provisions
(1.3) Risk Categories (RBS)
(4) Quality Management Plan
(1) Documentation Reviews: A structured
review of the project documentation may be
performed, including plans, assumptions,
previous project files, agreements, and
other information. The quality of the plans,
as well as consistency between those plans
and the project requirements and
assumptions, may be indicators of risk in
the project
(2) Information Gathering Techniques
(2.1) Brainstorming: The goal of
(1) Risk Register: The primary output from identify risk is
the initial entry into the risk register. The risk register is a
document in which the results of risk analysis and risk
response planning are recorded. It contains the outcomes
of the other risk management processes as they are
conducted, resulting in an increase in the level and type of
information contained in the risk register overtime. The
preparation of the risk register begins in the identifying
risks process with the following information, and then
becomes available to other project management and risk
management processes
(1.1) List of Identified Risk: The identified risks are

of 61
have been identified
and analyzed, making
it possible to plan
responses for those
risks. Known risks that
cannot be managed
proactively, should be
assigned a
contingency reserve.
Unknown risks cannot
be managed
proactively and
therefore may be
assigned a
management reserve.
A negative project risk
that has occurred is
considered an issue.
Individual project risks
are different from
overall project risk.
Overall project risk
represents the effect
of uncertainty on the
project as a whole. It
is more than the sum
of the individual risks
within a project, since
it includes all sources
of project uncertainty.
It represents the
exposure of
stakeholders to
implications of
variations in project
outcome, both positive
and negative.
Organizations perceive
risk as the effect of
uncertainty on projects
and organizational
objectives.
Organizations and
stakeholders are
willing to accept
varying degree of risks
depending on their risk
attitude. The risk
attitudes of both the
organization and the
stakeholders may be
influenced by a
number of factors,
which are broadly
classified into three
themes
(1) Risk Appetite:
Which is the degree of
uncertainty an entity is
willing to take on in
anticipation of a
reward.
The frequency of iteration and participation in each cycle will vary by
situation. The format of the risk statements should be consistent to
ensure that each risk is understood clearly and unambiguously in
order to support effective analysis and response development. The
risk statement should support the ability to compare the relative
effect of one risk against others on the project. The process should
involve the project team so they can develop and maintain a sense
of ownership and responsibility for the risk response actions
stakeholders outside the project team may provide additional
objective information.
(6) Scope Baseline: Project assumptions are
found in the project scope statement.
Uncertainty in project assumptions should be
evaluated as potential causes of project risk.
The WBS is a critical input to identifying risks as
it facilitates an understanding of the potential
risks at both the micro and macro levels. Risks
can be identified and subsequently tracked at
summary, control account, and . or work
package level.
(8) Activity Duration Estimates
(10.1) Project Charter
(10.3) Project Schedule Diagrams
(10.4) Issue Log
(10.5) Quality Checklists
(10.6) Other information proven to be valuable
in identifying risks
(11) Procurement Documents
brainstorming is to obtain a comprehensive
list of project risks. The project team
usually performs brainstorming, often with a
multidisciplinary set of experts who are not
part of the team. Ideas about the project
risk are generated under the leadership of a
facilitator, either in a traditional “free-form
brainstorm” session or “structured mass
interviewing techniques”. Categories of risk,
such as in risk breakdown structure, can be
used as a framework. Risk are then
identified and categorized by type of risk
and their definitions are refined.
(2.2) Delphi Technique: is a way to reach
consensus of experts. Project risk experts
participate in this technique anonymously. A
facilitator uses a questionnaire to solicit
ideas about the important project risk. The
responses are summarized and are then
recirculated to the experts for further
comments. Consensus may be reached in
few rounds of this process. The Delphi
technique helps reduce bias in the data and
keeps any one person having undue
influence on the outcome.
(2.3) Interviewing: experienced project
participants, stakeholders, and subject
matter experts helps to identify risks
(2.4) Root Cause Analysis: is a specific
technique used to identify a problem,
discover the underlying causes that lead to
it, and develop preventive action
(3) Checklist Analysis: Risk identification
checklist are developed based on historical
information and knowledge that has been
accumulated from previous similar projects
and from other sources of information. The
lowest level of RBS can also be used as risk
checklist. While a checklist may be quick
and simple, it is impossible to build an
exhaustive one, and care should be taken to
Ensure the checklist is not used to avoid the
effort of proper risk identification. The team
should also explore items that do not
appear on check list. Additionally, checklist
should be pruned from time to time to
remove or archive related items. The
checklist should be reviewed during project
closure to incorporate new lessons learned
and improve it for use on future projects.
(4) Assumptions Analysis: Every project and
its plan is conceived and developed based
on a set of hypotheses, scenarios, or
assumptions. Assumption analysis explores
the validity of assumptions as they apply to
the project. It identifies risks to the project
from inaccuracy, instability, inconsistency,
or incompleteness of assumptions.
(5) Diagraming Techniques
(5.1) Cause and Effect Diagrams: Also
known as Ishikawa or fishbone diagrams
and are useful for identifying causes of
described in as much detail as is reasonable. A structure
for describing risks using risks statements may be applied,
for e.g. EVENT may occur causing IMPACT, or if CAUSE
exists, EVENT may occur leading to EFFECT. In addition to
the list of identified risks, the root cause of those risks
may become more evident. These are the fundamental
conditions or events that may give rise to one or more
identified risks. They should be recorded and used to
support future risk identification for this and other
projects.
(1.2) List of Potential Responses: Potential responses to a
risk may sometimes be identified during the Identify Risks
process. These responses, if identified in this process,
should be used as inputs to the Plan Risk Responses
Process.

of 61
(2) Risk Tolerance:
Which is the degree,
amount, or volume of
risk that an
organization or
individual will
withstand.
(3) Risk Threshold:
This refers to measure
along the level of
uncertainty or the level
of impact at which a
stakeholder may have
a specific interest.
Below that risk
threshold, the
organization will
accept the risk. Above
the risk threshold, the
organization will not
tolerate the risk.
Positive and Negative
risks are commonly
referred to as
opportunities and
threats. The project
may be accepted if the
risks are within
tolerances and are in
balance with the
rewards that may be
gained by taking the
risks. Positive risks
that offer opportunities
within the limits of risk
tolerance may be
pursued in order to
generate enhanced
value.
Individuals and groups
adopt attitudes toward
risk that influence the
way they respond.
These risk attitudes
are driven by
perception, tolerances,
and other biases,
which should be made
explicit wherever
possible. A consistent
approach to risk
should be developed
for each project, and
communication about
risk and its handling
should be open and
honest. Risk responses
reflect an
organization’s
perceived balance
between risk taking
risks.
(5.2) System or Process Flow charts: These
show how various elements of a system
interrelate and the mechanism of causation
(5.3) Influence diagrams: These are
graphical representations of situations
showing causal influences, time ordering of
events, and other relationships among
variables and outcomes.
(6) SWOT Analysis: This technique
examines the project from each of the
strength, weakness, opportunities, and
threats (SWOT) perspective to increase the
breadth of identified risks by including
internally generated risks. The technique
starts with identification of strengths and
weakness of the organization, focusing on
either the project organization, or the
business area in general. SWOT analysis
then identifies any opportunities for the
project that arise from organizational
strengths, and any threats arising from
organizational weakness. The analysis also
examines the degree to which
organizational strengths offset threats, as
well as identifying opportunities that may
serve to overcome weakness.
(7) Expert Judgment
11.3 Perform Qualitative Risk Analysis
It is the process of prioritizing risks for further analysis or action by
assessing and combining their probability of occurrence and impact.
Benefits: It enables project managers to reduce the level of
uncertainty and focus on high-priority risks.
Perform Qualitative Risk Analysis assesses the priority of identified
risks using their relative probability or likelihood of occurrence, the
corresponding impact on project objectives if the risks occur, as well
as other factors such as the time frame for response and the
organization’s risk tolerance associated with the project constraints
of cost, schedule, scope, and quality. Such assessments reflect the
risk attitude of the project team and other stakeholders. Effective
assessments therefore requires explicit identification and
management of the risk approaches of key participants in the
perform qualitative risk analysis process. Where these risk
approaches introduce bias into assessment of identified risks,
attention should be paid to identifying bias and correcting it.
Establishing definitions of the levels of probability and impact can
reduce the influence of bias. The time criticality of risk-related
actions may magnify the importance of risk. An evaluation of the
quality of the available information on project risks also helps to
clarify the assessment of risk’s importance to the project.
Perform Qualitative risk analysis is usually a rapid and cost-effective
means of establishing priorities for Plan Risk Responses and lays the
foundation for perform quantitative risk analysis, if required. The
perform qualitative risk analysis process is performed regularly
throughout the project life cycle as defined in the projects risk
management plan. This process can lead into Perform Quantitative
(1) Risk Management Plan: Key elements used
are
(1.1) Roles and responsibilities for conducting
risk management
(1.2) Budget, schedule activities for risk
management
(1.3) risk categories
(1.4) definitions of probability and impact
(1.5) revised stakeholder risk tolerances
The inputs are usually tailored to the project
during the plan risk management processes. If
they are not available, they may be developed
during the perform qualitative risk analysis
process.
(2) Scope Baseline
(3) Risk Register
(4.1) Industry studies of similar projects by risk
specialists
(4.2) Risk databases that may be available from
industry or proprietary sources.
(1) Risk Probability and Impact assessment:
Risk probability assessment investigates the
likelihood that each specific risk will occur.
Risk impact assessment investigates the
potential effect on a project objective such
as schedule, cost, quality, or performance,
including both negative effects for threats
and positive effects for opportunities.
Probability and impact are assessed for
each identified risk. Risks can be assessed
in interviews or meetings with participants
selected for their familiarity with the risk
categories on the agenda. Project team
members and knowledgeable persons
external to the project are included.
The level of probability for each risk and its
impact on each objective is evaluated
during the interview or meeting.
Explanatory detail, including assumptions
justifying the levels assigned, are also
recorded. Risk probabilities and impacts are
related according to the definitions given in
the risk management plan. Risks with low
ratings of probability and impact will be
included in the risk register as part of the
watch list for future monitoring.
(2) Probability and Impact Matrix: Risk can
be prioritized for further quantitative
analysis and planning risk responses based
on their risk rating. Ratings are assigned to
risks based on their assessed probability
and impact. Evaluation of each risk’s
(1.1) Risk Register Updates: As new information becomes
available through the qualitative risk assessment, the risk
register is updated. Updates to the risk register may
include assessments of probability and impacts for each
risk, risk ranking or scores, risk urgency information or risk
categorization, and a watch list for low probability risks or
risks requiring further analysis.
(1.2) Assumptions Log Updates: As new information
becomes available through the qualitative risk assessment,
assumptions could change. The assumptions log needs to
be revisited to accommodate this new information.
Assumptions may be incorporated into the project scope
statement or in a separate assumptions log.
Project Management Process: These processes ensure the effective flow of the project throughout its life cycle.
These processes encompass the tools and techniques involved in applying the skills and capabilities described in the
knowledge area

of 61
and risk avoidance.
To be successful, an
organization should be
committed to address
risk management
proactively and
consistently
throughout the
project. A conscious
choice should be made
at all levels of the
organization to actively
identify and pursue
effective risk
management during
the life of the project.
Project risk could exist
at the moment a
project is initiated.
Moving forward on a
project without a
proactive focus on risk
management is likely
to lead to more
problems arising from
unmanaged threats.
Risk Analysis or directly into Plan Risk Responses Plan. importance and priority for attention is
typically conducted using a lookup table or
a probability and impact matrix. Such a
matrix specifies combinations of probability
and impact that lead to rating the risks as
low, moderate, or high priority. Descriptive
terms or numeric values can be used
depending on organizational preference.
Each risk is rated on its probability of
occurrence and impact on an objective if it
does occur. The organization should
determine which combinations of probability
and impact result in a classification of high
risk, moderate, and low risk. Usually, these
risk-rating rules are specified by the
organization in advance of the project and
included in organizational process assets.
Risk rating rules can be tailored in the plan
risk management process to the specific
project.
An organization can rate a risk separately
for each objective (eg cost, time, and
scope). In addition, it may develop ways to
determine one overall rating for each risk.
Finally, opportunities and threats are
handled in the same matrix using definitions
of the different levels of impact that ate
appropriate for each.
The risk score helps to guide risk responses.
For eg, risks that have a negative impact on
objectives, otherwise known as threats if
they occur, and that are in the high-risk
zone of the matrix, may require priority
action and aggressive response strategies.
Threats found in the low-risk-zone may not
require proactive management action
beyond being placed in the risk register as
part of the watch list or adding a
contingency reserve. Similarly for
opportunities, those in the high-risk-zone,
which may be obtained most easily and
offer the greatest benefit, should be
targeted first. Opportunities in the low risk
zone should be monitored. The numbers of
steps in the scale are usually established
when defining the risk attitude of the
organization.
(3) Risk Data Quality Assessment: is a
technique to evaluate the degree to which
the data about risks is useful for risk
management. It involves examining the
degree to which the risk is understood and
the accuracy, quality, reliability and integrity
of the data about the risk
The use of low quality risk data may lead to
a qualitative risk analysis of little use to the
project. If data quality is unacceptable, it
may be necessary to gather data. Often, the
collection of information about risks is
difficult, and consumes more time and
Product-Oriented Process: These processes specify and create the projects product. Product-oriented processes
are typically defined by the project life cycle and vary by application area as well as the phase of the product life
cycle. The scope of the project cannot be defined without some basic understanding of how to create the specified
product
Tailoring: Project Managers and their team should carefully address each process and its inputs and outputs and
determine which are applicable to the project they are working on. The PMBOK guide may be used as a resource in
managing a project while considering the overall approach and methodology to be followed for the project. This
effort is known as tailoring.

of 61
resources than originally planned.
(4) Risk Categorization: Risks to the project
can be categorized by sources of risk (eg.
Using the RBS), the area of the project
affected (eg using the WBS), or other useful
categories (eg project phase) to determine
the areas of the project most exposed to
the effects of uncertainty. Risks can also be
categorized by common root causes. This
technique helps determine work packages,
activities, project phases or even roles in
the project, which can lead to the
development of effective risk responses.
(5) Risk Urgency Assessment: Risk requiring
near-term responses may be considered
more urgent to address. Indicators of
priority may include probability of detecting
the risk, time to affect a risk response,
symptoms and warning signs, and the risk
rating. In some qualitative analysis, the
assessment of risk urgency is combined
with risk ranking that is determined from
the probability and impact matrix to give a
final risk severity rating.
(6) Expert Judgment
11.4 Perform Quantitative Risk Analysis
It is the process of numerically analyzing the effect of identified risks
on overall project objectives.
Benefits: It produces quantitative risk information to support
decision making in order to reduce project uncertainty.
Perform quantitative risk analysis is performed on risks that have
been prioritized by the perform qualitative risk analysis process as
potentially and substantially impacting the project’s competing
demands. The perform quantitative risk analysis process analyses the
effect of those risks on project objectives. It is used mostly to
evaluate the aggregate effect of all risks affecting the project. When
the risks drive the quantitative analysis, the process may be used to
assign a numerical priority rating to those risks individually.
Perform quantitative risk analysis generally follows the perform
qualitative risk analysis process. In some cases, it may not be
possible to execute the perform quantitative risk analysis process
due to lack of sufficient data to develop appropriate models. The
project manager should exercise expert judgment to determine the
need for and the viability of quantitative risk analysis. The availability
of time and budget, and the need for qualitative or quantitative
statements about risk and impacts, will determine which methods to
use on any particular project. Perform quantitative risk analysis
should be repeated, as needed, as part of the control risk process to
determine if the overall project risk has been satisfactorily decreased.
Trends may indicate the need for more or less focus on appropriate
risk management activities.
(4) Risk Register
(1) Data Gathering and Representation
Techniques
(1.1) Interviewing: techniques draw on
experience and historical data to quantify
the probability and impact of risks on
project objectives. The information needed
depends upon the type of probability
distributions that will be used. For instance,
information would be gathered on optimistic
(low), pessimistic (high), and most likely
scenarios for some commonly used
distributions.
(1.2) Probability Distribution: Continuous
probability distributions, which are used
extensively in modeling and simulation,
represent the uncertainty in values such as
durations of schedule activities and costs of
project components. Discreet distributions
can be used to represent uncertain events,
such as the outcome of a test or a possible
scenario in a decision tree. Beta distribution
and triangular distribution are widely used
continuous distribution. These distributions
depict shapes that are compatible with the
data typically developed during the
quantitative risk analysis. Uniform
distributions can be used if there is no
obvious value that is more likely than
another between specified high and low
bands, such as in the early concept stage of
design. Other commonly used distributions
include uniform, normal, lognormal. In
these charts the horizontal (X) axes
represents possible values of time and cost
and the vertical (Y) axes represent relative
likelihood
(1.1) Risk Register
(1.1.1) Probabilistic Analysis of the project: Estimates are
made of potential project schedule and cost outcomes
listing the possible completion dates and costs with their
associated confidence levels. This output, often expressed
as a cumulative frequency distribution, is used with
stakeholder risk tolerances to permit qualification of the
cost and time contingency reserves. Such contingency
reserves are needed to bring the risk of overrunning
stated project objectives to a level acceptable to the
organization.
(1.1.2) Probability of achieving cost and time objectives:
With the risks facing the project, the probability of
achieving project objectives under the current plan can be
estimated using quantitative risk analysis results.
(1.1.3) Prioritized list of quantified risks: The list includes
those risks that pose the greatest threat or present the
greatest opportunity to the project. These include the risk
that may have the greatest effect on cost contingency and
those that are most likely to influence the critical path.
These risks may be evaluated, in some cases, through a
tornado diagram generated as a result of the simulation
analysis
(1.1.4) Trends in Quantitative Risk Analysis results: As the
analysis is repeated, a trend may become apparent that
leads to conclusions affecting risk responses.
Organizational historical information on project schedule,
cost, quality, and performance should reflect new insights
gained through the Perform Quantitative Risk Analysis
processes. Such history may take the form of a
quantitative risk analysis report. This report may be
separate from, or linked to, the risk register.

of 61
(2) Quantitative Risk Analysis and Modeling
Techniques: Commonly used techniques use
both even-oriented and project oriented
analysis approaches, including
(2.1) Sensitivity Analysis (Tornado
Diagram): helps to determine which risks
have the most potential impact on the
project. It helps to understand how
variations in project’s objectives coorelate
with variations in different uncertainties.
Conversely, it examines the extent to which
the uncertainty of each project elements
affects the objectives being studied when all
other uncertain elements are held at their
baseline values. One typical display of
sensitivity analysis is the tornado diagram
which is useful for comparing relative
importance and impact of variables that
have a high degree of uncertainty to those
that are more stable. The tornado diagram
is also helpful in analyzing risk-taking
scenarios enabled on specific risks whose
quantitative analysis highlights possible
benefits greater than corresponding
identified negative impacts. A tornado
diagram is a special type of bar chart used
in sensitivity analysis for comparing the
relative importance of the variables. In a
tornado diagram, the Y-axis contains each
type of uncertainty at base values, and the
X-axis contains the spread or correlation of
the uncertainty to the studied impact
(2.2) Expected Monetary Value (EMV)
Analysis (Decision Tree Analysis): is a
statistical concept that calculates the
average outcome when the future includes
scenarios that may or may not happen (i.e.
analysis under uncertainty). The EMV of
opportunities are generally expressed as
positive values, while those of threats are
expressed as negative values. EMV requires
a risk-neutral assumption – neither risk
averse nor risk seeking. EMV for a project is
calculated by multiplying the value of each
possible outcome by its probability of
occurrence and adding the products
together. A common use of this type of
analysis is a decision tree analysis
(2.3) Modeling and Simulation (Monte Carlo
Technique): A project simulation uses a
model that translates the specified detailed
uncertainties of the project into their
potential impact on project objectives.
Simulations are typically performed using
the Monte Carlo techniques. In a simulation,
the project model is computed many times
(iterated), with the input values (e.g cost
estimates, or activity durations) chosen at
random for each iteration from the
probability distributions of these variables. A
histogram (e.g. total cost, or completion
date) is calculated from the iterations. For a
cost risk-analysis, a simulation uses cost
estimates. For a schedule risk analysis, the

of 61
schedule network diagram and duration
estimates are used.
(3) Expert Judgment
11.5 Plan Risk Responses
It is the process of developing options and actions to enhance
opportunities and to reduce threats to project objectives
Benefits: It addresses the risks by their priority, inserting resources
and activities into the budget, schedule, and project management
plan as needed.
The plan risk responses process follows the perform quantitative risk
analysis process (if used). Each risk response requires an
understanding of the mechanism by which it will address the risk.
This is the mechanism used to analyze if the risk response plan is
having the desired effect. It includes identification and assignment of
one person (an owner for risk response) to take responsibility for
each agreed-to and funded risk response. Risk responses should be
appropriate for significance of the risk, cost-effective in meeting the
challenge, realistic within the project context, agreed upon by all
parties involved and owned by responsible person. Selecting the
optimum risk response from several options is often required.
The plan risk responses process presents commonly used approaches
to planning responses to the risks. Risks include threats and
opportunities that can affect project success, and responses are
discussed for each.
(1.1) Roles and Responsibilities
(1.2) Risk Analysis Definitions
(1.3) Timing for reviews (and for eliminating
risks from reviews)
(1.4) Risk Thresholds for low, moderate and
high risks. Risk thresholds help identify those
risks for which specific responses are needed
(2) Risk Register
(2.1) Identified risks
(2.2) Root causes of risks
(2.3) List of potential responses
(2.4) Risk owners
(2.5) Symptoms and Warning signs
(2.7) The relative rating or priority list of project
risks
(2.8) Risk requiring responses in the near term
(2.9) Risk for additional analysis and response
(2.10) Trends in quantitative analysis results
(2.11) Watch List, which is a list of low priority
risks within the risk register.
Several risk response strategies are
available. The strategy or mix of strategies
most likely to be effective should be
selected for each risk. Risk analysis tools,
such as decision tree analysis, can be used
to choose the most appropriate responses.
Specific actions are developed to implement
that strategy, including primary and back up
strategies, as necessary. A fall back plan
can be developed for implementation if the
selected strategy turn out not to be fully
effective or if an accepted risk occurs
secondary risks should be reviewed.
Secondary risks are risks that arise as a
direct result of implementation of a risk
response. A contiwngency reserve is often
allocated for time or cost. If developed, it
may include identification of conditions that
trigger its use.
(1) Strategies for Negative Risks or Threats:
3 strategies, which typically deal with
threats or risks that may have negative
impacts on project objectives if they occur,
are: avoid, transfer, and mitigate. The
fourth strategy, accept can be used for
negative risks or threats as well as positive
risks or opportunities. Avoidance and
Mitigation are usually good strategies for
critical risks with high impact, while
transference and acceptance are usually
good strategies for threats that are less
critical and with low overall impact.
(1.1) Avoid: Risk avoidance is a risk
response strategy where by the project
team acts to eliminate the threat or protect
the project from its impact. It usually
involves changing the project management
plan to eliminate the threat entirely. The
project manager may also isolate the
project objectives from the risk’s impact or
change the objective that is in jeopardy.
Examples of this include extending the
schedule, changing the strategy, or
reducing scope. The most radical avoidance
strategy is to shut down the project
entirely. Some risks that arise early in the
project can be avoided by clarifying
requirements, obtaining information,
improving communication, or acquiring
expertise.
(1.2) Mitigate: Risk mitigation is a risk
response strategy whereby the project team
acts to reduce the probability of occurrence
or impact of a risk. It implies a reduction in
the probability and / or impact of an
adverse risk to be within acceptable
threshold limits. Taking early action to
reduce the probability and / or impact of a
risk occurring on the project is often more
effective than trying to repair the damage
after the risk has occurred. Adopting less
(1.8) Cost Baseline
(2) Project Documents Updates: When appropriate risk
responses are chosen and agreed upon, they are included
in the risk register. The risk register should be written to a
level of detail that corresponds with the priority ranking
and the planned responses often, the high and moderate
risk are addressed in detail. Risks judged to be of low
priority are included in a watch list for periodic monitoring.
Updates to the risk register can include,
(2.1) Risk Register
(A) Risk owners and assigned responsibilities
(B) Agreed upon response strategies
(C) Specific actions to implement chosen response
strategy
(D) Trigger conditions, symptoms, and warning signs
of a risk occurrence
(E) Budget and schedule activities required to
implement the chosen responses
(F) Contingency plans and triggers that calls for their
execution
(G) Fallback plans for use as a reaction to a risk that
has occurred & the primary response proves to be
inadequate
(H) Residual risks that are expected to remain after
planned responses have been taken, as well as
those that have been deliberately accepted
(I) Secondary risks that arise as a direct outcome of
implementing a risk response
(J) Contingency reserves that are calculated based on
the quantitative risk analysis of the project & the
organizations risk thresholds.
(2.2) Assumptions log updates: As new information
becomes available through the application of risk
responses, assumptions could change. The assumptions
log needs to be revisited to accommodate this new
information
(2.3) Technical Documentation Updates
(2.4) Change Requests

of 61
complex processes, conducting more tests,
or choosing a more stable supplier are
examples of mitigation actions. Mitigation
my require prototype development to
reduce the risk of scaling up from a bench-
scale model of a process or product. Where
it is not possible to reduce probability, a
mitigation responses might address the risk
impact by targeting linkages that determine
the severity. For e.g. designing redundancy
into a system may reduce the impact from a
failure of the original equipment.
(1.3) Transfer: Risk transference is a risk
response strategy where by the project
team shifts the impact of a threat to a third
party, together with ownership of the
response. Transferring the risk simply gives
another party responsibility for its
management – it does not eliminate it.
Transferring does not mean disowning the
risk by transferring it to a later project or
other person without his or her knowledge
or agreement. Risk transference nearly
always involves a risk premium to the party
taking on the risk. Transferring liability for
risk is most effective in dealing with
financial exposure. Transference tool can be
quite diverse and include the use of
insurance, performance bonds, warranties,
guaranties etc. Contracts or agreements
may be used to transfer liability for
specified risks to other party. For e.g when
a buyer has capabilities that the seller does
not possess, it may be prudent to transfer
some work and its concurrent risk
contractually back to the buyer. In many
cases, use of cost-plus contract may
transfer the cost risk to the buyer, while a
fixed-price contract may transfer risk to the
seller.
(1.4) Accept: Risk acceptance is a risk
response strategy whereby the project team
decides to acknowledge the risk and not
take any action unless the risk occurs. This
strategy is adopted where it is not possible
or cost-effective to address a specific risk in
any other way. This strategy indicates that
the project team has decided not to change
the project management plan to deal with a
risk, or is unable to identify any other
suitable response strategy. This strategy
can be either passive or active. Passive
acceptance requires no action except to
document the strategy, leaving the project
team to deal with the risks as they occur,
and to periodically review the threat to
ensure that it does not change significantly.
The most common active acceptance
strategy is to establish a contingency
reserve, including amounts of time, money,
or resources to handle the risks.
(2) Strategies for Positive Risks or
Opportunities: 3 of the 4 responses
suggested to deal with risks potentially
Project Information
Data: Throughout the lifecycle of the project, a significant amount of data and information is collected, analysed, transformed and distributed
in various formats to project team members and other stakeholders. Project data are collected as a result of various executing processes and
are shared with the project team.
Information: The collected data are analysed in context, and aggregated and transformed to become project information during various
controlling processes
Reports: The information may then be communicated verbally or stored and distributed as reports in various formats
Work Performance Data: The raw observations and measurements identified during activities performed to carry out the project work. Eg
include reported % of work physically completed, quality and technical performance measures, start and finish dates of schedule activities, no
of change requests, no of defects, actual costs, actual durations, etc
Work Performance Information: The performance data collected from various controlling processes analysed in context and integrated
based on relationships across areas. Eg: status of deliverables, implementation status for change requests and forecasted estimates to
complete.
Work Performance Reports: The physical or electronic representation of work performance information compiled in project documents,
intended to generate decisions or raise issues, actions or awareness. Eg status reports, memos, justifications, information notes, electronic
dash boards, recommendations, and updates.
Enterprise Environmental Factors: Refers to conditions not under the control of the project team, that influence, constraints, or direct
the project.
1. Organizational culture, structure and governance
2. Geographical distribution of facilities and resources
3. Government and industry standards (e.g. regulatory agency regulations, codes of conduct, product standard, quality standards and
workmanship standards)
4. Infrastructure (existing facilities and capital equipment)
5. Existing human resources (e.g. skills, disciplines, and knowledge, such as design development, legal, contracting, purchasing)
6. Personnel administration (e.g. staffing and retention guidelines, employee performance reviews and training records, rewards and
overtime policy, and time tracking)
7. Company work authorization system
8. Market place conditions
9. Stakeholder risk tolerances
10. Political climate
11. Organizational established communication channels
12. Commercial databases (e.g. standard costing estimates data, industry risk study information, risk databases)
13. Project Management Information Systems (scheduling software tool, configuration management system, info collection and distribution

of 61
positive impact on project objectives are
exploit, enhance and share. The 4th
strategy, accept; can be used for negative
risks or threats as well as positive risks or
opportunities.
(2.1) Exploit: The exploit strategy may be
selected for risks with positive impacts
where the organizations wishes to ensure
that the opportunity is realized. This
strategy seeks to eliminate the uncertainty
associated with a particular upside risk by
ensuring the opportunity definitely happens.
E.g. of directly exploiting responses include
assigning an organization’s most talented
resources to the project to reduce the time
to completion or using new technologies or
technology upgrades to reduce cost and
duration required to realize project
activities.
(2.2) Enhance: The enhance strategy is
used to increase the probability and / or the
positive impacts of an opportunity.
Identifying and maximizing key drivers of
these positive – impact risks may increase
the probability of their occurrence. E.g. Of
enhancing opportunities include adding
more resources to an activity to finish early.
(2.3) Share: Sharing a positive risk involves
allocating some or all of the ownership of
the opportunity to a third party who is best
able to capture the opportunity for the
benefit of the project. E.g. of sharing
actions include forming risk-sharing
partnerships, team, special purpose
companies, or joint ventures. Which can be
established with the express purpose of
taking advantage of the opportunity so that
all parties gain from their actions
(2.4) Accept: Accepting an opportunity is
being willing to take advantage of the
opportunity if it arises, but not actively
pursuing it.
(3) Contingent Response Strategies: Some
responses are designed for use only if
certain events occur. For some risks, it is
appropriate for the project team to make a
response plan that will only be executed
under certain predefined conditions, if it is
believed that there will be sufficient warning
to implement the plan. Events that trigger
the contingency response, such as missing
intermediate milestones or gaining higher
priority with a supplier should be defined
and tracked. Risk responses identified using
this technique are often called contingency
plan or fall back plans and include identified
triggering events that set the plans in effect
(4) Expert Judgment
Process Group:
11.6 Control Risks
(2) Risk Register
(1) Risk Reassessment: Control risks often
results in identification of new risks,
reassessment of current risks, and closing
of the risks that are outdated. Project risk
reassessment should be regularly
(2) Change Requests: Implementing contingency plans or
workarounds sometimes result in a change requests.
Change requests are prepared and submitted to the PICC
Organizational Process Assets: Plans, processes, policies, procedures, and knowledge bases specific to and used by the performing
organization. OPA may be grouped as under
1. Processes & Procedures
1.1. Initiating and Planning:
1.1.1. Guidelines and criteria for tailoring the organizational set of standard processes and procedures to satisfy the specific needs
to the project
1.1.2. Specific organizational standards such as policies (e.g. human resource policy, health and safety policies, and project
management policies and procedures), product and project life cycles, and quality policies and procedures (e.g. process
audits, improvement targets, and standardized process definitions for use in the organization
1.1.3. Templates (e.g. risk register, work breakdown structure, project schedule network diagram and control templates)
1.2. Executing, Monitoring & Controlling
1.2.1. Change control procedures, including the steps by which performing organizations standards, policies, plans, and procedures
or any project document will be modified, and how any change will be approved and validated.
1.2.2. Financial controls procedures (e.g. time reporting, required expenditure and disbursement reviews, accounting codes, and
standard contact provisions)
1.2.3. Issues and defect management procedures defining issue and defect controls, issue and defect identification and resolution,
and action item tracking
1.2.4. Organizational communication requirements (e.g. specific communication technology available, authorized communication
media, record retention policies, and security requirements)
1.2.5. Procedures for prioritizing, approving, and issuing work authorizations
1.2.6. Risk control procedures, including risk categories, risk statement templates, probability and impact definitions, and probability
and impact matrix
1.2.7. Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria.
1.3. Closing
1.3.1. Project closure guidelines or requirements (e.g. lessons learned, final project audits, project evaluations, product validations
and acceptance criteria
2. Corporate Knowledge base
2.1. Configuration management knowledge bases containing the versions and baselines of all performing organization standards, policies
and procedures and project documents
2.2. Financial databases containing information such as labour hrs, incurred costs, budgets, and any project cost overruns.
2.3. Historical information and lessons learned knowledge bases. (e.g. project records and documents, all project closure information,
and documentation, information regarding both the results of previous project selection decisions and previous project performance
information, and information form risk management activities
2.4. Issues and defect management databases containing issue and defect status, control information, issue and defect resolution, and
action item results.
2.5. Process measurement databases used to collect and make available measurement data on process and products
2.6. Project files from previous projects (e.g. scope, cost, schedule, and performance measurement baselines, project calendars, project
schedule, network diagram, risk registers, planned response actions, and defined risk impact.

of 61
It is the process of implementing the risk response plans, tracking
identified risks, monitoring residual risks, identifying new risks, and
evaluating risk process effectiveness throughout the project.
Benefits: It improves efficiency of the risk approach throughout the
project life cycle to continuously optimize risk responses.
Planned risk responses that are included in the risk register are
executed during the life cycle of the project, but the project work
should be continuously monitored for new, changing and outdated
risks.
The control risks process applies techniques, such as variance and
trend analysis, which require the use of performance information
generated during project execution. Other purposes of the control
risks process are to determine if
(1) Project assumptions are still valid
(2) Analysis shows an assessed risk has changed or can be retired
(3) Risk Management policies and procedures are being followed
(4) Contingency reserves for cost or schedule should be modified in
alignment with the current risk assessment.
Control risks can involve choosing alternative strategies, executing a
contingency or fall back plan, tacking corrective action, and
modifying the project management plan. The risk response owner
reports periodically to the project manager on the effectiveness of
the plan, any unanticipated effects, an any correction needed to
handle the risk appropriately. Control risks also includes updating the
organization process assets, including project lessons learned
databases and risk management templates, for the benefit of future
projects.
(3.1) Deliverable Status
(3.3) Costs incurred
scheduled. The amount and detail of
repletion that are appropriate depends on
how the project progress relative to its
objectives.
(2) Risk Audits: risk audits examine and
document the effectiveness of risk
responses in dealing with identified risks
and their root causes, as well as
effectiveness of the risk management
process. The project manager is responsible
for ensuring that the risk audits are
performed at an appropriate frequency, as
defined in the project’s risk management
plan. Risk audits may be included during
routine project review meetings, or the
team may choose to hold spate risk audit
meetings. The format of the audit and its
objectives should be clearly defined before
the audit is conducted.
(3) Variance & Trend Analysis: For the
purpose of controlling risks, trends in the
project’s execution should be reviewed
using performance information. Earned
value analysis and other methods of project
variance and trend analysis may be used for
monitoring overall project performance.
Outcomes from these analyses may forecast
potential deviation of the project at
completion from cost and schedule targets.
Deviation from the baseline plan may
indicate potential impacts of threats or
opportunities.
(4) Technical Performance Measurement:
Compares technical accomplishments during
project execution to the schedule opf
technical achievement. It requires the
definition of objective, quantifiable,
measures of technical performance, which
can be used to compare actual results
against targets. Deviation such as
demonstrating more or less functionality
than planned at a milestone, can help to
forecast the degree of success in achieving
the project’s scope.
(5) Reserve Analysis: Throughout execution
of the project, some risks may occur with
positive or negative impacts on budget or
schedule contingency reserve. Reserve
analysis compares the amount of the
contingency reserves remaining to the
amount of risk remaining at any time in the
project in order to determine if the
remaining reserve is adequate
(6) Meetings
process and can include.
(2.1) Recommended Corrective Action: These are activities
that realign the performance of the project work with the
project management plan. They include contingency plans
and workarounds. The latter are responses that were not
initially planned, but are required to deal with emerging
risks that were previously unidentified or accepted
passively.
(2.2) Recommended Preventive Action: These are
activities that ensure that the future performance of the
project work is aligned with the project management plan.
(3) Project Management Plan Updates: The elements of
the project management plan that may be updated are
the same as those in the Plan Risk Responses Process
(4.1) Risk register
(A) Outcome of risk reassessments, risk audits, &
periodic risk reviews: These outcomes may
include identification of new risks, updates to
probability, impact, priority, response plans,
ownership and other elements of the risk register.
Outcomes can also include closing risks that are
no longer applicable and releasing their associated
reserves.
(B) Actual outcomes of the project’s risk & of the risk
responses: This information can help project
managers to plan for risk throughout their
organization’s as well as on future projects.
(5.1) Templates for the risk management plan, including
the probability and impact matrix and risk register
(5.2) Risk Breakdown structure
(5.3) Lessons learned form the project risk management
activities
Procurement
Management
necessary to purchase
or acquire products,
Process Group:
12.1 Plan Procurement Management
(1.1) Project scope statement
(1.2) WBS
(1.3) WBS dictionary
(1) Make-or-Buy Analysis: A general
management technique used to determine
whether particular work can best be
accomplished by the project team or should
be purchased from outside sources.
Sometimes a capability may exist within the
(1) Procurement Management Plan
(1.1) Types of contract to be used
(1.2) Risk Management Issues
(1.3) Whether independent estimates will used & whether
they are needed as evaluation criteria
(1.4) Those actions the project team can take unilaterally,

of 61
services, or results
needed from outside
the project team. The
organization can be
either the buyer or
seller of the products,
services, or results of a
project. It includes the
contract management
And change control
processes required to
develop and
administer contracts or
purchase orders issued
by authorized project
team members. It also
includes controlling
any contract issued by
an outside
organization (the
buyer) that is
acquiring deliverables
form the project from
the performing
organization (the
seller) and
administering
contractual obligations
placed on the project
team by the contract.
The project
procurement
management
processes involve
agreements, including
contracts, which are
legal documents
between a buyer and a
seller. A contract
represent a mutually
binding agreement
that obligates the
seller to provide
something of value
(eg. Specified
products, services, or
results) and obligates
the buyer to provide
monetary or other
valuable
compensation. An
agreement can be
simple or complex, and
may reflect the
simplicity or
complexity of the
deliverables or
required effort.
A procurement
contract includes
terms and conditions,
and may incorporate
other items that the
It is the process of documenting project procurement decisions,
specifying the approach, and identifying the potential sellers.
Benefits: It determines whether to acquire outside support, and if
so, how to acquire it, how much is needed, and when to acquire it
Plan procurement management identifies those project needs that
can best be met or should be met by acquiring products, services or
results outside of the project versus those project needs which can
be accomplished by the project team. When the project obtains
products, services, and results required for project performance from
outside of the performing organization, the processes form plan
procurement management through close procurements are
performed for each item to be acquired.
The plan procurement processes also includes evaluating potential
sellers, particularly if the buyer wishes to exercise some degree of
influence or control over acquisition decisions. Thought should also
be given to who is responsible for obtaining or holding any relevant
permits and professional licenses that may be required by legislation,
regulation, or organizational policy in executing the project.
The requirements of the project schedule can significantly influence
the strategy during the plan procurement management processes.
Decisions made in developing the procurement management plan
can also influence the project schedule and are integrated with
develop schedule, estimate activity resources, and make-or-buy
analysis.
The plan procurement management process include evaluating the
risks involved with each make-orbuy analysis. It is also includes
reviewing the type of contract planned to be sued with respect to
avoiding or mitigating risks, sometimes transferring risks to the
seller.
(3) Risk Register
(5) Project Schedule
(8.1) Market place conditions
(8.2) Products, services, and results that are
available in the market place
(8.3) Suppliers, including past performance or
reputation
(8.4) Typical terms and conditions for products,
services, and results or for the specific industry
(8.5) Unique local requirements
(9.1) Formal procurement policies, procedures,
and guidelines
(9.2) Management systems that are considered
in developing the procurement management
plan and selecting contractual relationship to be
used
(9.3) An established multi-tier supplier system
of prequalified sellers based on prior
experience.
A legal contractual relationships generally fall
into one of two board families: either fixed-price
or cost reimbursable. Also, there is a third
hybrid type commonly in use called the time
and material contract. In practice it is not
unusual to combine one or more types into a
single procurement
(9.1) Fixed Price Contracts: This category of
contracts involves setting a fixed total price for
a defined product, service or result to be
provided. Fixed price contracts may also
incorporate financial incentives for achieving or
exceeding selected project objectives, such as
schedule delivery dates, cost and technical
performance or anything that can be quantified
and subsequently measured. Sellers under
fixed-price contracts are legally obligated to
complete such contracts, with possible financial
damages if they do not. Under the fixed price
arrangement, buyers need to precisely specify
the product or services being produced.
Changes in scope may be accommodated, but
generally with an increase in contract price.
(A) Firm Fixed Price Contracts (FFP): The
price for goods is set at the outset and
not subject to change unless the scope
of work changes. Any cost increase due
to adverse performance is the
responsibility of the seller, who is
obligated to complete the effort. Under
the FFP contract buyer should precisely
specify the products / services to be
procured, and any changes to the
procurement specification can increase
project organization, but may be committed
to working on other projects, in which case,
the project may be needed to sources such
effort from outside the organization in order
to meet tis schedule commitments.
Budget constraints may influence make-or-
buy decisions. If a buy decision is to be
made, then a further decision of whether to
purchase or lease is also made. A make-or-
buy analysis should consider all related
costs-both direct costs as well as indirect
support costs. For e.g. the buy side of the
analysis includes both the actual out-of-
pocket costs to purchase the product, as
well as indirect costs of supporting the
purchasing process and purchased item.
Available contract types are also considered
during the buy analysis. The risk sharing
between the buyer and the seller
determines the suitable contract types,
while the specific contract terms and
conditions formalize the degree of risk being
assumed by the buyer and the seller. Some
jurisdictions have other types of contracts
defined, for eg contract types based on the
obligations of the seller-not the customer –
and the contract parties have the
obligations to identify the appropriate type
of contract as soon as the applicable law
has been agreed upon.
(2) Expert Judgment: is often used to
assess the inputs to and outputs from this
process. Expert purchasing judgment can
also be used to develop or modify the
criteria that will be used to evaluate seller
proposals. Expert legal judgment may
involve the services of legal staff to assist
with unique procurement issues, terms and
conditions. Such judgment, including
business and technical expertise, can be
applied to both the technical details of the
acquired products, services, or results and
to various aspects of the procurement
management processes.
(3) Market Research: includes examination
of industry and specific vendor capabilities.
Procurement teams may leverage
information gained at conferences, online
reviews and variety of sources to identify
market capabilities. The team may also
refine particular procurement objectives to
leverage maturing technologies while
balancing risks associated with the breadth
of vendors who can provide the materials or
services desired.[
(4) Meetings
if the performing organization has a prescribed
procurement, contracting, or purchasing department
(1.5) Standardized procurement documents, if needed
(1.6) Managing multiple suppliers
(1.7) Coordinating procurement with other project aspects
such as scheduling & performance reporting
(1.8) Any constraints & assumptions that could affect
planned procurements
(1.9) Handling the long lead items to purchase certain
items from sellers & coordinating the extra time needed to
procure these items with the development of the project
schedule
(1.10) Handling the make-or-buy decisions & linking then
into the estimate activity resources & develop schedule
processes.
(1.11) Setting the schedule dates in each contract for the
deliverables & coordinating with the schedule
development and control processes
(1.12) Identifying requirements for performance bonds or
insurance contracts to mitigate some forms of project risk
(1.13) Establishing the direction to be provided to the
sellers on developing & maintaining a WBS.
(1.14) Establishing the form & format to be used for the
procurement / contract statement of work
(1.15) Identifying pre-qualified sellers, if any to be used
(1.16) Procurement metrics to be used to manage
contracts and evaluate sellers
(2) Procurement Statement of Work (SOW): for each
procurement is developed form the project scope baseline
and defines only that portion of the project scope that is
to be included within the related contract. The
procurement SOW describes the procurement item in
sufficient detail to allow prospective sellers to determine if
they are capable of providing the products, services or
results. Sufficient detail can vary based on the nature of
the item, the needs of the buyer, or the expected contract
form. The procurement SOW is written to be clear,
complete, and concise. In some application areas, there
are specific content and format requirements for a
procurement SOW. Each individual item requires SOW;
however, multiple products or services can be grouped as
one procurement items within a single SOW. The
procurement SOW can be revised and refined as required
as it moves through the procurement process until
incorporated into a signed agreement. Information
included in a SOW can include,
(2.1) Specifications
(2.2) Quantity Desired
(2.3) Quality Levels
(2.4) Performance Data
(2.5) Period of performance
(2.6) Work Location
(2.7) Other requirements
(2.8) Collateral services required
• Performance Reporting
• Post-project operational support
(3) Procurement Documents: are used to solicit proposals
from prospective sellers.
(3.1) Bid / Quotation / Tender : When seller selection
decision is based on price i.e buying commercial or
standard items
(3.2) Proposal: When seller selection decision is based on
technical capability or technical approach.

of 61
buyer specifies as to
what the seller is to
perform or provide. It
is the project
management team’s
responsibility to make
certain that all
procurements meet
the specific needs of
the project while
adhering to
organization
procurement policies.
Depending upon the
application area, a
contract can also be
called an agreement,
an understanding, a
subcontract, or a
purchase order. Most
organizations
document policies and
procedures specifically
defining the
procurement rules and
specifying who has
authority to sign and
administer such
agreements on behalf
of the organization.
Although all project
documents may be
subject to some form
of review and
approval, the legally
binding nature of a
contract or agreement
usually means it will be
subject to more
extensive approval
process. In all cases,
the primary focus of
the review and
approval process is to
ensure that the
contract language
describes the products,
services, or results,
that will satisfy the
identified project need.
The project
management team
may seek support in
early phases from
specialists in
contracting,
purchasing, law, and
technical disciplines.
Such involvement can
be mandated by an
organization’s policies.
The various activities
the cost to the buyer.
(B) Fixed Price Incentive Fee Contracts
(FPIF): Gives the buyer and seller some
flexibility in that it allows for deviation
from performance, with financial
incentives tied to achieving agreed
upon metrics. Typically such financial
incentives are related to cost, schedule,
or technical performance to the seller.
Performance targets are established at
the outset and final contract price is
determined after completion of all work
based on seller’s performance. A price
ceiling is set and all cost above the
price ceiling is the seller’s responsibility,
who is obligated to complete the work
(C) Fixed Price with Economic Price
Adjustments Contracts (FP-EPA): Used
whenever seller’s performance period
spans a considerable period of years. It
is a fixed-price contract, but with
special proviso for pre-defined final
adjustments to the contract price due to
changed conditions, such as inflation
changes, cost increase (or decrease) for
specific commodities. EPA clause relates
to some reliable financial index which is
used to precisely adjust the final price.
The FP-EPA is intended to protect both
buyer and seller from external
conditions beyond their control
(9.2) Cost Reimbursable Contracts: This
category of contract involves payments (cost
reimbursements) to the seller for all legitimate
actual costs incurred for completed work, plus a
fee representing seller profit. Cost reimbursable
contracts may also include financial incentive
clause whenever the seller exceeds or falls
below defined objectives such as costs,
schedule or technical performance target. A cost
–reimbursable contract provides flexibility to
redirect a seller whenever the scope of work
cannot be precisely defined at the start & needs
to be altered, or when high risk may exists in
the effort
(A) Cost Plus Fixed Fee Contracts (CPFF):
The seller is reimbursed for all allowable
costs for performing the contract work
and receives a fixed fee calculated as a
% of initial project cost. A fee is paid
for completed work & does not change
due seller performance. Fee amounts
do not change unless scope changes
(B) Cost Plus Incentive Fee Contracts
(CPIF): The seller is reimbursed for all
allowable costs for performing the
contract work, and receives a pre-
determined incentive fee based upon
achieving certain performance
objectives as set forth in the contract.
In CPIF contracts, if the final costs are
less or greater than the original
estimated costs, then both the buyer
and the seller share costs from the
Common terms are in use for different types of
procurement documents and may include,
(3.3) Request for Information (RFI)
(3.4) Invitation for Bid (IFB)
(3.5) Request for Proposal (RFP)
(3.6) Request for Quotation (RFQ)
(3.7) Tender Notice
(3.8) Invitation for Negotiation
(3.9) Invitation for sellers initial response
The buyer structures procurement docs to facilitate an
accurate & complete response from each prospective
seller and to facilitate easy evaluation of the responses.
These documents include a description of the desired form
of the response, the relevant procurement statement of
work and any required contractual provisions. With
government contracting, some or all of the content and
structure of procurement documents may be defined by
regulation.
The complexity & level of detail of procurement docs
should be consistent with the value of & risks associated
with planned procurements. Procurement documents are
required to be sufficient to ensure consistent, appropriate
responses, but flexible enough to allow consideration of
any seller suggestions for better ways to satisfy the same
requirement
Issuing a procurement request to potential sellers to
submit a proposal or bid is normally done in accordance
with the policies of the buyer organization, which can
include publication of the request in public newspaper, in
trade journals, in public registers, or on the internet.
(4) Source selection criteria: are often included as a part
of procurement documents. Such criteria are developed
and used to rate or score seller proposals, and can be
objective or subjective.
Selection criteria may be limited to only the purchase price
if the procurement item is readily available from a number
of sellers. Purchase price in this context includes both the
cost of the item and all ancillary expenses such as
delivery.
Other selection criteria can be identified and documented
to support an assessment for more complex products,
services, or results. Some possible source selection criteria
are:
(4.1) Understanding of need
(4.2) Overall or life-cycle cost
(4.3) Technical Capability
(4.4) Risk
(4.5) Management approach
(4.6) Technical Approach
(4.7) Warranty
(4.8) Financial Capacity
(4.9) Production capacity and interest
(4.10) Business size & type
(4.11) Past performance of sellers
(4.12) References
(4.13) Intellectual property rights
(4.14) Proprietary rights
(5) Make-or-Buy Decisions

of 61
involved in the project
procurement processes
from the life cycle of
an agreement. By
actively managing the
agreement life cycle
and carefully wording
the terms and
conditions of a
procurement, some
identifiable risks may
be shared or
transferred to the
seller. Entering into an
agreement for
products or services is
one method of
allocating the
responsibility for
managing or sharing
potential risks.
A complex project may
involve managing
multiple contracts or
subcontracts
simultaneously or in
sequence. In such
cases, each contract
life cycle may end
during any phase of
the project life cycle.
Project Procurement
Management is
discussed within the
perspective of the
buyer-seller
relationship. The
buyer-seller
relationship may exists
at many levels on any
one project, and
between organizations
internal to and
external to the
acquiring
organizations.
Depending on the
application area, the
seller may be identified
as a contractor,
subcontractor, vendor,
service provider, or
supplier. Depending on
the buyer’s position in
the project acquisition
cycle, the buyer may
be called a client,
customer, prime
contractor, contractor,
acquiring organization,
service requestor, or
purchaser. The seller
can be viewed during
departures based on a pre-negotiated
formula, for eg. 80/20 split over/under
target costs based on the actual
performance of the seller.
(C) Cost Plus Award Fee Contracts (CPAF):
The seller is reimbursed all legitimate
costs, but the majority of the fee is
earned only on the satisfaction of
certain broad subjective performance
criteria defined and incorporated into
the contract. The determination of the
fee is based solely on the subjective
determination of seller performance by
the buyer and is not subjected to
appeals
(9.3) Time and Material Contracts: These
contracts are hybrid type of contractual
arrangement that contain aspects of both cost-
reimbursable & fixed-price contracts. They are
often used for staff augmentation, acquisition of
experts, and any outside support when a
precise statement of work cannot be quickly
prescribed. These types of contracts resemble
cost-reimbursable contracts in that they can be
left open ended and may be subject to a cost
increase for the buyer. The full value of the
agreement and the exact quantities of items
need not be defined by the buyer at the time of
contract award. Thus T&M contracts can
increase in contract value as if they were cost-
reimbursable contracts. Many organizations
require not-to-exceed values and time limits
placed to prevent unlimited cost growth.
Conversely, T&M contracts can also resemble
fixed unit price arrangements when certain
parameters are specified in the contract. Unit
labor, or material rates can be preset by the
buyer and seller, including seller profit, when
both parties agree on the values for specific
resources categories such as senior engineer at
specified rate per hour or categories of material
at specified rates per unit.
(6) Change Requests
(7.3) Risk Register.
12.2 Conduct Procurements
It is the process of obtaining seller responses, selecting a seller, and
awarding a contract.
Benefits: It provides alignment of internal and external stakeholder
expectations through established agreements
During the conduct procurement processes, the team will receive
bids for proposals and will apply previously defined selection criteria
to select one or more seller who are qualified to perform the work
and acceptable as a seller.
On major procurement items, the overall process of requesting
responses from sellers and evaluating those responses can be
repeated. A short list of qualified sellers can be established based on
a preliminary proposal. A more detailed evaluation can then be
conducted based on a more specific and comprehensive
requirements document requested from the seller on the short list.
In addition, tools and techniques described here may be used alone
(2) Procurement Documents,
(3) Source selection criteria
(4) Seller Proposals
(6) Make-or-buy Decisions: Factors that
influence make-or-buy decisions include
(6.1) Core capabilities of the organization
(6.2) Value delivered by the vendors meeting
the need
(6.3) Risks associated with meeting the need in
a cost-effective manner
(6.4) Capability internally compared with the
vendor community
(7) Procurement Statement of Work
(7.1) Specifications
(1) Bidder Conferences: Sometimes called
contractor conferences, vendor
conferences, and pre-bid conferences, are
meetings between the buyer and all
prospective sellers prior to submittal of a
bid or proposal. They are used to ensure
that all prospective sellers have a clear and
common understanding of the procurement
requirements, and that no bidder receives
preferential treatment. To be fair, buyers
should take great care to ensure that all
prospective sellers hear every question form
the buyer. Typical fairness is addressed by
techniques such as collecting questions
from bidders or arranging field visits in
advance of the bidder conference.
Responses to question can be incorporated
into the procurement documents as
amendments.
(2) Proposal Evaluation Techniques
(2.1) Weighting Systems
(1) Selected Sellers: The selected sellers are those who
have been judged to be in a competitive range based
upon the outcome of the proposal or bid evaluation, and
who negotiated a draft contract that will become the
actual contract when an award is made. Final approval of
all complex, high-value, high-risk, procurements will
generally require organizational senior management
approval prior to award.
(2) Agreements: A procurement agreements includes
terms and conditions, and may incorporate other items
that the buyer specifies regarding what the seller is to
perform or provide. It is the project management team’s
responsibility to make certain that all agreements meet
the specific needs of the project while adhering to
organizational procurement policies. Depending upon the
application area, an agreement can also be called an
understanding, a contract, a subcontract, or a purchase
order. Regardless of the document’s complexity a contract
is a mutually binding legal agreement that obligates the
seller to provide the specified products, services, or
results, and obligates the buyer to compensate the seller.

of 61
the contract life cycle
first as bidder, then as
the selected source,
and then as the
contracted supplier or
vendor.
The seller will typically
manage the work as a
project if the
acquisition is not just
for helf material,
goods, or common
products. In such case
(1) The buyer
becomes the
customer, and is thus
a key project
stakeholder for the
seller
(2) The seller’s project
management team is
concerned with all the
processes of project
management, not only
with those of this
knowledge area
(3) Terms and
conditions of the
contract become key
inputs to many of the
seller’s management
processes. The
contract can actually
contain the inputs (eg
major deliverables, key
milestones, cost
objectives) or it can
limit the project’s
team’s options (eg
buyers approval of
staffing decisions is
often required on
design projects)
In this section, it is
assumed that the
buyer of an item for
the project is assigned
to the project team
and that the seller is
organizationally
external to the project
team. It is also
assumed that a formal
contractual
relationship will be
developed and exisits
between the buyer and
the seller. However,
most of the
discussions in this
or in combination to select sellers. For eg. A weighting system can be
used to
(1) Select a seller that will be asked to sign a standard contract
(2) Establishing a negotiating sequence by ranking all proposals by
weighted evaluation scores assigned to each proposal.
(7.2) Quantity desired
(7.3) Quality Levels
(7.4) Performance Data
(7.5) Period of Performance
(7.6) Work location
(7.7) Other requirements
(8.1) Listing of prospective and previously
qualified sellers
(8.2) Information on relevant past experience
with sellers both good and bad,
(8.3) Prior agreements: Whenever a prior
agreement is in place, the buyer and seller roles
will have already been decided by executive
management. In some cases, the seller may
already be working under a contract funded by
the buyer or jointly by both parties. The effort
of the buyer and seller in this process is to
collectively prepare a procurement statement of
work that will satisfy the requirements of the
project. The parties will then negotiate a final
contract for award.
(2.2) Screening Systems
(2.3) Past Performance History
(2.4) Presentations
(3) Independent Estimates: For many
procurement items, the procuring
organization may elect to either prepare its
own independent estimate, or have an
estimate of costs prepared by an outside
professional estimator, to serve as a
benchmark on proposed responses.
Significant differences in cost estimates can
be an indication that the procurement
statement of work was deficient, ambiguous
, and/or that the prospective sellers either
misunderstood or failed to respond fully to
the procurement statement of work
(4) Expert Judgment
(5) Advertising
(6) Analytical Techniques:
(7) Procurement Negotiations: Clarify the
structure, requirements, and other terms of
the purchaser so that mutual agreement
can be reached prior to signing the
contract. Final contract language reflects all
agreements reached. Subjects covered
should include responsibilities, authority to
make changes, applicable terms and
governing law, technical and business
management approaches, proprietary
rights, contract financing, technical
solutions, overall schedule, payment and
price. Negotiations conclude with a contract
document that can be executed by both
buyer and seller.
For complex procurement items, contract
negotiation can be an independent process
with inputs (e.g issues or an open items
listing) and outputs (eg. Documented
decisions) of its own. For simple
procurement items, the terms and
conditions of the contract can be previously
set and non-negotiable, and only need to be
accepted by the seller
The project manager may not be the lead
negotiator on procurements. The project
manager and other members of the project
team may be present during negotiations to
provide assistance, and if needed, to ass
clarifications of the project’s technical,
quality and management requirements.
(7.1) Attacks
(7.2) Personal Insults
(7.3) Good guy / Bad Guy
(7.4) Deadline
(7.5) Lying
(7.6) Limited Authority
(7.7) Missing Man
(7.8) Fair & Reasonable
A contract is a legal relationship subject to remedy on
courts. The major components in an agreement document
will vary, but may include the following.
(2.1) SOW or Deliverables
(2.3) Performance reporting
(2.4) Roles & Responsibilities
(2.5) Seller’s Place of Performance
(2.6) Pricing
(2.7) Payment Terms
(2.8) Place of Delivery
(2.9) Inspection & Acceptance Criteria
(2.10) Warranty
(2.11) Product Support
(2.12) Limitation of Liability
(2.13) Fees & Retainer
(2.14) Penalties
(2.15) Incentives
(2.16) Insurance & Performance Bonds
(2.17) Subordinate Contract Approvals
(2.18) Change Requests Handling
(2.19) Termination Clause & Alternative Dispute
Resolution (ADR) mechanisms
(4) Change Requests
(5.1) Cost baseline
(5.2) Scope baseline
(5.3) Schedule baseline
(6.3) Risk Register
(6.4) Stakeholder register

of 61
section is equally
applicable to non-
contractual work
entered into with other
units of the project
team’s organizations.
(7.9) Delay
(7.10) Extreme Demands
(7.11) Withdrawal
(7.12) Fait accompli
12.3 Control Procurements
It is the process of managing procurement relationships, monitoring
contract performance, and making changes and corrections to
contracts as appropriate.
Benefits: It ensures that both the seller’s and buyer’s performance
meets procurement requirements according to the terms of the legal
agreement.
Both the buyer and the seller will administer the procurement for
similar purpose. Each is required to ensure that both parties meet
their contractual obligations and that their own legal rights are
protected. The legal nature of the contractual relationship makes it
imperative that the project management team is aware of the legal
implications of actions taken. When controlling any procurement on
larger projects with multiple providers, a key aspect of contract
administration is managing interfaces among the various providers
Due to varying organizational structures, many organizations treat
contract administration as an administrative function separate from
the project organization. While a procurement administrator may be
on the project team, this individual typically reports to a supervisor
form a different department. This is usually true of the performing
organization is also the seller of the project to an external customer
Control procurements include application of the appropriate project
management processes to the contractual relationship(s) and
integration of the outputs from these processes into the overall
management of the project. This integration will often occur at
multiple levels when there are multiple sellers and multiple products,
services, or results involved. The project management processes that
are applied may include,
(1) Direct & Manage Project Work: To authorize the seller’s work at
the appropriate time
(2) Control Quality: To inspect and verify adequacy of the seller’s
product
(3) Perform Integrated Change Control
(4) Control Risks
Control Procurements also has a financial management component
that involves monitoring payments to the seller. This ensures that
payment terms defined within the contract are met and the seller
compensation is linked to the seller’s progress, as defined in the
contract. One of the principal concerns when making payments to
suppliers is that there is a close relationship of payments made to
the work accomplished
The control procurement process reviews and documents how well a
seller is performing or has performed based on the contract and
establishes corrective actions when needed. These performances
reviews may be used as a measure of the seller’s competency for
performing similar work on future projects. Similar evaluations are
(3) Agreements
(5.1) Technical Documentation: Seller-
developed technical documentation and other
deliverable information are provided IAW terms
of the contract.
(5.2) Work Performance Information: The
seller’s performance reports indicate which
deliverables have been completed and which
have not.
(6.1) The extent to which quality standards are
being satisfied
(6.2) The cost that have been incurred and
committed
(6.3) Identification of seller invoices that have
been paid
(1) Contract Change Control System:
defines the process by which the
procurement can be modified. It includes
the paper work, tracking systems, dispute
resolution procedures, and approval level
necessary for authorizing changes. The
contract change control system is integrated
with the integrated change control system
(2) Procurement Performance Reviews: is a
structured review of the seller’s progress to
deliver project scope and quality, within
cost and on schedule, as compared to the
contract. It can include a review of seller-
prepared documentation and buyer
inspection, as well as quality audits
conducted during seller’s execution of the
work. The objective of a performance
review is to identify performance success or
failures, progress with respect to the
procurement statement of work, and
contract non-compliance, which allow the
buyer to quantify the seller’s demonstrated
ability or inability to perform work. Such
reviews may take place as a part of project
status reviews, which would include key
suppliers.
(3) Inspections & Audits: Inspections and
audits required by the buyer and supported
by the seller, as specified in the
procurements contract, can be conducted
during execution of the project to verify
compliance in the seller’s work processes or
deliverables. If authorized by contract,
some inspection and audit teams can
include buyer procurement personnel.
(4) Performance Reporting: Work
performance data and reports supplied by
sellers are evaluated against the agreement
requirements. Work performance
information from this evaluation is then
reported as appropriate. Performance
reporting provides management with
information about how effectively the seller
is achieving the contractual objectives.
(5) Payments Systems: Payments to the
seller are typically processed by the
accounts payable system of the buyer after
certification of satisfactory work by an
authorized person on the project team. All
payments should be made and documented
in strict accordance with the terms of the
contract.
(6) Claims Administration: Contested
changes and potential constructive changes
(1) Work Performance Information: provides a basis of
current or potential problems to support later claims or
new procurements. By reporting on the performance of a
vendor, the organization increases knowledge of
performance of the procurement, which supports
improved forecasting, risk management, and decision
making. Performance reports also assist in the events
there is a dispute with the vendor
Work performance information includes reporting
compliance of contract, which provides procuring
organizations a mechanism to track specific deliverables
expected and received from vendors. Contract compliance
reports support improved communications with vendors so
that potential issues are addressed promptly to the
satisfaction of all parties.
(2) Change Requests: Change requests to the following
are processed through the PICC process
(2.1) Project Management Plan
(2.2) Its subsidiary plan
(2.4) Cost Baseline
Requested by unresolved changes can include direction
provided by the buyer or actions taken by the seller, which
the other party considers a constructive change to the
contract. Since any of these constructive changes may be
disputed by one part and can lead to a claim against the
other party, such changes are uniquely identified and
documented by project correspondence.
(3.3) Cost Baseline
(4.1) Procurement Documentation
(5.1) Correspondence: Contract terms and conditions
often require written documentation certain aspects of
buyer / seller communications, such as the need for
warnings of unsatisfactory performance and requests for
contract changes or clarifications. This can include the
reported results of buyer audits and inspections that
indicate weakness the seller needs to correct. In addition
to specific contract requirements for documentation, a
complete and accurate written record of all written and
oral contract communications as well as actions taken and
decisions made are maintained by both parties.
(5.2) Payment Schedules and requests
(5.3) Seller performance evaluation documentation: Seller
performance evaluation documentation is prepared by the
buyer. Such performance evaluations documents the
seller’s ability to continue to perform work on the current
contract, indicate if the seller can be allowed to perform
work on future projects, or rate how well the seller’s

of 61
also carried out when it is necessary to confirm that a seller is not
meeting the seller’s contractual obligations and when the buyer
contemplates corrective actions. Control procurements include
capturing the necessary details for managing any early terminations
of the contracted work (for cause, convenience and default) in
accordance with the termination clause of the agreement. These
details are used in the close procurement process to terminate the
agreement
Agreements can be amended at any time prior to contract closure by
mutual consent, IAW the change control terms of the agreement.
Such amendments are typically captured in writing.
are those requested changes where buyer
and seller cannot reach an agreement on
compensation for the change or cannot
agree that a change has occurred. These
contested changes are variously called
claims. Disputes or appeals. Claims are
documented, processed, monitored, and
managed throughout the contract life cycle,
usually in accordance with the terms of the
contract. If the parties themselves do not
resolve a claim, it may have to be handled
IAW alternative dispute resolution (ADR)
typically following procedures established in
the contract. Settlement of all claims and
disputes through negotiation is the
preferred method
(7) Records Management System: A record
management system is used by the project
manager to manage contract &
procurement documentation and records. It
consists of a specific set of processes,
related control functions, and automation
tools that are consolidated and combined as
part of the PMIS. The system contains a
retrievable archive of contract documents
and correspondence.
performing the project work. These documents may form
the basis for early termination of the seller’s contract or
determine how contract penalties, fees, or incentives are
administered. The results of these performance
evaluations can also be included in the appropriate
qualified sellers list.
Process Group: Closing
12.4 Close Procurements
It is the process of completing each procurement
Benefits: It documents agreements and related documentation for
future reference
The close procurements process also involves administrative
activities such as finalizing open claims, updating records to reflect
final results, and archiving such information for future use. Close
procurements addresses each contract applicable to the project or a
project phase. In multiphase projects, the term of a contract may
only be applicable to a given phase of the project. In these cases,
the close procurements process closes the procurement(s) applicable
to that phase of the project. Unresolved claims may be subject to
litigation after closure. The contract terms and conditions can
prescribe specific procedures for agreement closure. The close
procurement process the close project or phase process by ensuring
contractual agreements are completed or terminated
Early termination of a contract is a special case of procurement
closure that can result from a mutual agreement by both parties,
from the default of one party, or for convenience of the buyer of
provided for in the contract. The rights and responsibilities of the
parties in the event of an early termination are contained in the
terminations clause of the contract. Based upon those procurement
terms and conditions, the buyer may have the right to terminate the
whole contract or a portion of the contract, at any time, for cause or
convenience. However, upon those contract terms and conditions,
the buyer may have to compensate the seller’s preparations and for
any completed and accepted work related to terminated part of the
contract.
(2) Procurement Documents
(1) Procurement Audits: A procurement
audit is a structured review of the
procurement process originating from the
plan procurement management process
through control procurements. The
objective of a procurement audit is to
identify success and failures that warrant
recognition in the preparation or
administration of other procurement
contracts on the project, or on other
projects within the performing organization.
(2) Procurement Negotiations: In all
procurement negotiations, the final
equitable settlement of all outstanding
issues, claims, and disputes by negotiation
is a primary goal. Whenever settlement
cannot be achieved through direct
negotiation, some form of alternative
dispute resolution (ADR) including
mediation or arbitration may be explored.
When all these fails, litigation in courts is
the least desirable option
(3) Record Management System
(1) Closed Procurements: The buyer, usually through its
authorized procurement administrator, provides the seller
with formal written notice that the contract has been
completed. Requirements for formal procurement closure
are usually defined in the terms and conditions of the
contract and are included in the procurement
management plan.
(2.1) Procurement File: A complete set of indexed contract
documentation, including the closed contract, is prepared
for inclusion, with the final project files
(2.2) Deliverable Acceptance: Documentation of formal
acceptance of seller-provided deliverables may be required
to be retained by the organization. The close procurement
process ensures this documentation requirement is
satisfied. Requirements for formal deliverable acceptance
and how to address non-conforming deliverables are
usually defined in the agreement.
(2.3) Lessons learned Documentation: Lessons learned,
what has been experienced, and process improvement
recommendations should be developed for the project file
to improve future procurements.
Stakeholder
Management
Process Group: Initiating
13.1 Identify Stakeholder
(1) Project Charter: The project charter can
provide information about internal and external
parties related with the project and affected by
the result or the execution of the project, such
(1) Stakeholder Analysis: is a technique of
systematically gathering and analyzing
quantitative and qualitative information to
determine whose interests should be taken
(1.1) Identification information
(A) Name
(B) Organizational Position

of 61
required to identify the
people, groups or
organizations that
could impact or be
impacted by the
project to analyze
stakeholder
expectations and their
impact on the project,
and to develop
appropriate
management
strategies for
effectively engaging
stakeholders in project
decisions and
execution. Stakeholder
management also
focuses on continuous
communication with
stakeholders to
understand their needs
and expectations,
addressing issues as
they occur, managing
conflicting interests
and fostering
appropriate
stakeholder
engagement in project
decisions and
activities. Stakeholder
satisfaction should be
managed as a key
project objective
Every project will have
stakeholders who are
impacted by or can
impact the project in a
positive or negative
way. While some
stakeholders may have
a limited ability to
influence the project,
others may have a
significant influence on
the project and its
expected outcomes.
The ability of the
project manager to
correctly identify and
manage these
stakeholders in an
appropriate manner
can mean the
difference between
success and failure.
It is the process of identifying the people, groups, or organizations
that could impact or be impacted by a decision, activity, or outcome
of the project analyzing and documenting relevant information
regarding their interests, involvement, interdependencies, influence,
and potential impact on project success
Benefits: It allows the project manager to identify the appropriate
focus for each stakeholder or group of stakeholders.
Project stakeholders are individuals, groups, or organizations who
may affect, be affected by, or perceive themselves to be affected by
a decision, activity, or outcome of a project.
They are comprised of persons and organizations such as customers,
sponsors, the performing organization and the public who are
actively involved in the project, or whose interests may be positively
or negatively affected by the execution or completion of the project.
They may also exert influence over the project and its deliverables.
Stakeholders may be at different levels within the organization and
may possess different authority levels, or may be external to the
performing organization for the project.
It is critical for project success to identify the stakeholders early in
the project or phase and to analyze their levels of interest, their
individual expectations, as well as their importance and influence.
This initial assessment should be reviewed and updated regularly.
Most projects will have a diverse number of stakeholders, depending
on their size, type and complexity. While the project manager’s time
is limited and should be used as efficiently as possible, these
stakeholders should be classified according to their interest,
influence, and involvement in the project, taking into consideration
the fact that the affect or influence of a stakeholder may not occur or
become evident until later stages in the project or phase. This
establishes the project manager to focus on relationships necessary
to ensure the success of the project.
as project sponsor(s), customers, team
members, groups, and departments
participating in the project, and other people or
organizations affected by the project.
(2) Procurements Documents: If a project is the
result of a procurement activity or is based on
an established contract, the parties in that
contract are key project stakeholders other
relevant parties, such as suppliers, should also
be considered as part of the project stakeholder
list
into account throughout the project. It
identifies the interest, expectations, and
influence of the stakeholders and relates
them to the purpose of the project. It also
helps to identify stakeholder relationships
(with the project and with other
stakeholders) that can be leveraged to build
coalitions and potential partnerships to
enhance the project’s chance of success,
along with stakeholder relationships that
need to be influenced differently at different
stages of the project or phase
Stakeholder analysis generally involves
steps described below
(a) Identify all potential project
stakeholders and relevant information, such
as their roles, departments, interests,
knowledge, expectations, and influence
levels. Key stakeholders are usually easy to
identify. They include any one in a decision-
making or management role who is
impacted by the project outcome, such as
the sponsor, the project manager, and the
primary customer. Identifying other
stakeholder is usually done by interviewing
identified stakeholders and expanding the
list until all potential stakeholders are
included.
(b) Analyze the potential impact or support
each stakeholder could generate, and
classify then so as to define an approach
strategy. In large stakeholder communities,
it is important to prioritize the stakeholders
to ensure the efficient use of effort to
communicate and manage their
expectations
(c) Assess how key stakeholders are likely
to react or respond in various situations, in
order to plan how to influence them to
enhance their support and mitigate
potential negative impacts
Stakeholder classification models include,
(1.1) Power/Interest Grid: Grouping the
stakeholders based on their level of
authority (“power”) and their level of
concern (“interest”) regarding the project
outcomes.
(1.2) Power/Influence Grid: Grouping the
stakeholders based on their level of
authority (“power”) and their active
involvement (“influence”) in the project.
(1.3) Influence/Impact Grid: Grouping the
stakeholders based on their active
involvement (“influence”) in the project and
their ability to effect changes to the
project’s planning or execution (“impact”)
(1.4) Salience Model: describing classes of
stakeholders based on their power (ability
to impose their will), urgency (need for
immediate attention), and legitimacy (their
(C) Location
(D) Role in the project
(E) Contact information
(1.2) Assessment Information
(A) Major requirements
(B) Main expectations
(C) Potential Influence in the project
(D) Phase on the life cycle with the most interest
(1.3) Stakeholder Classification
(A) Internal
(B) External
(C) Supporter
(D) Neutral
(E) Resistor
The stakeholder register should be consulted and updated
on a regular basis, as stakeholder’s may change – new
ones identified throughout the life cycle of the project

of 61
involvement is appropriate)
(2) Expert Judgment
(3) Meetings
13.2 Plan Stakeholder Management
It is the process of developing appropriate management strategies to
effectively engage stakeholders throughout the project life cycle,
based on the analysis of their needs, interests and potential impact
on project success
Benefits: It provides a clear, actionable plan to interact with project
stakeholders to support the project’s interests.
Plan stakeholder management identifies how the project will affect
stakeholders, which then allows the project manager to develop
various ways to effectively engage stakeholders in the project, to
manage their expectations, and to ultimately achieve the project
objectives
Stakeholder management is more than improving communications
and requires more than managing a team. Stakeholder management
creation and maintenance of relationships between the project team
and stakeholders, within project boundaries
As the project progresses, the membership of the stakeholder
community and required level of engagement may change,
therefore, stakeholder management planning is an iterative process
that is reviewed on a regular basis by the project manager
(1.1) Life cycle selected for the project and
processes that will be applied to each phase.
(1.2) Description of how work will be executed
to accomplish the project objectives
(1.3) Description of how human resources
requirements will be met and how roles and
responsibilities, reporting relationships and
staffing management will be addressed and
structured for the project
(1.4) Change management plan that documents
how changes will be monitored and controlled
(1.5) Need and techniques for communicating
among stakeholders
(1) Expert Judgment: Based on project
objectives, the project manager should
apply expert judgment to decide upon the
level of engagement required at each stage
of the project from each stakeholder. For
e.g. at the beginning of the project, it may
be necessary for senior stakeholders to be
highly engaged in order to clear away any
obstacles to success. Once these have been
successfully removed, it may be sufficient
for senor stakeholders to change their level
of engagement from leading to supporting
and other stakeholders, such as end users,
may become more important.
(2) Meetings
(3) Analytical Techniques: The current
engagement level of all stakeholders needs
to be compared to planned to engagement
levels required for successful project
completion. Stakeholder engagement
throughout the life cycle of the project is
critical to project success. The engagement
level of stakeholders can be classified as
follows
(3.1) Unaware: Unaware of project and
potential impacts
(3.2) Resistant: Aware of project and
potential impacts and resistant to change
(3.3) Neutral: Aware of project yet neither
supportive nor resistant
(3.4) Supportive: Aware of project and
potential impacts and supportive to change
(3.5) Leading: Aware of projects and
potential impacts and actively engaged in
ensuring the project is a success.
The current engagement can be
documented using “Stakeholder
Engagement Assessment Matrix”
(1) Stakeholder Management Plan: is a component of
Project Management Plan and identifies the management
strategies required to effectively engage stakeholders
(1.1) Desired & Current engagement levels of key
stakeholders
(1.2) Scope & impact of change to stakeholders
(1.3) Identified inter relationships & potential overlap
between stakeholders
(1.4) Stakeholder communications requirement for the
current project phase
(1.5) Information to be distributed to the stakeholders,
including language, format, content & level of detail
(1.6) Reason for the distribution of that information & the
expected impact to stakeholder engagement
(1.7) Time frame and frequency for the distribution of
required information to stakeholders
(1.8) Method of updating & refining the stakeholder
management plan as the project progresses and develops
Project Managers should be aware of the sensitive nature
of the stakeholder management plan and take appropriate
precautions. For e.g. information on stakeholders who are
resistant to the project can be potentially damaging, and
due consideration should be given regarding the
distribution of such information. When updating the
stakeholder management plan, the validity of underlying
assumptions should be reviewed to ensure continued
accuracy and relevance.
(2) Project Document Updates
13.3 Manage Stakeholder Engagement
It is the process of communicating and working with stakeholders to
meet their needs/expectations, address issues as they occur, and
foster appropriate stakeholder engagement in project activities
throughout the project life cycle
Benefits: It allows the project manager to increase support and
minimize resistance from stakeholders, significantly increasing the
chances to achieve project success.
Manage Stakeholder Engagement involves activities such as
(1) Engaging stakeholders at appropriate project stages to obtain or
confirm their continued commitment to the success of the project.
(2) Managing stakeholder expectations through negotiations and
communication, ensuring project goals are achieved.
(1) Stakeholder Management Plan
(2.1) Stakeholder communication requirement
(2.2) Information to be communicated,
including language, format, content and level of
detail
(2.3) Reasons for distribution of information
(2.4) Person or groups who will receive
information
(2.5) Escalation process
(3) Change Log
(4.1) Organizational Communication
Requirements
(4.2) Issue Management Procedures
(4.3) Change Control Procedures
(4.4) Historical information about projects
(1) Communication Methods
(2) Interpersonal Skills
(1.1) Building Trust
(1.2) Resolving Conflict
(1.3) Active Listening
(1.4) Over Resistance to Change
(3) Management Skills
(3.1) Facilitate Consensus toward project
objectives
(3.2) Influence people to support the
project
(3.3) Negotiate agreements to satisfy the
project needs
(3.4) Modify organizational behavior to
accept the project outcomes
(1) Issue Log
(2) Change Requests
(5.1) Stakeholder notifications

of 61
Printed on Friday, February 26, 2016 18:38:03
(3) Addressing potential concerns that have not yet become issues
and anticipating future problems that may be raised by stakeholders.
Such concerns need to be identified and discussed as soon as
possible to assess associated project risk.
Managing stakeholder engagement helps to increase the probability
of project success by ensuring that stakeholders clearly understand
the project goals, objectives, benefits and risks. This enables them to
be active supporters of the project and to help guide activities and
project decisions. By anticipating people’s reactions to project,
proactive actions can be taken to win support or minimize negative
impacts.
The ability of stakeholders to influence the project is typically highest
during the initial stages and gets progressively lower as the project
progresses. The project manager is responsible for encouraging and
managing the various stakeholders in a project and may call upon
the project sponsor to assist as needed. Active management of
stakeholder involvement decreases the risk of the project failing to
meet its goals and objectives
13.4 Control Stakeholder Engagement
It is the process of monitoring project stakeholder relationships and
adjusting strategies and plans for engaging stakeholders
Benefits: It will maintain or increase the efficiency or effectiveness
of stakeholder engagement activities as the project evolves or the
environment changes
Stakeholder engagement activities are included in the stakeholder
management plan and are executed during the life cycle of the
project. Stakeholder engagement should be continuously controlled
(2) Issue Log
(4.3) Issue log
(4.4) Change Log
(4.5) Project Communications
(2) Expert Judgment
(3) Meetings
(2) Change Requests: Analysis of project performance and
interaction with stakeholder often generates change
requests. These change requests are processes through
the PICC as follows
(2.1) Recommend corrective action include changes that
bring the expected future performance of the project in
line with the project management plan
(2.2) Recommended preventive actions can reduce the
probability of incurring future negative project
performacne
(4.2) Issue Log
(5) Organization Process Assets Updates
(5.1) Stakeholder Notifications

of 61
3.3 Respect: Mandatory Standards
As practitioners inthe global project management community, we require the following of ourselves
and our fellow practitioners:
3.3.1 We negotiate in good faith.
3.3.2 We do not exercise the power of our expertise or position to influence the decisions or
actions of others in order to benefit personally at their expense.
3.3.3 We do not act in an abusive manner toward others.
3.3.4 We respect the property rights of others
CHAPTER 4. FAIRNESS
4.1 Description of Fairness
Fairness is our duty to make decisions and act impartially and objectively. Our conduct must
be free from competing self interest, prejudice, and favoritism.
4.2 Fairness: Aspirational Standards
As practitioners in the global project management community:
4.2.1 We demonstrate transparency in our decision-making process.
4.2.2 We constantly reexamine our impartiality and objectivity, taking corrective action as
appropriate.
4.2.3 We provide equal access to information to those who are authorized to have that information.
4.2.4 We make opportunities equally available to qualified candidates.
4.3 Fairness: Mandatory Standards
As practitioners in the global project management community, we require the following of ourselves
Conflict of Interest Situations
4.3.1 We proactively and fully disclose any real or potential conflicts of interest to the appropriate
stakeholders.
4.3.2 When we realize that we have a real or potential conflict of interest, we refrain from
engaging in the decision-making process or otherwise attempting to influence outcomes,
unless or until: we have made full disclosure to the affected stakeholders; we have an
approved mitigation plan; and we have obtained the consent of the stakeholders to
proceed.
Favouritism and Discrimination
4.3.3 We do not hire or fire, reward or punish, or award or deny contracts based on personal
considerations, including but not limited to, favouritism, nepotism, or bribery
4.3.4 We do not discriminate against others based on, but not limited to, gender, race, age,
religion, disability, nationality, or sexual orientation.
4.3.5 We apply the rules of the organization (employer, Project Management Institute, or other
group) without favouritism or prejudice
CHAPTER 5. HONESTY
5.1 Description of Honesty
Honesty is our duty to understand the truth and act in a truthful manner both in our
communications and in our conduct.
5.2 Honesty: Aspirational Standards
As practitioners inthe global project management community:
5.2.1 We earnestly seek to understand the truth.
5.2.2 We are truthful in our communications and in our conduct.
5.2.3 We provide accurate information in a timely manner.
5.3 Honesty: Mandatory Standards
As practitioners in the global project management community, we require the following of ourselves
5.3.1 We do not engage in or condone behavior that is designed to deceive others, including but
not limited to, making misleading or false statements, stating half-truths, providing
information out of context or withholding information that, if known, would render our
statements as misleading or incomplete.
5.3.2 We do not engage in dishonest behaviour with the intention of personal gain or at the
expense of another.
1.2 Persons to Whom the Code Applies
The Code of Ethics and Professional Conduct applies to:
1.2.1 All PMI members
1.2.2 Individuals who are not members of PMI but meet one or more of the following criteria:
.1 Non-members who hold a PMI certification
.2 Non-members who apply to commence a PMI certification process
.3 Non-members who serve PMI in a volunteer capacity
1.4 Values that Support this Code
Practitioners from the global project management community were asked to identify the values that formed the basis of their decision
making and guided their actions. The values that the global project management community defined as most important were:
responsibility, respect, fairness, and honesty. This Code affirms these four values as its foundation
1.5 Aspirational and Mandatory Conduct
Each section of the Code of Ethics and Professional Conduct includes both aspirational standards and mandatory standards. The
aspirational standards describe the conduct that we strive to uphold as practitioners. Although adherence to the aspirational
standards is not easily measured, conducting ourselves in accordance with these is an expectation that we have of ourselves as
professionals—it is not optional.
The mandatory standards establish firm requirements, and in some cases, limit or prohibit practitioner behaviour. Practitioners who do
not conduct themselves in accordance with these standards will be subject to disciplinary‘procedures before PMI’s Ethics Review
Committee
CHAPTER 2. RESPONSIBILITY
2.1 Description of Responsibility
Responsibility is our duty to take ownership for the decisions we make or fail to make, the actions we take or fail to take, and the
consequences that result.
2.2 Responsibility: Aspirational Standards
2.2.1 We make decisions and take actions based on the best interests of society, public safety, and the environment.
2.2.2 We accept only those assignments that are consistent with our background, experience, skills, and qualifications.
2.2.3 We fulfill the commitments that we undertake – we do what we say we will do.
2.2.4 When we make errors or omissions, we take ownership and make corrections promptly. When we discover errors or
omissions caused by others, we communicate them to the appropriate body as soon they are discovered. We accept
accountability for any issues resulting from our errors or omissions and any resulting consequences.
2.2.5 We protect proprietary or confidential information that has been entrusted to us.
2.2.6 We uphold this Code and hold each other accountable to it.
2.3 Responsibility: Mandatory Standards
As practitioners in the global project management community, we require the following of ourselves and our fellow practitioners:
Regulations and Legal Requirements
2.3.1 We inform ourselves and uphold the policies, rules, regulations and laws that govern our work, professional,
and volunteer activities.
2.3.2 We report unethical or illegal conduct to appropriate management and, if necessary, to those affected by the conduct.
Ethics Complaints
2.3.3 We bring violations of this Code to the attention of the appropriate body for resolution.
2.3.4 We only file ethics complaints when they are substantiated by facts.
CHAPTER 3. RESPECT
3.1 Description of Respect
Respect is our duty to show a high regard for ourselves, others, and the resources entrusted to us. Resources entrusted
to us may include people, money, reputation, the safety of others, and natural or environmental resources. An
environment of respect engenders trust, confidence, and performance excellence by fostering mutual cooperation — an
environment where diverse perspectives and views are encouraged and valued.
3.2 Respect: Aspirational Standards
3.2.1 We inform ourselves about the norms and customs of others and avoid engaging in behaviours they might consider
disrespectful.
3.2.2 We listen to others’ points of view, seeking to understand them.
3.2.3 We approach directly those persons with whom we have a conflict or disagreement.
3.2.4 We conduct ourselves in a professional manner, even when it is not reciprocated.

PMBOK 5th Edition Study Notes

More Related Content

What's hot (20)

Similar to PMBOK 5th Edition Study Notes (20)

More from Atul Gaur PMP (11)

Recently uploaded (20)

PMBOK 5th Edition Study Notes