MDO451: Online

Project Framework
and Integration
Management v1.0
Participant Guide

Note to Participants: This guide contains the same content as the online version of this course.
However, the flow of the guide, section headings, and some graphics may appear differently
than they do online due to the interactive nature of the online courseware.
MDO 451: Online Project Framework and
Integration Management v1.0

© 2008 Boston University Corporate Education Center. All rights reserved. v1.0
Boston University Corporate Education Center is operated by TechSkills LLC

Selected information is reprinted from A Guide to the Project Management Body of Knowledge – Third Edition (PMBOK®
Guide, Third Edition) with permission of the Project Management Institute, Inc. Four Campus Boulevard, Newton Square,
Pennsylvania 19073-3299 USA. Phone: (610) 356-4600, Fax: (610) 356-4647. Project Management Institute (PMI®) is the
world's leading project management association with over 150,000 members worldwide. For further information, contact PMI
headquarters at (610) 356-4600 or visit the web site at www.pmi.org.

© Project Management Institute, Inc. All rights reserved.

"PMI" is a trade and service mark registered in the United States and other nations; "PMP" and the PMP logo are registered
certification marks in the United States and other nations; "PMBOK" is a trademark registered in the United States and other
nations; and the PMI Logo, "PM Network", "Project Management Journal", "PMI Today", and "Building professionalism in
project management." are trademarks of the Project Management Institute, Inc.

Boston University Corporate Education Center online course content is continually reviewed and updated based
upon current industry standards and user feedback.
Table of Contents
Course Introduction.................................................................. 1
Course Goal .......................................................................................................................................... 1
Course Overview .................................................................................................................................. 1
Course Objectives ................................................................................................................................. 1
Course Concepts ................................................................................................................................... 2

Concept 1 – Project Management Framework ...................... 3

1-1: Framework Overview ........................................................................................................................ 4
A Framework for Project Management ................................................................................................ 5
Project Phases ....................................................................................................................................... 5
Project Life Cycles ................................................................................................................................ 5
Process Groups...................................................................................................................................... 6
Knowledge Areas .................................................................................................................................. 6
Knowledge Areas and Their Component Processes ............................................................................. 7
Inputs, Tools and Techniques, and Outputs .......................................................................................... 7
1-2: What is a Project ................................................................................................................................ 8
The Definition of a Project ................................................................................................................... 9
Progressive Elaboration ........................................................................................................................ 9
Project Examples .................................................................................................................................. 9
Reasons to Initiate a Project ................................................................................................................ 10
How Projects Differ from Operations ................................................................................................. 10
1-3: What Is Project Management? ......................................................................................................... 11
Defining Project Management ............................................................................................................ 12
Applications of Project Management .................................................................................................. 12
Project Management Rigor ................................................................................................................. 12
How Project Management Differs from Other Types of Management ............................................... 12
Project Management Hierarchy .......................................................................................................... 13
Organizational Benefits of Project Management ................................................................................ 14
Corporate Trends Drive the Demand for Project Management Services ............................................ 14
Project Management Training ............................................................................................................. 14
Project Management Certification ...................................................................................................... 15
Project Management Career Benefits ................................................................................................. 15
1-4: Project Manager Roles and Responsibilities ................................................................................... 16

i
 Defining the Project Manager ............................................................................................................. 17
Responsibilities of a Project Manager ................................................................................................ 17
Managing Project Constraints ............................................................................................................. 17
How Stakeholders' Needs and Expectations Affect The Triple Constraints ....................................... 18
Decisions Faced by Project Managers ................................................................................................ 19
Managing Stakeholder Needs and Expectations ................................................................................. 19
Negotiating.......................................................................................................................................... 19
Accomplishing Project Objectives ...................................................................................................... 20
Common Project Manager Primary Tasks .......................................................................................... 20
Project Manager Areas of Expertise ................................................................................................... 21
Project Manager Ethics ....................................................................................................................... 25
1-5: Organizational Structures ................................................................................................................ 26
The Spectrum of Organizational Types .............................................................................................. 27
Organizational Structures and Their Impact on Project Management ................................................ 27
Organizational Influences on Projects ................................................................................................ 28
Organizational Culture, Values, and Styles ........................................................................................ 29
The Project Management Office (PMO) ............................................................................................. 30
The Role of the PMO .......................................................................................................................... 30
Project Management System............................................................................................................... 31
1-6: Project Stakeholders ........................................................................................................................ 32
The Project's Stakeholders .................................................................................................................. 33
Identifying Project Stakeholders ......................................................................................................... 33
Internal vs. External Stakeholders ...................................................................................................... 34
Common Project Stakeholders ............................................................................................................ 34
The Project Sponsor ............................................................................................................................ 34
Identifying Stakeholder Needs ............................................................................................................ 35
Gathering Stakeholder Requirements and Expectations ..................................................................... 35
Stakeholder Influence ......................................................................................................................... 35
Managing Stakeholder Influence ........................................................................................................ 36
Increasing Stakeholder Commitment .................................................................................................. 36
Reducing Stakeholder Impact ............................................................................................................. 37
1-7: Project Life Cycles .......................................................................................................................... 38
Defining Project Phase ........................................................................................................................ 39
Common Project Phases ..................................................................................................................... 40
Project Life Cycles .............................................................................................................................. 40

ii
 Phases and Life Cycles ....................................................................................................................... 41
Generic Project Life Cycle.................................................................................................................. 41
Phase Completion Requirements ........................................................................................................ 42
Project Life Cycle Approaches ........................................................................................................... 42
Project Life Cycle Examples............................................................................................................... 43
Waterfall Life Cycle ........................................................................................................................... 43
Incremental Life Cycle ....................................................................................................................... 44
Spiral Life Cycle ................................................................................................................................. 45
Evolutionary Life Cycle ...................................................................................................................... 46
Selecting a Life Cycle Model.............................................................................................................. 47
Product Life Cycles............................................................................................................................. 47
Summary ................................................................................................................................................. 48

Concept 2 – Project Management Processes ........................ 49

2-1: Process Overview ............................................................................................................................ 50
Definition of a Process ........................................................................................................................ 51
Project Management Process Groups ................................................................................................. 51
Degree of Project Management Process Rigor ................................................................................... 52
Project Management Processes and Quality Principles ...................................................................... 52
Key Quality Initiatives ........................................................................................................................ 53
The PDCA Cycle ................................................................................................................................ 53
Mapping the Process Groups to the PDCA Cycle .............................................................................. 54
Iterative Nature of a Process ............................................................................................................... 55
Process Group Interaction ................................................................................................................... 55
Interaction Between Project Phases .................................................................................................... 56
Process Group Inputs and Outputs ...................................................................................................... 57
Process Flow Within and Between the Process Groups...................................................................... 58
2-2: Initiating Process Group .................................................................................................................. 60
Initiating Process Group ..................................................................................................................... 61
Purpose of the Initiating Process Group ............................................................................................. 61
Activities Prior to the Initiating Process ............................................................................................. 61
Initiating Processes ............................................................................................................................. 62
Initiating Process Group: Major Outputs ............................................................................................ 63
2-3: Planning Process Group................................................................................................................... 64
Planning Process Group ...................................................................................................................... 65

iii
 Purpose of the Planning Process Group .............................................................................................. 65
Planning Processes .............................................................................................................................. 66
Progressive Elaboration ...................................................................................................................... 67
Planning Process Group: Major Outputs ............................................................................................ 67
2-4: Executing Process Group................................................................................................................. 70
Executing Process Group .................................................................................................................... 71
Purpose of the Executing Process Group ............................................................................................ 71
Executing Processes ............................................................................................................................ 72
Project Execution – Starting the Work ............................................................................................... 73
Project Execution – Controlling the Work .......................................................................................... 73
Executing Process Group: Major Outputs .......................................................................................... 73
2-5: Monitoring and Controlling Process Group .................................................................................... 74
Monitoring and Controlling Process Group ........................................................................................ 75
Purpose of the Monitoring and Controlling Process Group ................................................................ 75
Monitoring and Controlling Processes ................................................................................................ 76
Monitoring and Controlling Process Group: Major Outputs .............................................................. 77
Project Change Management .............................................................................................................. 77
2-6: Closing Process Group .................................................................................................................... 78
Closing Process Group ........................................................................................................................ 79
Purpose of the Closing Process Group ................................................................................................ 79
Closing Processes................................................................................................................................ 80
Closing Process Group: Major Outputs .............................................................................................. 80
The Importance of Formal Project Closure......................................................................................... 81
2-7: Project Management Knowledge Areas .......................................................................................... 82
Project Management Knowledge Areas .............................................................................................. 83
Mapping the Processes to the Knowledge Areas ................................................................................ 84
Summary ................................................................................................................................................. 85

Concept 3 – Project Integration Management ..................... 86

3-1: Overview of Project Integration Management ................................................................................ 87
Definition of Project Integration Management ................................................................................... 88
Balancing Trade-Offs.......................................................................................................................... 88
Project Integration Management ......................................................................................................... 89
Project Integration Management Processes ........................................................................................ 90
Project Integration Management Processes Flow ............................................................................... 91

iv
 Business Reasons for Projects............................................................................................................. 92
Assignment of the Project Manager .................................................................................................... 92
3-2: Develop Project Charter .................................................................................................................. 93
Purpose of a Project Charter ............................................................................................................... 94
Who Issues a Project Charter? ............................................................................................................ 94
Inputs, Tools and Techniques, and Outputs ........................................................................................ 94
Inputs to the Develop Project Charter Process .................................................................................... 95
Tools and Techniques for the Develop Project Charter Process ......................................................... 96
Outputs from the Develop Project Charter Process ............................................................................ 97
3-3: Develop Preliminary Project Scope Statement ................................................................................ 99
Definition of the Project Scope Statement ........................................................................................ 100
Why a Project Scope Statement Is Important ................................................................................... 100
Project Boundaries ............................................................................................................................ 100
Preliminary Project Scope Statement Elements ................................................................................ 101
Product Scope vs. Project Scope ....................................................................................................... 102
Inputs, Tool and Techniques, and Outputs ....................................................................................... 102
Inputs to the Develop Preliminary Project Scope Statement Process ............................................... 102
Tools and Techniques for the Develop Preliminary Project Scope Statement Process .................... 103
Outputs from the Develop Preliminary Project Scope Statement Process ........................................ 103
3-4: Develop Project Management Plan ............................................................................................... 105
Definition of a Project Management Plan ......................................................................................... 106
Project Management Plan: Subsidiary Plans .................................................................................... 106
Inputs, Tools and Techniques, and Outputs ...................................................................................... 107
Inputs to the Develop Project Management Plan Process ................................................................. 107
Tools and Techniques for the Develop Project Management Plan Process ...................................... 108
Outputs from the Develop Project Management Plan Process ......................................................... 109
3-5: Direct and Manage Project Execution ........................................................................................... 111
Definition of Direct and Manage Project Execution ......................................................................... 112
Inputs, Tools and Techniques, and Outputs ...................................................................................... 112
Inputs to the Direct and Manage Project Execution Process ............................................................ 113
Tools and Techniques for the Direct and Manage Project Execution Process.................................. 113
Outputs from the Direct and Manage Project Execution Process ..................................................... 114
Defect Repair Process Flow .............................................................................................................. 115
3-6: Monitor and Control Project Work ................................................................................................ 117
Project Performance .......................................................................................................................... 118

v
 The Monitor and Control Project Work Process ............................................................................... 118
Inputs, Tools and Techniques, and Outputs ...................................................................................... 118
Inputs to the Monitor and Control Project Work Process ................................................................. 119
Tools and Techniques for the Monitor and Control Project Work Process ...................................... 119
Outputs from the Monitor and Control Project Work Process .......................................................... 120
3-7: Integrated Change Control............................................................................................................. 121
Definition of Integrated Change Control .......................................................................................... 122
Integrated Change Control Process ................................................................................................... 122
Integrated Change Control Factors ................................................................................................... 122
Input, Tools and Techniques, and Outputs ....................................................................................... 123
Inputs to the Integrated Change Control Process .............................................................................. 124
Tools and Techniques for the Integrated Change Control Process ................................................... 124
Outputs from the Integrated Change Control Process....................................................................... 125
Charting a Typical Change Control Process ..................................................................................... 125
Outcomes of Requested Changes ...................................................................................................... 126
3-8: Close Project .................................................................................................................................. 127
Definition of Close Project ............................................................................................................... 128
Inputs, Tools and Techniques, and Outputs ...................................................................................... 128
Inputs to the Close Project Process ................................................................................................... 129
Tools and Techniques for the Close Project Process ........................................................................ 130
Outputs from the Close Project Process ............................................................................................ 130
Summary ............................................................................................................................................... 131

vi
Course Introduction
Course Goal
The goal of the Online Project Framework and Integration Management course is to develop a
foundation of project management skills using generally accepted project management knowledge and
practices. This course complies with standards of the Project Management Institute (PMI®) and the PMI®
publication, A Guide to the Project Management Body of Knowledge, Third Edition.
Outside the scope of this course: The Project Management Professional (PMP®) certification process
and Microsoft® Project proficiency are not included as objectives for this course:
PMP® certification is only available through the Project Management Institute (PMI®), which has specific
educational and experiential requirements that determine whether an individual is eligible to apply for
certification.

Course Overview
This course is primarily designed for people who have had or will have project management
responsibilities. It is also for project leaders or anyone who will be performing those roles in the future, as
well as for individuals who have worked on projects as project team members. The material will help you
to understand your project management organization, and to become more effective in applying project
management concepts within that organization regardless of your job title or official role.
This course will introduce you to project management concepts and essential techniques that can make
you more proficient at delivering your projects on time and within budget. Based on a framework which
encompasses the entire body of knowledge in the project management field, this course will familiarize
you with the language and methodology commonly used by professional publications, associations, and
your peers in the project management profession. It will also help you to get started in preparing for your
Project Management Professional (PMP®) certification from the Project Management Institute.

Course Objectives
The course objectives for the Online Project Framework and Integration Management course are
listed below.
• Define a project and identify the key characteristics of a project
• Recognize the key reasons for initiating projects, and the ways in which projects are used to
achieve the strategic goals of the organization
• Assess the importance of project management in today's complex and competitive business
environment
• Identify the critical skills needed by a project manager
• Understand the types of organizational structures, and describe their impact on managing
projects
• Identify the types of stakeholders for a project, and describe how to determine and manage
their influence over a project
• Distinguish among different project life cycles, and list the relative advantages and
disadvantages of each

Page 1
 • Describe the five project management Process Groups, the major interactions among them,
and the deliverables exchanged between them
• Recognize the effects of the factors that influence the level of implementation of each Process
Group
• Recognize how Project Integration Management facilitates the successful completion of
projects
• Define and develop a project charter
• Define and develop a preliminary project scope statement
• Identify the essential components of the project management plan and describe how they
interrelate
• Name and briefly explain many of the inputs, tools and techniques, and outputs of the
processes in the Project Integration Management Knowledge Area

Course Concepts
The course is divided into the concepts listed below, each of which is further divided into sub concepts.
This conceptual framework is the basis of the Table of Contents.
• Project Management Framework
• Project Management Processes
• Project Integration Management

Page 2
Concept 1 – Project Management Framework
Introduction
The Project Management Framework, as defined by the Project Management Institute (PMI®) in the
PMBOK® Guide, Third Edition, provides a useful set of concepts that help organize the information about
how projects can be managed effectively. The Project Management Framework section of this course
presents the meanings of these concepts and how they relate to each other in order to provide a solid
foundation for the project management discipline.
The discussion of this concept:
• Presents an overview of the Project Management Framework, as defined by the Project
Management Institute (PMI®) in the PMBOK® Guide, Third Edition, which provides a basic
structure for understanding project management
• Identifies the key characteristics of a project
• Explores key business factors fueling the demand for project management
• Presents the roles and responsibilities of the project manager, needed to successfully manage
projects
• Identifies the types of organizational structures and describes their impact on managing
projects
• Identifies the types of stakeholders for a project
• Identifies and distinguishes between different project life cycles, listing their relative
advantages and disadvantages

Page 3
1-1: Framework Overview
The framework for project management is the basis for the organization of the PMI® publication,
PMBOK® Guide, Third Edition. The PMBOK® Guide, Third Edition, is the compilation of information
required to manage a project, and contains the knowledge of proven professional practices and procedures
generally recognized as good practice.
The following pages will cover:
• A Framework for Project Management
• Project Phases
• Project Life Cycles
• Process Groups
• Knowledge Areas
• Knowledge Areas and Their Component Processes
• Inputs, Tools and Techniques, and Outputs

Page 4
A Framework for Project Management
The Project Management Institute defines a framework for project management that is a conceptual
model for understanding project management. The framework describes the environment in which the
project operates, as well as concepts about how project work is organized and managed.
The portion of the framework that addresses how project work is organized includes:
• Project phases
• Project life cycles
The portion of the framework that addresses how project work is managed includes:
• Project management processes. There are 44 project management processes that govern all
aspects of managing project work.
• Process Groups into which the project management processes are organized. The Process Groups
reflect the stage of the work being performed, from start to finish.
• Knowledge Areas into which the project management processes are organized by functional
specialization, such as Project Quality Management, Project Procurement Management, or
Project Risk Management.
The portion of the framework that addresses the project environment will be presented in a later concept.

Project Phases
Project work is divided into a number of project phases. This allows the project manager to allocate
specialized resources more efficiently and to manage the project's complexity and risk.

Definition: Project Phase

A collection of logically related project activities, usually culminating in the
completion of a major deliverable...
®
PMBOK Guide, Third Edition, Glossary

Project Life Cycles

A complete set of project phases is known as a project life cycle.

Definition: Project Life Cycle

A collection of generally sequential project phases whose name and number are
determined by the control needs of the organization or organizations involved in
the project. A life cycle can be documented with a methodology.
®
PMBOK Guide, Third Edition, Glossary

Organizations often define a limited set of standard project life cycles that project managers are expected
to use for all projects. Using standard project life cycles affords insights into the strengths and weaknesses
of common project activities, simplifies management oversight, and increases productivity in the
planning, execution, and control of projects.

Page 5
Process Groups
All projects are composed of processes. A process is a series of actions that bring about a result.
There are five project Process Groups for a project:
• Initiating Process Group
• Planning Process Group
• Executing Process Group
• Monitoring and Controlling Process Group
• Closing Process Group
The five Process Groups organize the forty-four processes of project management defined by PMI®.
Processes within the groups produce similar types of results. For example, the processes in the
Monitoring and Controlling Process Group produce information about the project's performance and
outputs that are used to correct deviations from plans.
The groups are also related in sequence: The outputs from the processes in each Process Group in the list
above are inputs to the processes in the next group in the list.

Knowledge Areas
The PMBOK® Guide, Third Edition, defines nine Knowledge Areas for project management.

Definition: Project Management Knowledge Area

An identified area of project management defined by its knowledge requirements
and described in terms of its component processes, practices, inputs, outputs, and
tools and techniques.
®
PMBOK Guide, Third Edition, Glossary

The nine project management Knowledge Areas are:

• Project Integration Management
• Project Scope Management
• Project Time Management
• Project Cost Management
• Project Quality Management
• Project Human Resource Management
• Project Communications Management
• Project Risk Management
• Project Procurement Management

Page 6
Knowledge Areas and Their Component Processes
The Knowledge Areas are described primarily in terms of their component processes. For example, the
graphic below depicts the 7 component processes of the Project Integration Management Knowledge
Area. In this course, when a specific process is being discussed, that process is highlighted in the matrix
showing where the process fits in both its Process Group and its Knowledge Area.
For example, in the diagram below, the focus is on 4.1 Develop Project Charter, a process in the
Project Integration Management Knowledge Area and a member of the Initiating Process Group.

Inputs, Tools and Techniques, and Outputs

Every project management process in the PMBOK® Guide is described in terms of its inputs, tools and
techniques, and outputs.
• Inputs: Documents or documentable items that will be acted upon
• Tools and Techniques: Mechanisms applied to the inputs to create the outputs
• Outputs: Documents or documentable items that are a result of the process
In this course, when a specific process is being introduced, you will see a diagram like the one shown
below. The diagram depicts the inputs, tools and techniques, and outputs of that process. The diagram
below shows these elements for the Develop Project Charter process.

Page 7
1-2: What is a Project
In this section, you will learn the definition of a project and understand the difference between a project
and other kinds of work.
The following pages will cover:
• The Definition of a Project
• Progressive Elaboration
• Project Examples
• Reasons to Initiate a Project
• How Projects Differ from Operations

Page 8
The Definition of a Project
The definition of a project as adopted by the Project Management Institute (PMI®) is presented below.

Definition: Project
A temporary endeavor undertaken to create a unique product, service, or result.
®
PMBOK Guide, Third Edition, Glossary

The key words in the definition are temporary and unique.

Temporary. A project has a well-defined beginning and ending. Although projects are temporary, they
are not necessarily short in duration.
Unique. Projects are not repetitious in nature and do not describe an ongoing operation. Projects are
designed to produce unique deliverables, such as a unique product, service, or outcome. Projects may bear
resemblances to other projects, but the combination of work, resources, objectives and other factors will
always be unique.
Projects exist to meet specific objectives, and they also consume constrained resources.

Progressive Elaboration
Progressive elaboration is an aspect of projects that reinforces the temporary and unique nature of a
project.
Projects move forward in steps or increments, and the project's work products (including their plans) are
refined and improved over time as more is learned about the project. At the start of a project, little may be
known about a project's scope, success criteria and metrics. As the project moves forward through the
iterative processes of initiating, planning, executing, monitoring and controlling, and closing, increasingly
more detail is known about the project's scope and the needed work.

Definition: Progressive Elaboration

Continuously improving and detailing a plan as more detailed and specific
information and more accurate estimates become available as the project
progresses, and thereby producing more accurate and complete plans that result
from the successive iterations of the planning process.
®
PMBOK Guide, Third Edition, Glossary

Project Examples
The PMBOK® Guide, Third Edition, notes the following as examples of projects.
• Developing a new product or service
• Effecting a change in structure, staffing, or style of an organization
• Designing a new transportation vehicle
• Developing or acquiring a new or modified information system
• Constructing a building or facility
• Building a water system for a community

Page 9
 • Running a campaign for political office
• Implementing a new business procedure or process
• Responding to a contract solicitation

Reasons to Initiate a Project

Projects are usually initiated to help achieve the strategic plan of the organization. Some common reasons
to initiate projects are:
• Market demand: An oil company authorizes a project to build a new refinery in response to
chronic gasoline shortages.
• Organizational need: A training company authorizes a project to create a new course in order to
increase its revenues.
• Customer request: An electric utility authorizes a project to build a new substation to serve a
new industrial park.
• Technological advance: A software firm authorizes a new project to develop a new generation of
video games after the introduction of new game-playing equipment by electronic firms.
• Legal requirement: A paint manufacturer authorizes a project to establish guidelines for the
handling of a new toxic material.

How Projects Differ from Operations

When considering the difference between a project and an operation, think about the unique
characteristics of each.

Project Operation

• Creates its own temporary charter, • Semi-permanent charter,

organization, and goals organization, goals
• Catalyst for change • Maintains status quo
• Unique product or service • Standard product or service
• Heterogeneous teams • Homogeneous teams
• Start and end date • Ongoing

Projects can arise from operations. For example, upgrading an assembly line with new equipment to
speed up the development of widgets could be a project born out of an operation. The widget assembly
line is an operation (the ongoing development of widgets) and the new equipment upgrade is a project
(the temporary — as short as possible — installation of the new equipment).

Page 10
1-3: What Is Project Management?
Project management is a combination of the following:
• Roles and responsibilities of individuals assigned to the project
• Organizational structure that sets out clear reporting arrangements
• Set of processes used to deliver the required outcome
Project management ensures that everyone involved knows what is expected of him, and helps to keep
time, cost, scope, quality, and the needs and expectations of stakeholders under control.
The following pages will cover:
• Defining Project Management
• Applications of Project Management
• Project Management Rigor
• How Project Management Differs from Other Types of Management
• Project Management Hierarchy
• Organizational Benefits of Project Management
• Corporate Trends Drive the Demand for Project Management Services
• Project Management Training
• Project Management Certification
• Project Management Career Benefits

Page 11
Defining Project Management
The use of formal project management has increased dramatically, beginning in the latter half of the
twentieth century. It has evolved because of the successes, failures, and lessons learned when
organizations have undertaken large, difficult to define, complex, and lengthy challenges. Projects today
would be much more difficult to manage using only traditional organizational structures and management
methods.
The definition of project management as found in the PMBOK® Guide, Third Edition, is given below.

Definition: Project Management

The application of knowledge, skills, tools, and techniques to project activities to
meet the project requirements.
®
PMBOK Guide, Third Edition, Glossary

Applications of Project Management

Project management is a universal discipline that delivers consistent, predictable, and repeatable results.
Project management methods can be applied to any project regardless of size, budget, or timeline.
Consider the differences in the size, budgets, and timelines of the following projects:
• Designing a mechanical device
• Managing a marketing campaign
• Building a bridge
• Putting a satellite into orbit
• Setting up an e-commerce website on the Internet
The discipline of project management can be applied to each of these projects.

Project Management Rigor

The level of rigor and formality with which the project management team applies project management
processes depends on a number of variables, which include:
• Importance of the project
• Difficulty of the project
• Experience with the project type
• Size of the project
• Risk factors in the project

How Project Management Differs from Other Types of Management

There are several approaches to management used by industry today, and it is important to distinguish
how project management differs from other types of management.
Project management changes the status quo in a temporary, proactive way that fulfills the strategic plan
on an incremental basis, improves day-to-day operations, and avoids reactive crisis by managing risk.

Page 12
If an organization is interested in producing something new in a planned, systematic, and proactive
manner, project management is the appropriate type of management to employ.

Management Type Definition Comparison to Project

Management

Focuses on setting a strategic Strategic management focuses

plan and achieving a long-range on the what, where, and why;
Strategic Management
vision/mission in an ongoing, the focus of project management
proactive way. is the how and when.

Provides an ongoing focus on Operations management focuses

managing and maintaining the on the routine; the focus of
Operations Management
day-to-day status quo in a project management is change.
recurring, proactive way.

Focuses on fighting fires by Crisis management is reactive in

fixing the status quo in a nature; project management is
temporary, reactive way when it proactive in nature.
breaks or malfunctions. Crisis
Crisis Management
management is not a formally
accepted type of management,
but in reality is practiced by
many organizations.

Project Management Hierarchy

Project management is carried out within a hierarchy of management activities. This hierarchy is made up
of the following elements.
• Strategic plan: A document that describes an organization's fundamental goals and objectives,
and the strategies that will be employed to address them
• Portfolio: A collection of projects and programs that are carried out to meet strategic objectives
• Program: A group of related projects managed in a coordinated way to obtain benefits and
control not available from managing them individually
• Project: A temporary endeavor undertaken to create a unique product, service, or result
• Subproject: A smaller portion of the overall project created when a project is subdivided into
more manageable components or pieces
The organization's strategic plan is what drives the portfolio of projects and their funding. It lists the
organization's strategic objectives and the strategies that will be used to address them. Each strategy gives
rise to one or more programs or projects that will contribute to accomplishing the objectives.
The project portfolio represents the entire range of project-related investments that the organization is
planning to make within the period up to the investment horizon, which may be several years.
Related projects can be managed as a program with a program manager at the head of a group of
project managers. This allows the program manager to ensure that any dependencies among the projects
are closely monitored, and that any necessary schedule or resource adjustments can be coordinated among
the affected member projects.

Page 13
Project managers are focused on their own project's deliverables, schedule, budgets, and resources.
Subprojects are portions of projects that can be outsourced or sub-contracted out to vendors or to internal
specialist teams. Such delegated efforts have their own statements of work, governance, plans, oversight,
resources, and project management processes.

Organizational Benefits of Project Management

Many benefits of successfully implementing project management have been identified. Common
management principles such as quality management, strategic planning, and customer focus are
recognized as critical success factors (CSFs) for businesses. Project management incorporates these
principles and, when it is applied effectively, it delivers the following organizational benefits:
• Accomplishment of strategic objectives
• Increased capability to measure and improve project performance
• Improved customer focus and alignment
• Maximized value of project investments
• Improved ability to control project scope
• Optimized use of organizational resources
• Improved ability to manage risk
• Effective detection and management of issues
• Improved time-to-market
• Compliance with regulations and standards

Corporate Trends Drive the Demand for Project Management Services

Some examples of corporate trends that create the need for effective project management include:
• Corporate globalization
• Increasing focus on customer relationship management
• Adoption of enabling technologies to transform business operations
• Increasing technical integration of business processes with business partners
• Downsizing, mergers, and reorganizations
• Sophisticated customers requiring high-end quality goods and services
• Multinational projects requiring standard processes to manage projects
• Constant technical growth

Project Management Training

These corporate trends have given rise to the need for a new training paradigm for project managers.
The current business environment demands a unique set of requirements for project management skills.
Therefore, it is necessary for project managers to transcend boundaries by acquiring project
management, business management, and technical skills that will allow them to:
• Define, plan, and control the project

Page 14
 • Manage stakeholder expectations
• Deliver the project on time and within budget
Given the importance of effective project management, many companies clearly understand the need for
training. Companies provide opportunities for on-the-job training and access to more formal training,
such as this program. Project assignments are made with the goal of providing new and necessary
experiences for project managers.
Some companies are not investing in project management training because of resource constraints. Often,
it is the responsibility of project managers to take control of their careers and to seek opportunities for
self-improvement. Again, such opportunities may be presented by internal job assignments or external
training opportunities.

Project Management Certification

There are many organizations offering project management training and certification. The Project
Management Institute, PMI®, is the recognized leader for project management information, with over
150,000 members worldwide--its membership has grown at roughly 30% per year in recent years.
PMI® offers a Project Management Professional (PMP®) certification. There are over 100,000 PMP®
certified project managers worldwide, and it is the most respected and universally recognized credential
in the project management profession. Check the PMI® web site at www.pmi.org for more information.

Project Management Career Benefits

The current recognition of project management as a profession and its growth potential make project
management a very attractive career option. Additionally, the standards of project management are widely
accepted, ensuring that project management skills and knowledge are transferable across multiple
industries.
The benefits for individuals pursuing project management as a career are numerous. These benefits
include:
• Potential for future leadership positions
• Visibility of project results
• Opportunity to build a reputation and network

Page 15
1-4: Project Manager Roles and Responsibilities
Project manager roles and responsibilities may vary between projects, but the project manager is always
the person responsible for accomplishing the project objectives.
Managing a project includes:
• Establishing clear and achievable objectives
• Identifying the product or service requirements needed to meet the project objectives
• Balancing the competing demands for quality, scope, time, and cost
• Adapting the specifications, plans, and approach to the different concerns and expectations of the
various stakeholders
The following pages will cover:
• Defining the Project Manager
• Responsibilities of a Project Manager
• Managing Project Constraints
• How Stakeholders' Needs and Expectations Affect the Triple Constraints
• Decisions Faced by Project Managers
• Managing Stakeholders' Needs and Expectations
• Negotiating
• Accomplishing Project Objectives
• Common Project Manager Primary Tasks
• Project Manager Areas of Expertise
• Project Manager Ethics

Page 16
Defining the Project Manager
The PMBOK® Guide, Third Edition, provides the following definition of a project manager.

Definition: Project Manager

The person assigned by the performing organization to achieve the project
objectives.
®
PMBOK Guide, Third Edition, Glossary

This definition is not very specific on its own, but combining it with the definition of project
management creates a more complete definition. The project manager must have a specific set of skills
to manage the project activities so that the requirements of the project are met.
Project Manager: The individual responsible for applying knowledge, skills, tools, and techniques to
project activities to achieve project objectives.
Note: This is not the official PMBOK® Guide definition, but it does combine two PMBOK® Guide
definitions in order to create a more comprehensive one.

Responsibilities of a Project Manager

The project manager must apply a large variety of skills, tools, techniques, and knowledge. All of these
must be integrated to manage project work within given constraints in order to fulfill the expectations of
stakeholders.
The project manager has many roles and responsibilities for a project. Key responsibilities include:
• Managing project constraints
• Managing project decision elements
• Managing stakeholder needs and expectations
• Negotiating
• Accomplishing project objectives

Managing Project Constraints

This Triple Constraint Model illustrates how the project management constraints of time, cost, and
scope and quality interact and change over the life of a project. The project manager's primary
responsibility is to integrate all aspects of the project to manage this interaction. The project manager
integrates knowledge, skills, tools, and techniques to manage these constraints in order to keep them
aligned with stakeholder needs and expectations.

Page 17
A change in one area of the project affects other areas. The project manager's key role is to manage the
effect of increasing the emphasis on one of the project constraints by managing the potential sacrifice of
performance in another.
For example, a scope change may affect cost or product quality. These interactions may often require the
project manager to make a trade-off among project objectives to derive the best solution.
Influences that create the need to compromise or make trade-off decisions include:
• Politics
• Staff morale
• Senior management prerogatives
• Client preferences
• Satisfaction issues

How Stakeholders' Needs and Expectations Affect The Triple Constraints

Project constraints of time, cost, and scope and quality are influenced by the stakeholder needs and
expectations from the center. Identifying the parameters that are most flexible for the stakeholders helps
the project manager satisfy stakeholder needs by relaxing less important constraints in order to hold firm
on those that are more important.

Page 18
Decisions Faced by Project Managers
Successful project management requires the project manager to establish and maintain project stability.
This is accomplished by making sound decisions.
Examples of the types of decisions the project manager faces are:
• Determining whether or not a change in one project constraint (cost, time, scope and quality)
affects another, and to what extent
• Determining how a change impacts the rest of the project activities
• Deciding whether adding or reallocating existing resources solves scheduling problems
• Determining how to best persuade stakeholders to accept changes or modifications to the project
• Interacting with the team members in ways that respect the differences in their cultures,
personalities, needs, and motivations
• Selecting and implementing corrective actions
• Identifying and managing project risks

Managing Stakeholder Needs and Expectations

In addition to the sponsor, project manager, and project team, many people within the performing
organization, the customer's organization, and regulatory or industry-specific groups may be participating
in or affected by a project. Collectively, these individuals are called the project's stakeholders.

Definition: Stakeholder
Person or organization (e.g., customer, sponsor, performing organization, or the
public) that is actively involved in the project, or whose interests may be positively
or negatively affected by execution or completion of the project. A stakeholder
may also exert influence over the project and its deliverables.
®
PMBOK Guide, Third Edition, Glossary

Before a project plan can be prepared, it is important to understand and document stakeholder needs and
expectations.
A successful project is one that meets the stakeholders' requirements and expectations. Managing the
expectations of the stakeholders is another key responsibility of the project manager. The project manager
must be aware of the stakeholders' expectations at all times (since they do fluctuate), and ensure that the
project plan continues to adapt to satisfy them.

Negotiating
In most organizations, project managers work with resources from many different areas. These resources
are generally borrowed from functional managers and sought by other project managers within the
organization. Negotiating for those resources is a skill that project managers need to develop.
In a similar vein, project managers are constantly balancing the trade-offs to the Triple Constraints. In
order to adapt to changing circumstances and stakeholder needs, the project manager must be able to
effectively negotiate with stakeholders.

Page 19
Effective negotiating requires understanding each party's interests, and creating a consensus around a
compromise solution that offers the maximum benefit for each participant and for the community of
stakeholders as a whole.
Effective negotiating also involves recognizing and marshalling sources of organizational power, and
balancing the use of these sources in order to ensure that all stakeholders are committed to the solution.

Accomplishing Project Objectives

One of the most important project management activities that the project team performs during initiation
is defining the project success criteria, or the project objectives. It is these objectives that the project
manager must satisfy in order to succeed. The accomplishment of these project objectives, whether they
are related to cost, schedule, scope, or quality, is the job of each project manager. Project performance is
periodically evaluated against these objectives using appropriate metrics. This means that the project
manager must stay focused on ensuring that the objectives are clear and stable, and that all project work
contributes to meeting them.
Any changes in stakeholder needs or expectations should be reflected in changes to the project objectives.
These, in turn, propagate changes to the project management plan documents, which drive how the
project is executed in order to achieve the new objectives.

Common Project Manager Primary Tasks

The project manager's primary tasks will differ based on the individual's industry, the organizational
structure, or the project.
These tasks can include:
• Clarifying and controlling the project scope
• Developing a project plan that is executable and will achieve the desired results
• Setting priorities
• Acquiring and allocating resources
• Creating and selling a vision
• Motivating the project team
• Developing an integrated change control system

Page 20
 • Communicating with stakeholders
• Selecting and using appropriate tools and techniques for each project management process
• Ensuring compliance with regulations, state and federal laws, organizational policies, and
procedures
• Establishing and maintaining quality
• Managing project risks
• Maintaining team harmony
• Resolving issues

Project Manager Areas of Expertise

Knowing how to effectively apply knowledge, skills, tools, and techniques to a project is not sufficient for
effective project management. According to the PMBOK® Guide, Third Edition, the project manager and
project team need to understand and use knowledge and skills from at least five areas of expertise.
These areas of expertise include:
1. Project Management Body of Knowledge
2. Application Area Knowledge, Standards, and Regulations
3. Understanding the Project Environment
4. General Management Knowledge and Skills
5. Interpersonal Skills
These five areas are explored further on the following pages.

Areas of Expertise Needed by the Project Team, PMBOK® Guide, Third Edition, Figure 1-2

Page 21
1. Project Management Body of Knowledge
The Project Management Body of Knowledge (PMBOK®) is the collection of all best practices and new
ideas involving the managing of project work. It includes proven practices and methods, as well as
innovations in project management that are continually emerging. As such, the body of knowledge is
constantly growing and evolving.
The PMBOK® Guide is a subset of this body of knowledge.

Areas of Expertise Needed by the Project Team, PMBOK® Guide, Third Edition, Figure 1-2

2. Application Area Knowledge, Standards, and Regulations

Application area skills are extensions to the standard practice of project management; these skills are used
to address the uniqueness of a particular project, industry, or context. One common example is the
specific nature of the construction industry and its dependence on contractors. As a result, the common
knowledge and practice of procurement in construction does not apply to all categories of projects.

Definition: Application Area

A category of projects that have common components significant in such projects,
but are not needed or present in all projects. Application areas are usually defined
in terms of either the product (i.e., by similar technologies or production methods)
or the type of customer (i.e., internal versus external, government versus
commercial) or industry sector (i.e., utilities, aerospace, information
technologies). Application areas can overlap.
®
PMBOK Guide, Third Edition, Glossary

Each application area has its own set of accepted standards and regulations. For example, the standards
and regulations required for the construction industry are different from those required for the
pharmaceutical industry.

Page 22
Areas of Expertise Needed by the Project Team, PMBOK® Guide, Third Edition, Figure 1-2

3. Understanding the Project Environment

There are many aspects of the project environment that should be considered, including:
• Cultural and social environment
• International and political environment
• Physical environment
Projects are performed within organizations that are composed of people from all walks of life and
cultural and political backgrounds. Project managers need to recognize this, and failure to do so could
result in the project manager flying against corporate norms for behavior while trying to achieve the
project objectives, and in continually encountering roadblocks to success.
Managers of projects with team members from different parts of the world have an even greater
challenge: they must observe international customs and norms, in addition to overcoming the physical
obstacles of space and time, in managing their projects. An understanding of the entire scope of the
working environment for the project is a key to project success.

Areas of Expertise Needed by the Project Team, PMBOK® Guide, Third Edition, Figure 1-2

Page 23
4. General Management Knowledge and Skills
General management knowledge and skills are the foundation for building project management skills.
They refer to all the planning, organizing, staffing, executing, and controlling that an organization needs
in order to function on a daily basis.
Specific management skills required include:
• Financial management and accounting
• Purchasing and procurement
• Sales and marketing
• Contracts and commercial law
• Strategic planning, tactical planning, and operational planning
• Organizational structures and personnel administration
o Health and safety practices
o Information technology

Areas of Expertise Needed by the Project Team, PMBOK® Guide, Third Edition, Figure 1-2

5. Interpersonal Skills
Like all managers, project managers achieve results by directing the efforts of others. The ability to do
this and the level of effectiveness achieved will often determine the success of the project. Specific
interpersonal skills required include:
• Effective communication skills
• Influencing skill
• Leadership skills
• Motivational skills
• Negotiation and conflict management skills
• Problem solving skills

Page 24
Areas of Expertise Needed by the Project Team, PMBOK® Guide, Third Edition, Figure 1-2

Project Manager Ethics

Ethics are not categorized as a skill or knowledge, but as a critical component of successful project
management. PMI® requires project managers to agree to certain standards of ethical behavior. This
provides a tremendous benefit to organizations using PMI® certified project managers, because it ensures
that project managers are aware of the ethical standards in the choices they make in managing projects.
Project managers must adhere to this commitment to ethics in all aspects of managing the project.
Project managers commit to making ethical choices in everyday activities such as:
• Protecting company information and enforcing the Economic Espionage Act
• Maintaining and using business courtesies
• Supporting federal anti-trust laws
Trust and respect are critical when the project manager must:
• Influence stakeholder decisions on the various aspects of projects
• Make unpopular decisions
• Manage everyday team operations

Page 25
1-5: Organizational Structures
There are many different types of organizations, for example, corporations, government agencies, and
healthcare providers. Within each one of these organizational types lives a structure and a culture.
Furthermore, unique project management structures exist as well.
Projects are usually part of a larger organization such as a corporation or professional association. The
systems, cultures, styles, and structures of the organization influence the project. The following pages
describe the environment in which projects operate, with the goal of gaining a solid understanding of the
project management discipline.
The following pages will cover:
• The Spectrum of Organizational Types
• Organizational Structures and Their Impact on Project Management
• Organizational Influences on Projects
• Organizational Culture, Values, and Styles
• The Project Management Office (PMO)
• The Role of the PMO
• Project Management System

Page 26
The Spectrum of Organizational Types
Decision-making and resource allocation in projects are highly dependent on the structure of the
performing organization. Organizational structures exist on a spectrum between non-project-based and
project-based organizations.
Non-Project-Based Organizations
These are organizations whose operations do not consist primarily of projects and tend not to have
management systems in place to facilitate project management. Factories and supermarkets are good
examples of non-project-based organizations.
Project-Based Organizations
These are organizations whose operations consist mainly of projects and which tend to have management
systems in place to facilitate project management. Construction companies are a good example of project-
based organizations.
There are two types of project-based organizations:
1. Organizations that derive revenue from projects for others under contracts, for example, Federal
government contractors, building contractors, advertising agencies, and professional services
consulting companies.
2. Organizations that have adopted management by projects. Many organizations are involved in
highly dynamic business activities. Examples are new product development companies and
government agencies (particularly those that make frequent changes to programs, such as
organizations in the Health and Human Services area).

Organizational Structures and Their Impact on Project Management

The structure of an organization has an impact on project management. Organizations can be classified
into the following structures:
• Functional
• Matrix
• Projectized
Organizational structures cover the spectrum with regard to the project manager's authority and ability to
operate autonomously. The organizational infrastructure should give the project manager clear guidance
regarding performance expectations and achieving successful performance within the organization.
This guidance starts with the basic description of the project manager's position, but extends to include
career pathing, competency models, training and development opportunities, certification, and rewards

Page 27
systems. Project managers should work with the organization to understand how they can continually
improve and contribute to it.
The following pages describe the organizational structures listed above. Key aspects of each structure that
may influence the project as well as the level of the project manager's authority are noted.

Organizational Influences on Projects

The chart below summarizes key project-related characteristics of the different types of organizational
structures. Notice the level of authority a project manager has in relation to the organizational structure. In
most cases, project managers must work within an existing structure and are unable to change it. Knowing
the influences of the organizational structure on project management helps formulate the project
approach, and in particular how communications, staffing, risk, and procurement are managed.

Organization Matrix
Structure
Functional Projectized
Weak Balanced Strong
Project
Matrix Matrix Matrix
Characteristics

Project Little or Limited Low to Moderate High to

Manager’s None Moderate to High Almost Total
Authority

Resource Little or Limited Low to Moderate High to

Availability None Moderate to High Almost Total

Control of the Functional Functional Mixed Project Project

project budget Manager Manager Manager Manager

Project Part-time Part-time Full-Time Full-time Full-time

Manager’s Role

Project Part-time Part-time Part-time Full-time Full-time

Management
Administrative
Staff

Organizational Structure Influences on Projects; PMBOK® Guide, Third Edition, Figure 2-6

Page 28
Organizational Culture, Values, and Styles
Other key influences on how projects are managed within an organization are the culture, values, and
style of an organization. To be most effective, the project manager should understand, identify, and
operate within the expectations dictated by the organization’s culture and style. Additionally, a deep
understanding of the values of the organization will help the project manager identify the factors that the
organization perceives as most important to its success.
The culture and style of an organization are reflected in factors such as:
• Shared values and norms
• Policies and procedures
• View of authority relationships
• Work ethic and hours
Shared Values and Norms
Examples of shared values and norms include how openly staff deal with conflict, whether ideas are
evaluated on the basis of their intrinsic merit or on the status of their sponsor, whether rewards and
sanctions are allocated objectively, and to what degree management solicits the opinions of line staff
regarding the business.
Policies and Procedures
Policies and procedures may be strict and rigidly enforced, or haphazard and ignored.
View of Authority Relationships
Authority relationships may be strictly interpreted according to the organization chart, or the organization
chart may often be ignored in favor of charismatic middle and senior managers who charm and excite
staff into focusing on their priorities at the expense of their less appealing peers.
Work Ethics and Hours
Work ethics may vary, and are sometimes not reflected by strict adherence to a formal schedule. A more
accurate indicator is the willingness of staff to expend extra effort, especially on short notice, to correct
problems or complete challenging assignments. Another indicator is the staff’s attentiveness to quality
standards, in particular the average level of quality of the deliverables, and their conformance to standards
on the first pass.
To summarize how culture, values, and styles of an organization influence a project:
• Organizations that demonstrate openness to new ideas and the ability to resolve conflicts
constructively; to follow and improve policies and procedures; to respect assigned authority; and
to meet the challenges posed by extremely difficult circumstances have the greatest chance of
meeting project objectives.
• Organizations that are tolerant of poor quality, dismissive of innovation, arbitrary in following
policy and ineffectual in resolving conflicts will demonstrate the poorest project performance and
experience the greatest difficulty improving it.

Page 29
The Project Management Office (PMO)
A Project Management Office (PMO) is an organization that is established to serve project performance
needs, primarily in the area of project management. A PMO ensures that projects are aligned with the
corporate strategy and that the organization is operating at peak efficiency, utilizing repeatable processes
to yield predictable results.

Definition: Project Management Office (PMO)

An organizational body or entity assigned various responsibilities related to the
centralized and coordinated management of those projects under its domain.
The responsibilities of a PMO can range from providing project management
support functions to actually being responsible for the direct management of a
project.
PMBOK® Guide, Third Edition, Glossary

The Role of the PMO

Although any organizational structure can implement a PMO, it is more common in some matrix and
most projectized organizational structures. However, a PMO's function within each type of organizational
structure may vary widely. Depending on the needs of an organization, a PMO can range in scope from a
small office that serves to provide training and templates to a large department that touches all aspects of
the business.
Some functions that different PMOs may execute in different styles include:
• Standards setting and compliance monitoring. The PMO has developed standard processes
and templates that each project manager must use to ensure consistency in managing and
executing project activities and reporting. The PMO also acts as the governance group with
respect to these standards.
• Coaching and mentoring. The PMO serves as a resource for mentors and coaches for the project
managers within the organization. Typically, the members of the PMO are senior project or
program managers who possess a wealth of knowledge that can be leveraged to assist other
project managers.
• Central reporting function. Here, the PMO acts as the central repository for all project
information in the organization. Executive management can then look to a single point-of-contact
for all project information. This function is often tied to the project portfolio management
function.
• Providing a pool of project managers "for hire." Since the PMO is generally staffed with
senior project or program managers, they can be leveraged to cover any gaps in projects that may
occur due to illness, vacation, poor performance, or organizational need.

Page 30
Project Management System
A project management system provides a framework for launching and implementing project activities
within a parent organization. Each organization that implements project management practices should
have a project management system, which is the set of tools, techniques, methodologies, resources, and
procedures used to manage a project. The project management system may be formal or informal, and
includes the set of processes and the related control functions.
Use of this system should be outlined in the project management plan, and will vary depending on many
factors, including:
• Application area
• Organizational influence
• Complexity of the project
• Availability of existing systems
A PMO may have another function in the organization: managing the project management system to
ensure that the project management data can be consistently interpreted and will be current and correct. It
may also be responsible for generating analyses or reports based on the system; for coaching project
managers on the more sophisticated techniques required to use it; and for administering support to ensure
the internal consistency and integrity of its data.

Page 31
1-6: Project Stakeholders
Managing stakeholder expectations and their influence over project outcomes is one of the most important
things a project manager can do. Knowing exactly who the project's stakeholders are and being able to
identify their roles is part of understanding the "environment" of the project.
The following pages will cover:
• The Project's Stakeholders
• Identifying Project Stakeholders
• Internal vs. External Stakeholders
• Common Project Stakeholders
• The Project Sponsor
• Identifying Stakeholder Needs
• Gathering Stakeholder Requirements and Expectations
• Stakeholder Influence
• Managing Stakeholder Influence
• Increasing Stakeholder Commitment
• Reducing Stakeholder Impact

Page 32
The Project's Stakeholders
Project stakeholders have one or more of the following characteristics:
1. They participate in the project.
2. They influence the objectives or outcomes.
3. They have interests that are affected by the project's execution or its result.
The diagram below illustrates how all the participants on the project, including the project sponsor,
belong to the group considered the project's stakeholders. However, not all stakeholders are participants
because some stakeholders are not intended to benefit from the project nor are they required to perform
support activities for it. An example might be members of the organization whose span of influence will
be affected by the new product or service that the project will deliver.

Stakeholder Relationship to Project

Adapted from PMBOK® Guide, Third Edition, Figure 2-5

Identifying Project Stakeholders

Knowing who the stakeholders are and determining their requirements for a project makes it easier to
manage stakeholder expectations, a key element in managing a project.
In order to identify the stakeholders for your project, begin by asking the following questions:
• Who will contribute to this project?
• Who will be affected by this project?
o Are they considered internal or external?
o Are they affected in a positive or a negative way?

Page 33
Internal vs. External Stakeholders
One definition of internal stakeholders is those who participate in the project. External stakeholders are
those who do not actively participate in the project.
Another definition would be to classify stakeholders within the same organization as internal, whether
they participate in project activities or not. External stakeholders are those who are not members of the
organization.
Whether or not the participants are within the performing organization does not affect the need to analyze
their influences, though it will certainly play a part in determining how to address them. For example, if a
project to build a new highway on-ramp is in a developed area, the neighboring landowners and even
tenants have rights and interests that must be addressed through a public hearing process.

Common Project Stakeholders

Some common project stakeholders are listed and described below:
• Project manager: Individual responsible for the successful completion of the project
• Project team members: Individuals who perform the required project tasks
• Customer: Individual who determines the project deliverables (requirements) and provides
funding; often represents, or is, the end- product or service user
• Performing organization: Enterprise most directly involved in doing the work of the project
• Central staff: Group that provides basic functions such as:
o Procurement
o Contracts
o Legal services
o Human Resources
• Project sponsor: Person in management who approves and supports the project
Other stakeholders include functional managers, government agencies/regulators, suppliers and
vendors/subcontractors, resource managers, and senior management.

The Project Sponsor

The project sponsor is the person (or group) with formal authority. Sponsor authority comes from the
person or group's title and position within the organization.
Project sponsors communicate the importance of the project to key upper managers and relay
management support and commitment back to the team. They help refine team missions and goals,
identify deficiencies in project plans, challenge team thinking, provide resources, review team progress,
and obtain help from senior management. A project charter (discussed later in the course) should be
written by the project sponsor for each project. Project sponsors can have a tremendous impact on the
success of key projects.

Page 34
Identifying Stakeholder Needs
Once the stakeholders have been identified, ask the following questions about each one:
• What position does this person hold?
• Why is he or she interested in this project?
• How does the project affect the scope of his or her control?
• What authority does he or she have?
• What decisions will he or she influence?
Not all stakeholders in a particular project are supportive. Many times, the key stakeholders have
opposing interests that need to be recognized. As an example, some of the stakeholders of the highway
on-ramp project may include property owners who will benefit from increased access to transportation
routes, while others may feel that the aesthetic appeal of the neighborhood is the primary source of their
land's value, and that it will be compromised by the project.

Gathering Stakeholder Requirements and Expectations

As illustrated earlier in the course by the Triple Constraint model, the constraints of time, cost, and scope
and quality are influenced by the stakeholder needs and expectations. There is a two-fold message to be
extracted here: (1) Project stakeholders need to be identified and their requirements determined; and (2)
Stakeholder expectations need to be managed throughout the project.
There are many techniques that project teams use to gather stakeholder requirements. Some of these
techniques are listed below.
• Task analysis
• White papers
• Focus groups
• Joint Application Development (JAD) sessions
• Interviews
• Surveys
• Prototyping
• Rapid Application Development (RAD) workshops

Stakeholder Influence
The stakeholders' responsibilities and authority on a project affect their ability and tendency to influence
the project objectives and outcome. For example, if the marketing department manager fails to provide
adequate resources for a sales and marketing project, insufficient requirements could result, leading to
unsuccessful outcomes.
Stakeholders' influence can range from providing the funding for the project (sponsor), to performing the
project work (project team) to being the recipient of the project's product (customer). Depending on his
role in the project, a stakeholder can exert varying degrees of influence on the project's outcomes.
Stakeholders can influence or impact the project in one of three ways.

Page 35
 1. Attempting to change the scope, objectives, or project processes to improve the benefit to them,
or reduce its negative impact on them
2. Granting or withholding resources
3. Actively lobbying other stakeholders to take one of the aforementioned actions
Dealing with all these influences and impacts is the responsibility of the project manager and project
sponsor, and requires them to have substantial communication and negotiation skills.

Managing Stakeholder Influence

Managing stakeholder expectations and their influence over project outcomes is one of the most important
things a project manager can do.
Important elements in managing stakeholder influences include:
• Determining how important each stakeholder's influence is to the project's success
• Determining what interests each stakeholder has that the project will or could affect
• Determining whether the stakeholder is supportive of, neutral toward, or opposed to the effects of
the project
• Understanding what the project would need in order to improve the commitment of neutral
stakeholders or reduce the impact of those opposed
• Understanding which stakeholders might be leveraged to influence neutral or unsupportive
stakeholders to increase their commitment or to reduce their negative impact
• Designing strategies for managing stakeholder influence in order to increase the commitment or
reduce the negative impact of neutral or opposed stakeholders
• Designing communications processes to ensure that:
o Stakeholders' interests and positions are known.
o The project's benefits to and impact on them is clearly communicated.
o The effectiveness of any strategies for managing stakeholder influence is monitored.
o The commitment of supportive stakeholders is maintained.

Increasing Stakeholder Commitment

A variety of skills in the areas of communication and negotiation are required to increase stakeholder
commitment. For example, it may be appropriate for the project manager to lobby the project sponsor in
order to increase the authority of a stakeholder in the governance of the project; for example,
recommending that the stakeholder be granted a seat on a steering committee. To accomplish this, the
project manager must be able to communicate the necessity of the change and its benefit to the sponsor.
The project manager may also need to identify and address the sponsor's concerns about sharing influence
with the stakeholder.
Another strategy might be to recommend that some portion of the project's scope be modified to benefit
the stakeholder specifically. This involves understanding the interests underlying the stakeholder's
position, so that changes can be selected that have the least impact on the project's objectives. Often, such
changes differ widely from the changes the stakeholder initially requested.

Page 36
Reducing Stakeholder Impact
To minimize the impact of a rigidly opposed stakeholder when attempts to increase the stakeholder's
commitment using other strategies have failed, the project manager could recommend making changes to
the project (or even to the organization, in extreme circumstances) to reduce the negative impact on the
stakeholder's area of authority.
For example, suppose that a project manager requires the participation of a specialized team, but the
senior manager who oversees the department to which the team belongs is opposed to the project, has
blocked their participation, and has been unresponsive to the project manager's efforts to increase his
commitment. If no substitute resources are available, the project manager could attempt to reduce the
stakeholder's impact by lobbying either to have the team reassigned to a department whose manager is
more supportive or to have the existing team split into two teams, one of which is reassigned.
However, proposing a change to the organization is a strategy of last resort, since it requires significant
negotiating and communicating skills, involves applying substantial leverage from the other stakeholders,
and is likely to further polarize the opposition of the stakeholder. As a result, the other stakeholders are
usually reluctant to commit their support.

Page 37
1-7: Project Life Cycles
Projects can be divided into phases for better control. The completion and approval of one or more
deliverables characterizes a project phase. Collectively, all of a project's phases are known as the project
life cycle.
The following pages will cover:
• Defining Project Phase
• Common Project Phases
• Project Life Cycles
• Phases and Life Cycles
• Generic Project Life Cycle
• Phase Completion Requirements
• Project Life Cycle Approaches
• Project Life Cycle Examples
• Selecting a Life Cycle Model
• Product Life Cycles

Page 38
Defining Project Phase
In order to manage the project's complexity, the project work is divided into phases, each of which
transforms the outputs from the prior phase in a well-defined way. At the end of each phase, the resulting
deliverables can be assembled and verified for correctness and completeness before the next phase of
work is begun.
To manage risk, phases are used to give management adequate visibility into the project's performance.
Dividing a project into phases permits sponsors to have better control over the project by:
• Incrementally evaluating the project's progress against its objectives. This allows management to
take corrective action whenever the project strays from its plan, and to cancel the project and
minimize the lost investment whenever a project persistently exhibits poor performance without
adequate improvement over time.
• Evaluating the quality of deliverables, both interim and final, to ensure that the project is making
adequate technical progress.
• Authorizing the incremental allocation of resources for the next phase, or the formal closure of
the project, when performance is satisfactory.

Definition: Project Phase

A collection of logically related project activities, usually culminating in the
completion of a major deliverable. Project phases (also called phases) are
mainly completed sequentially, but can overlap in some project situations.
Phases can be subdivided into subphases and then components; this hierarchy, if
the project or portions of the project are divided into phases, is contained in the
work breakdown structure. A project phase is a component of a project life
cycle. A project phase is not a project management process group.
PMBOK® Guide, Third Edition, Glossary

Phases are most often used to create unique deliverables. For example, the requirements phase defines
the basic requirements of what the product will do, while the subsequent design phase will determine
how best to fulfill those requirements. The requirements phase will generally produce requirements
documents, which the design phase transforms into design specifications. A subsequent construction
phase then transforms the design specifications into the components of the product or service.

Page 39
Common Project Phases
Listed below are some types of common project phases for specific industries.

Industry Phases

• Formation
• Ramp Up
Manufacturing • Production
• Phase Out
• Final Audit

• Start-up
• Definition
Engineering
• Main
• Termination

• Planning: Program/Study, Schematic/Preliminary

Design, Design Development, Working Drawings
• Site and Foundations

Construction • Framing/Superstructure and Enclosure

• Mechanical/Electrical/Plumbing
• Rough-in Work and Finishes
• Commissioning

Project Life Cycles

Project life cycles generally define the following:
• When the deliverables are to be generated
Example: A Functional Design phase concludes with the release of a description of the entire
application system's visible behavior, which consists of all the screen displays, reports, and
scheduled events, such as the aging of accounts receivable.
• Who is involved in each phase
Example: In the Testing Phase of many life cycles, a quality assurance team is specified as the
group directing and controlling the execution of test cases and referring the results to the
development team.
• How to control and approve each phase
Example: Each phase concludes with a management review and approval signature of key
deliverables by the governing function. The governing function is usually carried out by a
project-specific or general IT steering committee of key stakeholders who either control
investment or will use the product, or both.

Page 40
 • Which transitional actions at the end of the project are included in order to link the project to
ongoing operations
Example: Technical documentation and training on the newly installed system will be provided.

Phases and Life Cycles

The transition from one project phase to another within a project life cycle usually results in a technical
handoff or other deliverable. A process is followed to review and approve all deliverables before starting
work in the new phase. Performance reviews are often called phase exits, stage gates, Q-gates, or kill
points. These reviews are conducted to determine whether or not the project should continue, and to
identify key triggers for risk. Phases and life cycles allow for Go/No Go decisions.
Risk increases constantly until approval is granted, and any mainline work in succeeding phases that is
conducted without the approval of the prior phase accelerates the increase in risk. However, it is common
to accept some of this risk by initiating work in the next phase before the formal approval to move on is
granted.
The dangers of this include:
• If the project fails to obtain approval to proceed, the resources may not receive payment for the
work they accomplished in the pre-approved phase.
• If there are significant changes requested to the deliverables, any work done based on the
unapproved deliverables may be wasted.

Generic Project Life Cycle

The following graph illustrates a generic project life cycle.

Adapted from PMBOK® Guide, Third Edition, Figure 2-1

Phases are normally sequential and defined by some form of technical information transfer or technical
component handoff. In some project life cycles, sequences of phases may repeat.
Cost and staffing levels are low at the start, peak during intermediate phases and drop off rapidly as the
project draws to a conclusion. It is also common for this rise and fall in resource costs to occur within a
single phase for those specialized resources that are only allocated to that phase. This occurs for quality
assurance resources who perform testing in a project's testing phase.

Page 41
Phase Completion Requirements
Stakeholders who will use the project's product or service generally have the following requirements for
the project deliverables:
• They have passed a quality inspection for both standards and conformity to upstream
specifications.
• They have satisfied one or more independent subject matter experts within their line organization
that the requested functionality is effectively addressed in the deliverables.
Stakeholders who control the investment require that the project deliverables satisfy these requirements:
• They reflect the true condition of the project.
• They demonstrate that the project is proceeding according to the approved plans, or they indicate
that satisfactory corrective actions will allow the project to continue to meet its objectives, despite
changes in circumstances.
When a project shows a significant deviation from the planned scope, budget, schedule, or quality
objectives, both stakeholder groups will need to review and approve any changes in the project plan or the
project objectives that the project manager proposes. This normally takes place during a management
review at phase completion, but it may also occur at any time via a special meeting if the project manager
determines that the circumstances warrant it.

Project Life Cycle Approaches

The project life cycle organizes the work for completing a project. The simplest life cycle breaks the work
into phases that are functionally specialized, for example, putting all the testing in one phase.
This has two major benefits:
• It allows resources to be concentrated efficiently so that specialized resources can be applied for
maximum productivity and quality at minimum cost.
• It allows all the work components to be verified against each other for correctness and
completeness so that missing or incorrect elements can be caught and corrected before further
investment is wasted on them.
A life cycle that uses functionally organized phases also has two major disadvantages:
• There are long intervals between phase completions and, in many application areas, a long
interval between design and testing, so errors that are made at the beginning of the phase are not
detected until much later. This increases the risk of significant wasted effort and rework.
• This approach is inflexible and makes any changes difficult and expensive to incorporate.
The optimal project life cycle is the one that provides the organization of project effort that maximizes the
project manager's ability to manage both the complexity of the work and the project risks at the same
time.

Page 42
Project Life Cycle Examples
There are many project life cycle models and significant variations in structure and naming, even within a
specific application area. The project manager is responsible for selecting the life cycle that best supports
the type of project being managed.
The following graph illustrates a typical sequence of phases in a project life cycle.

Adapted from PMBOK® Guide, Third Edition, Figure 2-3

Waterfall Life Cycle

The oldest of life cycles, and the best known, is the waterfall — a sequence of stages in which the output
from each stage becomes the input for the next. The waterfall cycle is used to show a sequence of "What
.....How" steps that form the specifications of a system.

Waterfall Life Cycle: Advantages and Disadvantages

The waterfall model is well understood, but it is not right for every project. It does not work nearly as
well when building systems for knowledge workers - people at help desks, experts trying to solve
problems, or executives trying to lead their companies into the Fortune 100.
Another problem is that the waterfall model assumes that the only role for users is in specifying
requirements, and that all requirements can be specified in advance. Unfortunately, requirements may
change throughout the process, requiring user feedback and iterative consultation. Thus, several other life
cycle models have been developed.

Page 43
Advantages Disadvantages

Simple milestones Not useful until finished

Clear review points Takes a long time to deliver a usable product

Easily understood Mistakes and changes can cause costs to escalate rapidly

Known and trusted Higher cost to remove errors

Decisions documented Copes poorly with frequent changes

Incremental Life Cycle

The incremental life cycle model divides the product into modules, in which sections of the project are
created and tested separately. The advantage to this is that the project can be completed more quickly if
enough resources are available. The difficulty may come in integrating the separate component
subsystems.
An incremental, prototype-based methodology in increasing use today is the Unified Process, of which
the Rational Unified Process (RUP)™ is a major commercially available version.

Incremental Life Cycle

Incremental Life Cycle: Advantages and Disadvantages

The advantages and disadvantages of the incremental life cycle are listed in the table below.

Advantages Disadvantages

Mini-projects More complex to manage

Balances the allocation of scarce resources Increased risk of miscommunication

Explicitly manages risk Requires a sophisticated architecture

Faster delivery Requires more time to integrate the component

subsystems

Page 44
Spiral Life Cycle
The next generation of life cycle methodologies emphasizes rapid prototyping and customer feedback.
Barry Boehm developed the "spiral model" in the mid 1980s.The main focus of the spiral model is
managing risk through iterative cycles of development and evaluation. In the pure spiral life cycle model,
only one delivery of a working system occurs at the end. Successive prototypes become more and more
elaborate versions of the initial prototype. Each version incorporates more details of the functionality and
corrects defects found in the prior iteration's requirements, design, and implementation.

Spiral Life Cycle

Spiral Life Cycle: Advantages and Disadvantages

The advantages and disadvantages of the spiral life cycle are listed in the table below.

Advantages Disadvantages

Risk reduced Complexity

Critical Success Factors addressed early Delivery expectations must still wait for the conclusion
of the project

Detailed user requirements Heavy user involvement is required to validate each

prototype

Encourages re-use Few practitioners

Validates assumptions and feasibility Risk assessment expertise required

Page 45
Evolutionary Life Cycle
The evolutionary life cycle reflects a strategy for products in which future requirement refinements are
anticipated to evolve, such as software product development. It is also for projects that involve a technical
risk that discourages the full and immediate implementation of the needed capability. This strategy
develops in a series of builds.
It differs from the incremental approach by acknowledging that user needs are not fully understood and
that all requirements cannot be fully defined up front. Requirements are only defined to the extent that
they are known. As additional user needs become known through feedback from previous builds, the
specific requirements for each succeeding build are defined. Product capabilities are increased with the
delivery of each incremental release until the product is complete. Users have early access to product
releases (such as beta software products) and are encouraged to provide performance feedback, which is
used to shape the product as it evolves into its final form.

Evolutionary Life Cycle

Evolutionary Life Cycle: Advantages and Disadvantages

The advantages and disadvantages of the evolutionary life cycle are listed in the table below.

Advantages Disadvantages

Early deployment for business value Sophisticated architecture required

Fast delivery Heavy user involvement

Cash flow advantage Experienced team and management

More adaptable Product tends to perform less efficiently

Room to abandon Needs continuous support and development

Page 46
Selecting a Life Cycle Model
The project manager can use a matrix to compare the different types of life cycles that may be considered
for a specific type of project. Depending on the specific nature of the project being managed, these
columns may be adapted to more accurately reflect project parameters. However, the Risk, Size, and
Team columns are common to all projects.

Life Cycle Requirements Architecture System Risk Size Team

Waterfall Known Known Indivisible Low System New

to
Medium

Incremental Known Known Divisible Low Medium New

to Low

Spiral Unknown Unknown Divisible/ Medium Medium Experienced

Indivisible to Low

Evolutionary Known Unknown Divisible High Medium Experienced

to Low

Product Life Cycles

An area of possible confusion is the difference between the life cycle of a project and the life cycle of a
product. Many different projects may support the same product during the product's life cycle.
To illustrate the difference in the two concepts, here is an example: The product is an electricity-
generating power station. The initial project is to build the power station. After this first project has been
completed, the power station is turned over to the operators, who then use the power station to produce
electricity over the station's lifetime. At the end of the economic life of the power station, another project
may be started — the shutdown and disposal of the station itself.
In reality, most projects are planned with the total life cycle costs in mind. If a little extra time can be
spent designing a more reliable or higher quality product, the savings over the years of operation will
easily outstrip the incremental design costs.
Products are also said to have life cycles, which differ from project life cycles, generally beginning with a
concept and ending with retirement or replacement. Here is an example of a typical product life cycle:
1. Research & Development
2. Market Introduction
3. Growth
4. Maturity
5. Operation
6. Retirement/Withdrawal from Marketplace

Page 47
Summary
The Project Management Framework, as defined by the Project Management Institute (PMI®) in the
PMBOK® Guide, Third Edition, provides a useful set of concepts that help to organize the information
about how projects can be effectively managed. The Project Management Framework section of this
course presented the meaning of these concepts and how they relate to each other in order to provide a
solid foundation for the project management discipline.
Project management is a discipline created in response to the successes and failures of projects that have
been undertaken; it applies knowledge, skills, tools, and techniques to maximize the efficiency of project
operations.
The project manager is the individual responsible for applying the knowledge, skills, tools and techniques
in the management of a project. The project manager has many roles and responsibilities for a project and
should be committed to certain standards of ethical behavior.
Projects are usually part of a larger organization such as a corporation or professional association. The
systems, cultures, styles, and structures of the organization influence the project. Organizational structures
exist on a spectrum between project-based and non-project-based organizations.
A successful project is one that meets the stakeholders' requirements and expectations. The project
manager uses knowledge, skills, tools, and techniques to satisfy stakeholders' requirements for the project
constraints of time, cost, and scope and quality.
Each project is unique, but certain sequences of phases are common. Collectively, these common
arrangements of phases are known as a project life cycle. The project life cycle organizes the work for
completing a project.

Page 48
Concept 2 – Project Management Processes
Introduction
The PMBOK® Guide, Third Edition, specifies 44 project management processes that are used by the
project team to manage a project. These processes have been generally recognized as good practice on
most projects most of the time and they apply globally and across industry groups.
The PMBOK® Guide states that good practice means "there is general agreement that the application of
those project management processes has been shown to enhance the chances of success over a wide range
of projects."
The discussion of this concept:
• Recognizes the key principles of quality and their influence on project management
• Identifies the five Project Management Process Groups as defined by the Project
Management Institute (PMI®)
• Describes the major flows of information and deliverables between the Project Management
Process Groups
• Describes the major deliverables from each of the five Process Groups and how they
interrelate
• Lists and describes each of the nine Knowledge Areas of project management
• Classifies the 44 Project Management processes into the nine Knowledge Areas

Page 49
2-1: Process Overview
The PMBOK® Guide, Third Edition, identifies 44 Project Management processes that are aggregated into
five Project Management Process Groups. The Project Management Process Groups and their constituent
processes are guides for applying appropriate project management knowledge and skills during the
project.
The following pages will cover:
• Definition of a Process
• Project Management Process Groups
• Degree of Project Management Process Rigor
• Project Management Processes and Quality Principles
• Key Quality Initiatives
• The PDCA Cycle
• Mapping the Process Groups to the PDCA Cycle
• Iterative Nature of a Process
• Process Group Interaction
• Interaction Between Project Phases
• Process Group Inputs and Outputs
• Process Flow Within and Between the Process Groups

Page 50
Definition of a Process
The PMBOK® Guide, Third Edition, definition of a process is given below.

Definition: Process
A set of interrelated actions and activities performed to achieve a specified set of
products, results, or services.
®
PMBOK Guide, Third Edition, Glossary

Process Categories
Processes fall into two major categories, project management processes and product-oriented
processes. These processes interact with each other, and the project manager needs to coordinate them so
that project requirements can be completed successfully.
• Project management processes: These processes are used to initiate, plan, execute, monitor and
control, and close a project. They apply to most projects most of the time, regardless of the
application area.
• Product-oriented processes: These processes specify and create the project's product. They are
typically defined by the project life cycle and vary by application area.

Project Management Process Groups

The 44 Project Management processes are aggregated into 5 Project Management Process Groups. The
five Process Groups (listed and described below) have clear dependencies and are performed in the same
sequence on each project, regardless of application area or industry focus.
• Initiating: Defines and authorizes the project or a project phase
• Planning: Defines and refines objectives, and plans the course of action required to attain the
objectives and scope that the project was undertaken to address
• Executing: Integrates people and other resources to carry out the project management plan for
the project
• Monitoring and Controlling: Regularly measures and monitors progress to identify variances
from the project management plan so that corrective action can be taken when necessary to meet
project objectives
• Closing: Formalizes acceptance of the product, service, or result and brings the project or a
project phase to an orderly end
PMBOK® Guide, Third Edition, Section 3.2

Page 51
Degree of Project Management Process Rigor
Project management is accomplished through Project Management processes that receive inputs and then
apply tools and techniques, project management knowledge, and skills to generate outputs.
Project Management processes are performed by the project team. The project manager must work with
the project team to determine the appropriate application of each Process Group, establishing the level of
formality with which each process within each Process Group will be executed.
The level of rigor of the project processes is influenced by the nature of the project, including:
• Complexity of the project
• Overall risk of the project
• Size of the project
• Timeframe of the project
• Level of experience of the project team
• Access to key resources
The degree of rigor of the project processes is also influenced by the nature of the performing
organization, which includes:
• Organizational structure
• Overall level of project management maturity
• Application area
The project manager and the project management team are responsible for determining the degree to
which each process will be formalized, in conformity with organizational policy.
For example, on a project for which the product or service is known or easily visualized, such as the
upgrade of a computer, the team may elect not to perform a great deal of quantitative risk analysis. But,
when the team is working on "bleeding-edge" technology that involves many unknowns and a great deal
of money, the team should take a more rigorous approach to analyzing and managing risk.
The degree of formality of a Project Management process may also change during the project. For
example, at the outset, project risks are greater in impact and number than towards the end, when many
risks may not have materialized, and the effects of errors are smaller. As a result, the Risk Management
processes can be simplified, since most of the risks no longer warrant the same level of effort to analyze
and manage.

Project Management Processes and Quality Principles

The evolution of the Project Management processes has been influenced by key principles of quality,
such as:
• Generating products by using processes
• Using feedback to manage processes
• Satisfying customer expectations
• Improving processes based on their performance

Page 52
Key Quality Initiatives
Understanding how quality processes were developed will give you a better grasp of how the Project
Management Process Groups have evolved. Quality initiatives date as far back as the beginning of the
industrial age. The modern quality movement had its real beginning at the end of World War II, and
numerous quality efforts have been initiated as a result of increased consumer expectations and
competition for high quality products.
For example:
• Total Quality Management (TQM) – A comprehensive and structured approach to
organizational management that seeks to improve the quality of products and services through
ongoing refinements in response to continuous feedback.
• Continuous Quality Improvement (CQI) – An approach to quality management that builds on
traditional quality assurance methods by emphasizing the organization and systems: it focuses on
“process” rather than the individual; recognizes both internal and external “customers”; and
promotes the need for objective data to analyze and improve processes.
• Management by Objectives (MBO) – A structured management technique of setting goals for
any organizational unit.
• Quality Circles – Teams of workers trained in basic problem solving and statistical tools who
select and implement improvement projects within their work groups.
• Six Sigma –- A highly disciplined approach to statistical process control that focuses on
improving processes in order to make products with extremely low occurrence of defects. Six
Sigma ensures that internal processes are running optimally.
Additionally, Walter Shewhart created the Plan-Do-Check-Act (PDCA) cycle. The Plan-Do-Check-Act
(PDCA) cycle is the basic model for the interaction among the Project Management Process Groups.

The PDCA Cycle

The Plan-Do-Check-Act (PDCA) cycle provides a framework for the improvement of a process or
system. It can be used to guide the entire improvement project, or to develop specific projects once target
improvement areas have been identified.
The PDCA cycle design is a dynamic model. The completion of one turn of the cycle flows into the
beginning of the next. Following in the spirit of continuous quality improvement, the process can
always be re-analyzed and a new set of changes can begin.

Plan-Do-Check-Act Cycle

Page 53
 • Plan. A change or a test aimed at improvement. In this phase, analyze what you intend to
improve, looking for areas that hold opportunities for change. The first step is to choose areas that
offer the most return for the effort expended—the biggest bang for your buck. To identify these
areas for change, consider using a flowchart or Pareto chart.
• Do. Carry out the change or test (preferably on a small scale). In this phase, you implement the
change you decided on during the planning phase.
• Check. Check or study the results. In this phase, you ask, “What was learned?” or “What went
wrong?” This is a crucial step in the PDCA cycle. After you have implemented the change, you
must determine how well it is working. Is it really leading to improvement in the way you had
hoped? You must decide on several measures with which you can monitor the level of
improvement.
• Act. In this phase, you will adopt the change, abandon it, or run through the cycle again. If the
change consumed too much time, was difficult to adhere to, or even led to no improvement, you
may consider abandoning the change and planning a new one. However, if the change led to a
desirable improvement or outcome, you may consider expanding the trial to a different area, or
increasing the complexity of the change. This sends you back into the Plan phase.

Mapping the Process Groups to the PDCA Cycle

The graphic below is an enhanced version of the PDCA cycle. It illustrates how the Project Management
Process Groups are mapped to the PDCA cycle.
• The Initiating processes start the cycle and the Closing processes end the cycle.
• The Planning processes correspond to PLAN.
• The Executing processes correspond to DO.
• The Monitoring and Controlling processes correspond to CHECK and ACT.

This cycle of Process Groups repeats during each phase of the project.

Page 54
Iterative Nature of a Process
In addition to exchanging inputs and outputs in a sequence, the Project Management processes also
interact with each other iteratively.
For example, as the Planning processes incorporate elements such as quality, human resources,
communications, risk, and procurement considerations into the overall project management plan, some
original assumptions and plans for scope, cost, and schedule may have to be altered. These changes, in
turn, may also result in further changes to the quality, human resources, and communications plans, and
so on.

Process Group Interaction

Typically, after the Planning processes, the project enters the Executing Process Group. However, while
in the Executing Process Group, the project manager is also monitoring and controlling the project and
feeding status back to the Planning processes as required. Once the project or phase is completed, the
Closing processes begin.
Processes from different groups may occur simultaneously. For example, Planning continues throughout
the project, almost to the end, though it is most intensive in the early stages. Some of the Monitoring and
Controlling activities begin very early, while the majority of this effort is concentrated in a wave that
follows the Executing processes' effort.
This interrelationship among the levels of project management effort being expended on each of the
Process Groups is depicted in the diagram below as a staggered series of waves.

Many of the outputs created by the processes in each Process Group are used as inputs to processes in
subsequent Process Groups.
For example, the project management plan created in the Planning Process Group includes documentation
on how the project will be executed in the Executing Process Group.
Similarly, processes within the Monitoring and Controlling Process Group analyze the work performance
information produced during project execution, and if there are significant variations from the plan, a

Page 55
change request may be issued by these controlling processes. If approved, the change will be fed back
into the Executing Process Group for implementation.

Interaction Between Project Phases

All Process Groups occur with varying levels of rigor during each project life cycle phase. All the Process
Groups must occur at least once within each phase of the project, in order to start, execute, and complete
the phase according to the plan. The closing process of one phase of a project typically includes
authorizing the beginning of the next phase.
For example, the Process Groups occur in the design phase and then are used again in the
implementation phase. The design phase of the project may have to be formally closed, with a major
review or report, before the implementation phase is approved.
A small project with no phases may still contain multiple iterations of these Process Groups, in order to
refine the Project Management deliverables or processes to incorporate new information and to adapt to
changing circumstances.
The Process Groups and their relationship to the project as a whole are illustrated in the graphic below.

Each phase begins with the Initiating process, and project management activities proceed through the
Planning group of processes, followed by the Executing processes, until the phase is completed by the
Closing processes. The Monitoring and Controlling processes interact to ensure that the project stays on
track.
Information about project execution is passed to the Monitoring and Controlling processes and any
corrective actions are returned to the Executing processes. Significant changes to the project required by

Page 56
the Monitoring and Controlling processes might mean that some of the Planning processes must be
carried out again.

Process Group Inputs and Outputs

As noted earlier, project management is accomplished through processes that receive inputs and generate
outputs by applying tools and techniques, project management knowledge, and skills.
The graphic below illustrates the key inputs and outputs exchanged between the Process Groups. Each
Process Group produces the deliverables listed to the right.

Summary of Process Group’s Interactions. Adapted from PMBOK® Guide, Third Edition, Figure 3-4

Page 57
Process Flow Within and Between the Process Groups
There are two or more processes within each Process Group that are executed to create the Project
Management deliverables. For example, the Initiating Process Group includes two processes: Develop
Project Charter and Develop Preliminary Scope Statement.
There is a logical flow of information between the processes within each Process Group. Outputs from
one process within a Process Group are used as inputs to other processes in the same Process Group. In
the diagram below, the arrow from Develop Project Charter to Develop Preliminary Project Scope
Statement indicates process flow and the transfer of at least one Project Management deliverable (in this
case the project charter) between them. For the sake of readability, the actual deliverables are not shown
in this kind of diagram from the PMBOK® Guide, Third Edition.
As we noted earlier, information is also exchanged between Process Groups. In this diagram, the large
arrows show information being exchanged with the Planning, Executing, and Monitoring and Controlling
Process Groups.

In this course, as each Process Group is presented in further detail, this type of diagram will be shown.
The rectangular box labeled Develop Project Charter is the diagramming convention used to indicate a
process. An arrow is the convention used to indicate process flow.
Note the two numbering systems for each process. The first numbering system refers to where the process
appears in Chapter 3 of the PMBOK® Guide, Third Edition, within the section on Project Management
Process Groups.
The second numbering system indicates where the process is described in Section III, The Project
Management Knowledge Areas, of the PMBOK® Guide, Third Edition. The first part of the number is the

Page 58
chapter in the PMBOK® Guide, Third Edition, while the second part of the number represents the order in
which this process is presented in that chapter of the PMBOK® Guide, Third Edition.
For example (4.1) refers to the Develop Project Charter process, which is the first process in the Project
Integration Management Knowledge Area. Project Integration Management is presented in Chapter
4 of the PMBOK® Guide.

Page 59
2-2: Initiating Process Group
The Initiating Process Group defines and authorizes the start of a project or a project phase.
The following pages will cover:
• Initiating Process Group
• Purpose of the Initiating Process Group
• Activities Prior to the Initiating Process
• Initiating Processes
• Initiating Process Group: Major Outputs

Page 60
Initiating Process Group
Initiating is one of the five Project Management Process Groups. Although it precedes the other Process
Groups, Initiating may also occur for each phase within the project life cycle.
When starting the first phase of a project, the Initiating Process Group defines the purpose of the project
and identifies the project objectives. When starting any other phase, the Initiating Process Group updates
the project purpose and objectives as necessary. It also provides formal authorization for the project
manager to execute the next phase of the project.
Repeating the Initiating process at the start of each phase helps to keep the project aligned with the
business need that it was undertaken to address. It also helps to ensure that the project is halted if the
business need no longer exists or if the project is unlikely to satisfy that need. This formal Initiating
process links the project to the ongoing work of the performing organization.

Project Management Process Groups Mapped to the Plan-Do-Check-Act Cycle, Highlighting the Initiating Processes
Adapted from PMBOK® Guide, Third Edition, Figure 3-2

Purpose of the Initiating Process Group

The Initiating Process Group serves many purposes for the organization. Some important reasons for a
formal initiation process are listed below:
• To commit the organization to a project or a phase
• To set the overall direction of the solution
• To define top-level project objectives
• To secure the necessary approvals and resources
• To assign a project manager

Activities Prior to the Initiating Process

Some organizations have several activities that must be performed before a project is authorized. These
activities are almost always performed to provide project sponsors with information regarding the value
or likely success of authorizing the project.

Page 61
In some organizations, a project is not formally initiated until after the completion of one or more of the
following:
• A needs assessment
• A feasibility study
• A preliminary plan
• An equivalent form of analysis that was itself separately initiated

Initiating Processes
There are 2 processes in the Initiating Process Group: Develop Project Charter and Develop
Preliminary Project Scope Statement. As noted earlier, the Initiating processes occur at the outset of
each phase of the project.
This diagram shows that the Develop Project Charter process occurs prior to the Develop Preliminary
Project Scope Statement process. In fact, the main output from the Develop Project Charter process is
the primary input to the Develop Preliminary Project Scope Statement process.
The large two-way arrows labeled Planning Process Group, Executing Process Group, and
Monitoring & Controlling Process Group illustrate that there is also exchange of information between
the Initiating Process Group and these three other Process Groups.

Page 62
Initiating Process Group: Major Outputs
There are two outputs from the Initiating Process Group. The project charter is produced by the Develop
Project Charter process. The preliminary project scope statement is the output from the Develop
Preliminary Project Scope Statement process.
Project Charter
The initiation of a project often means that significant resources are about to be expended. Such decisions
should involve senior management. The project charter is a formal means of obtaining and documenting
authorization from management to proceed with the project. It demonstrates a commitment to the project
and authorizes the project manager to apply resources from the organization to the project work.
Preliminary Project Scope Statement
A scope statement is a document that captures the total work to be performed in the project. It represents
an agreement among the stakeholders about what is within and what is outside the project’s scope. It
describes both the product or service that the project will deliver, as well as performance-related
objectives regarding cost, schedule, technical issues, and quality. The preliminary project scope statement
is the first iteration of project scope statement, which is further refined in the Scope Definition process.

Page 63
2-3: Planning Process Group
The Planning Process Group defines and refines objectives, and plans the course of action required to
attain the objectives within the scope that the project was undertaken to address.
The following pages will cover:
• Planning Process Group
• Purpose of the Planning Process Group
• Planning Processes
• Progressive Elaboration
• Planning Process Group: Major Outputs
• Purpose of the Project Management Plan

Page 64
Planning Process Group
Planning is one of the five Project Management Process Groups, containing 21 of the 44 project
management processes. Most of the complexity, and perhaps most of the effort of project management, is
in the Planning Process Group, and is preparatory in nature.

Project Management Process Groups Mapped to the Plan-Do-Check-Act Cycle, Highlighting the Planning Processes
Adapted from PMBOK® Guide, Third Edition, Figure 3-2

Purpose of the Planning Process Group

The purpose of the Planning Process Group is to:
• Create and manage the project management plan
• Set up the baselines (schedule, cost, quality, etc.) against which future project activity will be
measured

Definition: Baseline

The approved time phased plan (for a project, a work breakdown structure component,
a work package, or a schedule activity), plus or minus approved project scope, cost,
schedule, and technical changes. Generally refers to the current baseline, but may
refer to the original or some other baseline. Usually used with a modifier (e.g., cost
baseline, schedule baseline, performance measurement baseline, technical baseline).
PMBOK® Guide, Third Edition, Glossary

The processes of the Planning Process Group create a project management plan. The project management
plan details the project work that will be performed during the Executing processes. Once approved, the
project management plan components provide baselines against which the project manager will measure
actual performance.

Page 65
Planning Processes
The graphic below shows the 21 processes of the Planning Process Group. Notice the complexity of the
process flow. Not all process interactions and data flow among the processes are shown in the diagram.
This diagram illustrates the interaction that the Planning processes have within the Planning Process
Group itself, as well as the interaction between the Planning Process Group and the other four Process
Groups.

Page 66
Progressive Elaboration
Many of the processes within project management are iterative in nature. This allows the project manager
to repeat a process and refine its deliverables as more information becomes available, in order to manage
the project more effectively. As discussed earlier in the course, this is known as progressive elaboration.
Progressive elaboration involves repeating this cycle of the processes in the Planning Process Group at
least once for each phase in the project life cycle. Each repetition further refines the project scope, the
work breakdown structure, and the associated project management plans.

Planning Process Group: Major Outputs

The Project Management Plan
The key deliverable from the Planning Process Group is the project management plan. A project
management plan is a dynamic, integrated document that shows the overall path of the project. It is
dynamic because it changes throughout the course of the project. It is integrated because it is made up of a
number of other specialized constituent plans.
The complete project management plan identifies the following.
• What has to be done
• Why it must be done
• Who will do the work
• When it will be done
• What resources will be required
• What criteria must be met in order for the project to be complete and successful
• What could go wrong, and what will be done about it either when it does, or beforehand, to
prevent it
Purpose of the Project Management Plan
In addition to guiding project execution and control, a project management plan will also:
• Document all project planning assumptions
• Document decisions regarding any alternatives chosen
• Facilitate stakeholder communications
• Define how and when key management reviews will take place
• Provide a set of baselines for performance measurement
The project management plan addresses:
• How rigorously each of the project management processes will be implemented
• What inputs and outputs from the project management processes will be used
• How changes to project performance baselines will be controlled
• What project life cycle will be used, and how it will be tailored to fit the project
• How key management reviews will be used to address open issues and make decisions

Page 67
Project Management Plan: Constituent Plans
For a project to be successful, all defined work must be planned, estimated, scheduled, and authorized. In
order to manage key aspects of the project management activities, separate plans are created to set out the
details of how these activities will be carried out, and how their respective contributions to the project
management plan will be maintained. The project management plan integrates all of the constituent plans
into one document.
Key constituents of the project management plan are shown and described below.
• Scope management plan
o Describes what the product or service produced by the project will do, what deliverables
will be required, and how the project’s scope will be managed.
o Developed as part of the Project Scope Management Knowledge Area in the Planning
Process Group.
• Schedule management plan
o Describes activities that will be needed to create the project deliverables, in what
sequence they will occur, who will perform them, and what other resources will be
required, as well as how this schedule information will be maintained.
o Developed as part of the Project Time Management Knowledge Area in the Planning
Process Group.
• Procurement management plan
o Describes which deliverables will be purchased, how vendors will be selected to produce
the deliverables, how the contracts related to the procured deliverables will be developed
and managed, and related oversight activities.
o Developed as part of the Project Procurement Management Knowledge Area in the
Planning Process Group.
• Cost management plan
o Describes how the project budget is allocated to produce the project deliverables over
time, and how the budget will be maintained.
o Developed as part of the Project Cost Management Knowledge Area in the Planning
Process Group.
• Communications management plan
o Describes all aspects of how the project manager and team will communicate both
internally and with stakeholders, and describes how any additions or modifications to
existing communications vehicles will be carried out. The plan also describes how the
communications management plan itself will be maintained.
o Developed as part of the Project Communications Management Knowledge Area in
the Planning Process Group.
• Risk management plan
o Describes how risks will be identified, assessed, and managed, as well as how risk-related
project information will be maintained.
o Developed as part of the Project Risk Management Knowledge Area in the Planning
Process Group.

Page 68
• Quality management plan
o Identifies how the quality of project deliverables will be assessed, as well as how such
quality information will be used, shared, and stored. The plan also describes how the
quality management plan itself will be maintained.
o Developed as part of the Project Quality Management Knowledge Area in the Planning
Process Group.
• Staffing management plan
o Describes how staff will be assigned to and released from the project, and how this
staffing information will be maintained, as well as describing any training or
development activities.
o Developed as part of the Project Human Resource Management Knowledge Area in
the Planning Process Group.

Page 69
2-4: Executing Process Group
The Executing Process Group integrates people and other resources to carry out the project management
plan for the project.
The following pages will cover:
• Executing Process Group
• Purpose of the Executing Process Group
• Executing Processes
• Project Execution – Starting the Work
• Project Execution – Controlling the Work
• Executing Process Group: Major Outputs

Page 70
Executing Process Group
The Executing Process Group contains 7 Project Management processes. These processes implement the
project management plan for the project.

Project Management Process Groups Mapped to the Plan-Do-Check-Act Cycle, Highlighting the Executing Processes
Adapted from PMBOK® Guide, Third Edition, Figure 3-2

Purpose of the Executing Process Group

The processes of the Executing Process Group serve to complete the work defined in the project
management plan to accomplish the project’s requirements.
The processes involve:
• Coordinating people and resources
• Integrating and performing the activities of the project in accordance with the project
management plan
• Addressing the scope defined in the project scope statement
• Implementing approved changes

Page 71
Executing Processes
The graphic below shows the 7 processes of the Executing Process Group. This diagram illustrates the
interaction that the Executing processes have within the Executing Process Group as well as the
interactions between the Executing Process Group and the other four Process Groups.
For example, the Monitoring and Controlling processes interact with the Executing processes to ensure
that work results are aligned with the project management plan. In some cases, work results that are not
under control require changes to the project management plan, necessitating the iteration of the Planning
processes.

Page 72
Project Execution – Starting the Work
When a project deliverable is approved as complete, the project management team reviews succeeding
activities that use that deliverable as an input to determine whether these activities are ready to start. If the
other required input deliverables are also ready, and the assigned resource is available to work on the
activity, the activity may be started.
To start the activity, the project management team “releases” it for work by providing the assigned
resources with the necessary input deliverables and the following information:
• The project process to be followed for developing the new deliverable
• The standards that must be applied
• The procedure for reviewing the deliverable for correctness and completeness
• When the deliverable is due and how much effort should be expended on it
The management team may also indicate the priority of this activity versus that of other activities
concurrently assigned to the same resources.

Project Execution – Controlling the Work

As the project work is executed, information may be gathered regarding the work performance. By
analyzing it against the project baselines, this information will indicate whether the project is performing
according to the project management plan.
Variations in areas such as activity duration and resource availability may result in the need to implement
corrective actions. Analysis of any variations from baselines may also result in change requests and, if
approved, the changes may require the team to modify the constituent plans or baselines of the project.
Finally, deliverables are sometimes not approved and instead, defect repairs are recommended. These
recommended defect repairs are returned to the Direct and Manage Execution process, where they are
released for additional work on the deliverable, usually by the same resources originally assigned to it.
When such defect repairs are reported as complete, they are verified within the Monitoring and
Controlling Process Group. The cycle may be repeated until the deliverable is satisfactory.

Executing Process Group: Major Outputs

The main outputs from the Executing Process Group are listed below.
• Deliverables
• Requested changes
• Implemented change requests
• Implemented corrective actions
• Implemented preventive actions
• Implemented defect repairs
• Work performance information

Page 73
2-5: Monitoring and Controlling Process Group
The Monitoring and Controlling Process Group regularly measures and monitors progress to identify
variances from the project management plan, so that corrective action can be taken when necessary to
meet project objectives.
The following pages will cover:
• Monitoring and Controlling Process Group
• Purpose of the Monitoring and Controlling Process Group
• Monitoring and Controlling Processes
• Monitoring and Controlling Process Group: Major Outputs
• Project Change Management

Page 74
Monitoring and Controlling Process Group
Monitoring and Controlling is one of the five Project Management Process Groups and consists of 12
Project Management processes. These processes observe project execution so that potential problems can
be identified and, when necessary, corrective action can be taken to control the execution of the project.
As illustrated in the diagram, the Monitoring and Controlling processes happen concurrently with the
other Process Group processes.

Project Management Process Groups Mapped to the Plan-Do-Check-Act Cycle, Highlighting the Monitoring and Controlling Processes
Adapted from PMBOK® Guide, Third Edition, Figure 3-2

Purpose of the Monitoring and Controlling Process Group

The purpose of establishing and using Monitoring and Controlling measures is to observe the Initiating,
Planning, Executing, and Closing processes (monitor). Monitoring helps identify possible problems as
indicated by variances between the project’s actual performance and the project baselines, as well as any
problems in the deliverables. If done in a timely manner, corrective action can be taken and baselines
adjusted when appropriate (control).
Note: Changes for a project can occur in many ways. Changes may originate from an internal source,
because performance results differ from the project management plan, or from an external request, for
example from a customer who wants to add another feature.

Page 75
Monitoring and Controlling Processes
The graphic below shows the 12 processes of the Monitoring and Controlling Process Group. It illustrates
the interaction that the Monitoring and Controlling processes have within the Monitoring and Controlling
Process Group, as well as the interactions between the Monitoring and Controlling Process Group and the
other four Process Groups.
As a result of the Monitoring and Controlling processes, the project management plan may be modified,
or the project or project management processes may be altered in an effort to maintain continuous
improvement. Alternatively, if prompt action can still result in the project’s performance returning to the
level required by the baselines, these processes can result in recommended corrective actions or
preventive actions.

Page 76
Monitoring and Controlling Process Group: Major Outputs
The main processes of the Monitoring and Controlling Process Group are Monitor and Control Project
Work and Integrated Change Control. The major outputs from these two processes are listed below.
Monitor and Control Project Work
• Recommended corrective actions
• Recommended preventive actions
• Recommended defect repairs
• Forecasts
• Requested changes
Integrated Change Control
• Approved change requests
• Rejected change requests
• Approved corrective actions
• Approved preventive actions
• Approved defect repairs
• Project management plan updates
• Project scope statement updates
• Validated defect repairs
• Deliverables (approved)

Project Change Management

Some of the key elements of managing a successful project are recognizing, understanding, and
controlling changes. There are many steps involved in project change management. Regardless of what
process identifies the need or desire for a change, a formal process or procedure must be followed for the
review and possible incorporation of the change into the baseline of the project.
The following are some basic principles of project change management:
• Change is inevitable on any project.
• Managing change can mean the difference between success and failure.
• There are many sources of change.
• If it is not documented, it should be treated as if it did not happen.
The Integrated Change Control process manages the overall review and approval of requested changes.
The Integrated Change Control process will be discussed in more detail in the section that covers the
Project Integration Management Knowledge Area.
In addition, each of the Knowledge Areas has one controlling process that implements approved changes
to the project management baseline for that Knowledge Area. In this way, changes to the project scope,
schedule, budget, resources, quality, and risk activities are all coordinated across the entire project.

Page 77
2-6: Closing Process Group
The Closing Process Group formalizes acceptance of the product, service, or result, and brings the project
or project phase to an orderly end.
The following pages will cover:
• Closing Process Group
• Purpose of the Closing Process Group
• Closing Processes
• Closing Process Group: Major Outputs
• The Importance of Formal Project Closure

Page 78
Closing Process Group
Closing is one of the five Project Management Process Groups, and includes two Project Management
processes.
As illustrated in the diagram, the Closing processes occur after all project work is completed.

Project Management Process Groups Mapped to the Plan-Do-Check-Act Cycle, Highlighting the Closing Processes
Adapted from PMBOK® Guide, Third Edition, Figure 3-2

Purpose of the Closing Process Group

The PMBOK® Guide description of the Closing Process Group clearly identifies the purpose of closure
as: to bring a project or project phase to an orderly end. This requires a formal acceptance of project
work, confirming that the project work is complete and satisfactory.
Formal Closing processes ensure that all contract issues are concluded, and that all contract deliverables
are reviewed and accepted. Additionally, closing activities include the internal documentation and
archiving of project records and lessons learned for the benefit of future projects in an organization.
The PMBOK® Guide, Third Edition, definition of Closing processes is presented below.

Definition: Closing Processes

Those processes performed to formally terminate all activities of a project or phase,
and transfer the completed product to others or close a cancelled project.
®
PMBOK Guide, Third Edition, Glossary

To summarize, the purpose of the Closing Process Group is to:

• Formalize all contract requirements
• Formalize acceptance of project and contract closure
• Document lessons learned
• Archive project reports and data

Page 79
Closing Processes
The graphic below shows the 2 processes of the Closing Process Group. This diagram illustrates the
interaction between Close Project and Contract Closure as well as the interaction of the Closing
Process Group with the Planning Process Group, the Executing Process Group, and the Monitoring
and Controlling Process Group.

Closing Process Group: Major Outputs

The major outputs from the Closing Process Group include:
• The final product, service, or result
• Updates to organizational process assets

Page 80
The Importance of Formal Project Closure
What sometimes happens at the end of the project? Some team members leave as quickly as they can,
looking for the next project or career. Others may be let go because the budget is gone. The project
manager is already thinking about the next project. People may not be recognized or thanked for the hard
work or sacrifices they made.
Formal project closure is important to ensure that:
• All contract requirements are concluded
• Lessons learned from a project are captured
• Good performance by team members is rewarded and recognized
Celebrate Success
It is important to recognize the project team and its hard work at the end of the project and to celebrate the
successful completion of the project. This may be as simple as giving team members commemorative T-
shirts, a dinner out on the town, a Friday afternoon off, or something more formal. In any case, it brings
closure to the project, lets team members know that their hard work is appreciated, and makes it more
likely they will be committed to another project with the same project manager, team members, and
performing organization.

Page 81
2-7: Project Management Knowledge Areas
As illustrated on the previous pages, the 44 Project Management processes can be grouped into five
Process Groups. They can also be grouped and viewed by Knowledge Area.
The Project Management processes are presented by Knowledge Area because:
• The processes in a Knowledge Area share many characteristics, such as inputs, tools and
techniques, and outputs, simplifying comparing and relating them to each other.
• Practitioners often specialize in a particular Knowledge Area, and this approach offers a ready
mechanism for specifying the scope of a practitioner’s specialized role.
For those new to the field or expanding their knowledge of it, this approach allows more rapid
assimilation of the knowledge content and easier reference to external materials that are structured using
the same conceptual model.
The following pages will cover:
• Project Management Knowledge Areas
• Mapping the Processes to the Knowledge Areas

Page 82
Project Management Knowledge Areas
The PMBOK® Guide, Third Edition, defines nine Knowledge Areas. These Knowledge Areas describe
project management knowledge and practice in terms of their component processes. These Knowledge
Areas are listed and described below. (The number of processes within each Knowledge Area is shown in
parentheses – totaling 44.)
• Project Integration Management (7 processes): Includes all processes and activities needed to
identify, define, combine, unify, and coordinate the various processes and project management
activities within the Project Management Process Groups.
• Project Scope Management (5 processes): Includes all the processes required to ensure that the
project includes all the work required, and only the work required to complete the project
successfully.
• Project Time Management (6 processes): Includes all the processes required to accomplish
timely completion of the project.
• Project Cost Management (3 processes): Includes the processes involved in planning,
estimating, budgeting, and controlling costs so that the project can be completed within the
approved budget.
• Project Quality Management (3 processes): Includes the processes and activities of the
performing organization that determine quality policies, objectives, and responsibilities so that
the project will satisfy the objectives for which it was undertaken. It implements the quality
management system through policy and procedures, with continuous process improvement
activities conducted throughout, as appropriate.
• Project Human Resource Management (4 processes): Includes the processes that organize and
manage the project team.
• Project Communications Management (4 processes): Employs the processes required to
ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate
disposition of project information. The Project Communications Management processes provide
the critical links among people and information that are necessary for successful communications.
• Project Risk Management (6 processes): Includes the processes concerned with conducting risk
management planning, identification, analysis, response, and monitoring and control on a project.
• Project Procurement Management (6 processes): Includes the processes used to purchase or
acquire the products, services, or results needed from outside the project team.

Page 83
Mapping the Processes to the Knowledge Areas
The following graphic illustrates the mapping of the 44 Project Management processes to the nine Project
Management Knowledge Areas (horizontal view). It also provides a view of the five Project Management
Process Groups and their constituent processes (vertical view).

Mapping of the Project Management Processes to the Project Management Process Groups and the Knowledge Areas, PMBOK® Guide, Third
Edition

Page 84
Summary
There are 44 Project Management processes that are aggregated into five Project Management Process
Groups. The five Process Groups have clear dependencies and are performed in the same sequence on
each project.
The Initiating Process Group defines the purpose of the project and identifies the project objectives when
starting the first phase of a project, or updates the project objectives as necessary when starting any other
phase. It also provides formal authorization for the project manager to execute the next phase of the
project.
Once a project has been initiated, the project manager then plans the project. There are 21 processes in the
Planning Process Group. The ultimate goal of the Planning processes is to complete a valid project
management plan.
Once the project has been planned and the details of the plans have been documented in the project
management plan, the work required to complete project objectives can begin. The processes in the
Executing Process Group are used to carry out the project management plan details, producing work
results.
The purpose of establishing and using Monitoring and Controlling measures is to observe the Initiating,
Planning, Executing, and Closing processes (monitor) and identify potential problems or variances
between the project performance and the project baseline, as well as problems in the deliverables in a
timely manner. This is important so that corrective action can be taken and baselines adjusted when
appropriate (control).
The definition of the Closing Process Group clearly delineates the purpose of closure as: …to bring a
project or project phase to an orderly end. This requires a formal acceptance of project work, confirming
that the project work is complete and satisfactory.
The PMBOK® Guide defines nine Knowledge Areas. These Knowledge Areas describe project
management knowledge and practice in terms of their component processes.

Page 85
Concept 3 – Project Integration Management
Introduction
Project Integration Management describes the processes and activities that integrate the various elements
of project management, which are identified, defined, and combined within the project management
Process Groups.
This concept:
• Describes how Project Integration Management facilitates the successful completion of projects
and identifies the key deliverables produced from this Knowledge Area
• Defines the project charter and identifies all the components, and describes the importance of
obtaining formal authorization for a project
• Identifies the components of the preliminary project scope statement and examines the
importance of properly identifying scope for a project
• Explains the benefits of using the project management plan for project planning and identifies the
essential components of the project management plan
• Describes the relationship between the project management plan, the execution of project work,
and the formal closing of a project or project phase

Page 86
3-1: Overview of Project Integration Management
Project Integration Management involves coordinating all the other Project Management Knowledge
Areas throughout a project’s life cycle. This integration ensures that all the elements of a project come
together at the right times to complete a project successfully.
The following pages will cover:
• Definition of Project Integration Management
• Balancing Trade-Offs
• Project Integration Management
• Project Integration Management Processes
• Project Integration Management Processes Flow
• Business Reasons for Projects
• Assignment of the Project Manager

Page 87
Definition of Project Integration Management
Project Integration Management is a method of helping project managers and the program management
team coordinate the various elements of a project throughout the project’s life cycle to meet the project’s
needs and demands.

Definition: Project Integration Management

Includes the processes and activities needed to identify, define, combine, unify, and
coordinate the various processes and project management activities within the
Project Management Process Groups.
®
PMBOK Guide, Third Edition, Appendix F, Summary of Project Management Knowledge Areas

Within the project management context, integration means that the project manager and the team are
responsible for ensuring that all activities required to produce the project’s product are performed
successfully. Part of this effort also involves meeting stakeholder requirements and managing stakeholder
expectations.
This integration effort includes:
• Making choices on schedule and resource utilization
• Proactively anticipating issues and effectively managing them
• Coordinating all work efforts
• Balancing trade-offs between competing project objectives

Balancing Trade-Offs
As the Triple Constraint model illustrates, there are three primary elements constraining every project:
scope and quality, time, and budget. If any one of these elements changes, the other two constraints will
be impacted as well. For example, if the budget is cut, the scope of the project may need to be reduced in
order to maintain the equilibrium of the triangle.

Page 88
This same effect is true for other elements in the project. As human resources are added to complete the
work of the project, schedule and/or budget may be affected. As risks are identified and analyzed, projects
may require additional resources or a longer schedule to properly mitigate the risks.
There is no single best way to manage any given project. A project manager needs to perform solid
Project Integration Management in order to be successful. It is the responsibility of the project manager to
see the big picture of the project and manage the details with that big picture in mind.
Project Integration Management requires the project team to:
• Exchange project management work products among Project Management processes
• Ensure that defects are removed from deliverables
• Manage change requests and corrective and preventive actions
• Successfully accomplish project objectives
• Work within an organization’s defined procedures
• Re-plan to address project problems and opportunities when necessary
Effective communication with all project stakeholders is integral to performing Project Integration
Management. Project managers need to communicate not only upward to senior management and
downward to the project team, but also horizontally and vertically to other project managers, and to
functional managers within their organizations.

Project Integration Management

Project Integration Management involves integrating the deliverables from the other project Knowledge
Areas. It also involves accommodating enterprise environmental factors, such as organizational culture
and staff capabilities, and organizational process assets, such as methodologies and other defined
processes. It requires that the project manager and team coordinate the processes within all Process
Groups to accomplish the project’s objectives within an organization’s defined procedures.
• For planning, it requires a project management plan, project charter, and project scope statement
to serve as a blueprint or guide.
• For executing, it involves releasing work, measuring the work performance, and implementing
change requests.
• For monitoring and controlling, it requires forecasting variances from the plan and managing
change requests and corrective and preventive actions.
• For closing, it involves determining whether the project’s deliverables perform as required.
Project Integration Management is also concerned with project initiation, as the project manager and
team are always evaluating successes and trade-offs in light of the reasons for undertaking the project in
the first place. Projects are initiated due to business needs, and as part of the Project Integration
Management effort, the project manager is required to regularly validate and demonstrate that the value
and cost of future efforts are commensurate with the accomplishment of this strategic purpose.

Page 89
Project Integration Management Processes
Shown below is an adaptation of PMBOK ® Guide, Third Edition, Table 3-45, showing the processes of
the Project Integration Management Knowledge Area. This matrix illustrates the relationship between two
of the dimensions of the project management framework – the Process Groups along the top, and the
Knowledge Areas down the side.
From this matrix, you can see that there are two Project Integration Management processes in the
Initiating Process Group, 4.1 Develop Project Charter and 4.2 Develop Preliminary Project Scope
Statement; and two in the Monitoring and Controlling Process Group, 4.5 Monitor & Control Project
Work and 4.6 Integrated Change Control. The Planning, Executing, and Closing Process Groups each
contain one Project Integration Management process – 4.3 Develop Project Management Plan, 4.4
Direct & Manage Execution, and 4.7 Close Project.

PMBOK® Guide, Third Edition

According to the PMBOK® Guide, Third Edition, there are seven Project Integration Management
processes. These are listed and described below.
• Develop Project Charter – Developing the project charter that formally authorizes a project or a
project phase
• Develop Preliminary Project Scope Statement – Developing a preliminary project scope
statement that provides a high-level scope narrative
• Develop Project Management Plan – Documenting the actions necessary to define, prepare,
integrate, and coordinate all subsidiary plans into a project management plan
• Direct and Manage Project Execution – Executing the work defined in the project management
plan to achieve the project’s requirements defined in the project scope statement
• Monitor and Control Project Work – Monitoring and controlling the processes used to initiate,
plan, execute, and close a project to meet the objectives defined in the project management plan
• Integrated Change Control – Reviewing all change requests, approving changes, and
controlling changes to the deliverables and organizational process assets
• Close Project – Finalizing all activities across all the project management Process Groups to
close the project or a project phase.

Page 90
Project Integration Management Processes Flow
The following diagram shows the key process and information flow for Project Integration Management
processes, which are shown in gray boxes.

Page 91
Business Reasons for Projects
Projects are commonly chartered and authorized by an entity external to the project organization, such as
an enterprise, a government agency, a company, a program organization, or a portfolio organization.
Projects are chartered as a result of one or more of the following:
• Market demand
• Organizational need
• Customer requests
• Technology advance
• Legal requirements
• Social need

Assignment of the Project Manager

One of the most critical decisions made by the organization is naming the project manager. This involves:
• Finding someone with the ability to acquire, manage, and motivate the needed resources
• Matching a project manager to a project based on skills required to manage the project
successfully
Because the project manager is such a crucial factor in the success of a project, one should be named no
later than the Develop Project Charter process.

Page 92
3-2: Develop Project Charter
This section introduces you to the purpose of a project charter. It will also demonstrate why it is important
to develop a project charter, and will discuss the different types of information that are documented in the
charter.
The following pages will cover:
• Purpose of a Project Charter
• Who Issues a Project Charter
• Inputs, Tool and Techniques, and Outputs
• Inputs to the Develop Project Charter Process
• Tools and Techniques for the Develop Project Charter Process
• Outputs from the Develop Project Charter Process
• Constraints and Assumptions

Page 93
Purpose of a Project Charter
Definition: Project Charter
A document issued by the project initiator or sponsor that formally authorizes the
existence of a project, and provides the project manager with the authority to apply
organizational resources to project activities.
PMBOK® Guide, Third Edition, Glossary

The purpose of a project charter is to define at a high level the business need that the project will address,
the product or service that the project will deliver, the resources that are needed, and why the project is
justified.
The project charter also represents the organization’s formal commitment to dedicating the necessary time
and resources to the project. For this reason, the project charter should be shared with and agreed to by all
major stakeholders.
The project charter also grants the project manager the authority to carry out the next phase of the project.

Who Issues a Project Charter?

The project manager does not issue the project charter. In actual practice, the project manager is often
involved in its creation. Regardless of origin, the charter needs to be issued by a manager with a level of
authority appropriate to the project’s funding. The definition specifies two roles as typically issuing the
charter:
• Initiator – A person or organization that has both the ability and the authority to start a project
• Sponsor – The person or group that provides the financial resources, in cash or in kind, for the
project
PMBOK® Guide, Third Edition, Glossary

Inputs, Tools and Techniques, and Outputs

The diagram below shows the inputs, tools and techniques, and outputs of the Develop Project Charter
process.

Inputs, Tools and Techniques, and Outputs - Develop Project Charter

Page 94
Inputs to the Develop Project Charter Process
Contract (when applicable)
This applies when the project work is being done for an external customer.
Project Statement of Work
A statement of work (SOW) is a narrative description of the project’s products or services. The SOW
includes a description of the product’s scope. It should also reflect the business need and strategic plan for
the organization.
Enterprise Environmental Factors
The organization’s enterprise environmental factors and systems that surround and influence the project
success must be considered.
These factors include:
• Organizational or company culture and structure
• Governmental and industry standards
• Infrastructure
• Existing human resources
• Personnel administration
• Company work authorization system
• Marketplace conditions
• Stakeholder risk tolerances
• Commercial databases
• Project management information systems
Organizational Process Assets
Organizational process assets are the organization’s processes and procedures for conducting project
work, as well as the organizational corporate knowledge base for project information.
Organizational process assets that concern processes and procedures for conducting work include:
• Standard organizational processes, such as standards, policies, project and product life cycles, and
quality policies and procedures
• Standardized guidelines, work instructions, proposal evaluation criteria, and performance
measurement criteria for typical project activities
• Templates for project management documents
• Guidelines and criteria for tailoring the organization’s standard processes to satisfy the specific
needs of the project
• Organizational communications requirements and available communications vehicles
• Project closure guidelines or requirements
• Financial controls procedures
• Issue and defect management procedures

Page 95
 • Change control procedures
• Risk management procedures and tools
• Procedures for approving and issuing work authorizations
The organizational corporate knowledge base for storing and retrieving information contains:
• A process measurement database used to collect and make available measurement data on
processes and products
• Project files (including baselines, network diagrams, and risk management information)
• Historical information and lessons learned knowledge base containing issue and defect issues
• An issue and defect management database
• A configuration management knowledge base
• A financial database

Tools and Techniques for the Develop Project Charter Process

Project Selection Methods
This involves measuring the potential value of the project and comparing it to other opportunities.
Decisions must be made about where to expend valuable resources. Any number of decision models and
calculation methods can help in the selection process.
The PMBOK® Guide mentions two categories:
• Benefit measurement methods, which use comparative approaches, scoring and ranking models,
and relative benefit contribution
• Mathematical models, which use programming algorithms, such as linear programming
Project Management Methodology
A project management methodology defines an integrated set of project management processes, their
associated deliverables, and how they should be tailored and carried out. An organization’s project
management methodology must include some definition of how the Project Management processes
interact with project life cycle phases and phase deliverables, and how management controls are applied
(particularly through status reviews and deliverable approvals) to move the project through to completion.
Project Management Information System (PMIS)
A PMIS includes the set of automated tools that the organization uses to manage projects. These tools are
integrated into a system that the enterprise uses to guide Planning, Executing, Monitoring and Controlling
and Closing processes.
Expert Judgment
Any group or individual with specialized knowledge can provide expert judgment to assess the inputs
needed to develop the project charter.

Page 96
Outputs from the Develop Project Charter Process
The single output from the Develop Project Charter process is the project charter.
Components of the Project Charter
The project charter includes:
• A definition of the requirements that the project must satisfy to meet customer, sponsor, and other
stakeholder needs
• A high-level description of the product or service that the project is undertaken to produce
• Project purpose
• Assigned project manager and the degree and extent of the authority he or she is being granted
• Summary milestone schedule
• Stakeholder influences
• Functional organizations and participants
• Organizational, environmental, and external assumptions
• Organizational, environmental, and external constraints
• Business case justifying the project, including ROI or other characteristics, which will be
compared to the criteria in the organization’s project selection method
• Summary (high-level) budget
Finally, the charter should include the signature of the project initiator or sponsor to authorize the project
manager to apply resources to project activities.
Although the components of the project charter list may seem trivial at first glance, it is often difficult in
practice to gather and document this information clearly. However, the effort needed to draft (and revise)
the project charter is typically invaluable in identifying the real problem and a workable solution.
Constraints
At the beginning of a project or phase, there are often pieces of information about the project that are not
complete. The project manager should clarify any known project constraints and document them. To
progress, the project manager may have to create and document some assumptions until more information
becomes available.

Definition: Constraint
Applicable restriction or limitation, either internal or external to the project, that
will affect the performance of the project or a process.
PMBOK® Guide, Third Edition, Glossary

Constraints are factors that may restrict the options available to a project manager. Many projects have
schedule constraints, cost constraints, or resource constraints. An inflexible deadline or budget, for
example, can impose severe limits on a project. Governmental regulations and the availability of skilled
labor can also serve as constraints. These factors should be identified and documented as part of the
Initiating process.

Page 97
Assumptions
Assumptions are factors that are considered to be true, real, or certain for planning purposes – although it
is understood that they may be false.

Definition: Assumption

Assumptions are factors that, for planning purposes, are considered to be true, real, or
certain without proof or demonstration. Assumptions affect all aspects of project planning,
and are part of the progressive elaboration of the project. Project teams frequently identify,
document, and validate assumptions as part of their planning process. Assumptions generally
involve a degree of risk.
PMBOK® Guide, Third Edition, Glossary

Some things cannot be known until the project is underway, and it may not make sense to delay
commencing the project until more information becomes available.
Identifying assumptions is a way to deal systematically with the need to act without having all the
information. Assumptions can also serve as red flags. If circumstances show an assumption to be
incorrect, decisions based on that assumption might need re-examination.

Page 98
3-3: Develop Preliminary Project Scope Statement
This section introduces the definition of a preliminary project scope statement and its importance to the
project management team and other stakeholders. It introduces the inputs, tools and techniques, and
outputs that are associated with the project scope statement, and the way the work breakdown structure
(WBS) organizes and defines the total scope of a project.
The following pages will cover:
• Definition of Project Scope Statement
• Why a Project Scope Statement Is Important
• Project Boundaries
• Preliminary Project Scope Statement Elements
• Product Scope vs. Project Scope
• Inputs, Tools and Technique, and Outputs
• Inputs to the Develop Preliminary Project Scope Statement Process
• Tools and Techniques for the Develop Preliminary Project Scope Statement Process
• Outputs from the Develop Preliminary Project Scope Statement Process
• Initial Work Breakdown Structure (WBS)
• Definition of Work Breakdown Structure Dictionary
• WBS Format Example

Page 99
Definition of the Project Scope Statement
The PMBOK® Guide, Third Edition, provides the following definition of the project scope statement.

Definition: Project Scope Statement

The narrative description of the project scope, including major deliverables, project
objectives, project assumptions, project constraints, and a statement of work, that provides a
documented basis for making future project decisions and for confirming or developing a
common understanding of project scope among the stakeholders. The definition of the project
scope – what needs to be accomplished.
PMBOK® Guide, Third Edition, Glossary

The project scope is a summary of all the work required to produce the products, services, or results that
the project will deliver. The project scope is documented at a high level in the preliminary project scope
statement during the Develop Preliminary Project Scope Statement process.
The complete project scope is later defined during the Scope Definition process in the Project Scope
Management Knowledge Area. The Scope Definition process transforms the preliminary project scope
statement into the detailed project scope statement. This additional process falls outside Project
Integration Management, and so is addressed in another course.
The project scope statement defines the boundaries of the project and documents a common
understanding of what those boundaries are.
The Project Scope Management Knowledge Area contains all the remaining processes that are primarily
concerned with defining and controlling what is and is not included in the project scope.

Why a Project Scope Statement Is Important

Proper Scope Definition is critical to a project's success. It establishes the boundaries of what the project
will and will not accomplish. The project scope statement eliminates any confusion or ambiguity that
might still exist after considering the project's goal, objectives, and high-level deliverables statements.
Poorly defined scope leads to frequent small changes in the project requirements (this is a phenomenon
known as “scope creep”). These changes inevitably lead to increased work effort, which in turn causes
project delays, cost overruns, and/or customer dissatisfaction. A clearly defined scope will crystallize
realistic stakeholder expectations.

Project Boundaries
The project initiator or sponsor provides the initial information regarding the project scope, and the
project management team refines this information through the Develop Preliminary Project Scope
Statement and Scope Definition processes. Changes to the project’s scope must be reviewed, approved,
and documented in the project scope management plan. The project initiator or sponsor approves all
major changes.

Page 100
PMBOK® Guide, Third Edition

Documenting the project scope allows the project manager to define one side of the Triple Constraint, and
allows the project manager and team to determine whether the scope objective can be achieved within the
cost, time, and quality boundaries. It is critical to document any changes to the scope baseline and to
balance them between the competing demands of cost, schedule, and quality. Failure to define the project
scope carefully is one of the most pervasive causes of poor project performance, because everything
hinges on the defined scope.

Preliminary Project Scope Statement Elements

The preliminary project scope statement may not contain all the detail about the elements that will appear
in the detailed project scope statement, but it will probably have an outline of each element. The more
definition each element has at this point, the more accurate the remaining project management results will
be.
A preliminary project scope statement includes:
• Project and product objectives
• Product or service requirements and characteristics
• Product acceptance criteria
• Project boundaries (this includes dependencies on other projects)
• Project requirements and deliverables
• Constraints and assumptions
• Initial project organization
• Initial defined risks
• Schedule milestones
• Initial WBS
• Order of magnitude cost estimate
• Project configuration management requirements
• Approval requirements

Page 101
Product Scope vs. Project Scope
It is important to emphasize the difference between product scope and project scope.
• Product Scope – The features and functions that characterize a product, service, or result
• Project Scope – The work that must be performed to deliver a product, service, or result with the
specified features and functions
The preliminary project scope statement describes the project scope.

Inputs, Tool and Techniques, and Outputs

The diagram below shows the inputs, tools and techniques, and outputs of the Develop Preliminary
Project Scope Statement process.

Inputs, Tools and Techniques, and Outputs - Develop Preliminary Project Scope Statement

Inputs to the Develop Preliminary Project Scope Statement Process

Project Charter
The project charter is a document that formally authorizes a project and gives the project manager the
authority to apply organizational resources to project activities.
Project Statement of Work
A statement of work (SOW) is a narrative description of the project’s products or services. The SOW
includes a description of the product’s scope. It should also reflect the business need and strategic plan for
the organization.
Enterprise Environmental Factors
The organization’s enterprise environmental factors and systems that surround and influence the project
success must be considered.
Organizational Process Assets
These are the organization’s processes and procedures for conducting project work, as well as the
organizational corporate knowledge base for project information.

Page 102
Tools and Techniques for the Develop Preliminary Project Scope Statement
Process
Project Management Methodology
The project management methodology defines how the preliminary project scope statement will be
developed and changed.
Project Management Information System (PMIS)
The project management team uses the project management information system to draft the initial
preliminary project scope statement, conduct reviews and incorporate comments, and release the
approved version.
Expert Judgment
Any group or individual with specialized knowledge can provide expert judgment to assess the inputs
needed to develop the preliminary project scope statement.

Outputs from the Develop Preliminary Project Scope Statement Process

Preliminary Project Scope Statement
The preliminary project scope statement addresses and documents the characteristics and boundaries of
the project scope, including the product or service it will deliver. It also defines how the project scope
statement itself must be approved.
The preliminary project scope statement and the subsequent project scope statement describe in detail the
project’s deliverables and the work required to produce those deliverables. The preliminary project scope
statement also includes a section for an initial work breakdown structure (WBS). (The work
breakdown structure and the work breakdown structure dictionary are described below.)
From this point forward, Project Integration Management will be used to continuously evaluate and
validate the project objectives as expressed in the preliminary project scope statement.
Initial Work Breakdown Structure (WBS)
In order to plan and schedule work, the project manager must view the project at a very detailed level.
The project work must be broken down, or “decomposed,” into progressively smaller chunks until they
are small enough to be accurately estimated and effectively managed and controlled.
This deliverable-oriented, hierarchical map of the project work is the work breakdown structure
(WBS).
The PMBOK® Guide, Third Edition provides the following definition of work breakdown structure.

Definition: Work Breakdown Structure (WBS)

A deliverable-oriented hierarchical decomposition of the work to be executed by the project

team to accomplish the project objectives and create the required deliverables. It organizes
and defines the total scope of the project. Each descending level represents an increasingly
detailed definition of the project work. The WBS is decomposed into work packages. The
deliverable orientation of the hierarchy includes both internal and external deliverables.
PMBOK® Guide, Third Edition, Glossary

Page 103
Definition of Work Breakdown Structure Dictionary
In addition to the work breakdown structure, the Develop Preliminary Project Scope Statement process
also creates the work breakdown structure dictionary. This dictionary defines each WBS component by
describing a number of key attributes for the deliverable.
The PMBOK® Guide, Third Edition, provides the following definition of work breakdown structure
dictionary.

Definition: Work Breakdown Structure Dictionary

A document that describes each component in the work breakdown structure (WBS). For
each WBS component, the WBS dictionary includes a brief definition of the scope or
statement of work, defined deliverable(s), a list of associated activities, and a list of
milestones. Other information may include: responsible organization, start and end dates,
resources required, an estimate of cost, charge number, contract information, quality
requirements, and technical references to facilitate performance of the work.
PMBOK® Guide, Third Edition, Glossary

An example of a simple graphical WBS is shown below.

WBS Format Example
There are several methods for portraying the WBS. The hierarchically organized depiction of a WBS
shown below is intuitive and easy to follow. It makes clear which components are required for each
deliverable and which subcomponents are required for each component. The numbering system and
placement in the tree facilitate this ease of understanding. Relationships between components of the WBS
are explicitly shown by the lines between them, greatly reduce errors in developing or reading the WBS.

PMBOK® Guide, Third Edition: WBS Hierarchical Graphic Format Example

The graphic format has the advantage of being easy to scan and easy to use to locate components. This
makes it extremely efficient during the Create WBS process as the different components and
subcomponents are identified and rearranged to suit the project manager’s purposes. It is also easiest and
most efficient to use during review and validation of the work breakdown structure.

Page 104
3-4: Develop Project Management Plan
The Develop Project Management Plan process involves defining, consolidating, and coordinating all the
subsidiary plans from the Planning processes from other Knowledge Areas into an integrated whole. The
project management plan is then updated through the Integrated Change Control process that follows.
The following pages will cover:
• The Definition of a Project Management Plan
• Project Management Plan: Subsidiary Plans
• Inputs, Tools and Techniques, and Outputs
• Inputs to the Develop Project Management Plan Process
• Tools and Techniques for the Develop Project Management Plan Process
• Outputs from the Develop Project Management Plan Process
• Project Management Plan Review
• Approval Process

Page 105
Definition of a Project Management Plan
The PMBOK® Guide, Third Edition, provides the following definition of the project management plan.

Definition: Project Management Plan

A formal, approved document that defines how the project is executed, monitored and
controlled. It may be summary or detailed and may be composed of one or more subsidiary
management plans and other planning documents.
PMBOK® Guide, Third Edition, Glossary

The project management plan can be either summary or detailed. It incorporates, either directly or by
reference, all the plans that were created and refined in the other Knowledge Areas.
The project management plan also includes:
• A milestone list
• A resource calendar
• The schedule, cost, and quality baselines
• The risk register

Project Management Plan: Subsidiary Plans

One common error that many project team members make is thinking of the schedule as the project
management plan. In fact, the project management plan is a list of documents that are the result of a
number of Planning processes, and include a number of subsidiary management plans as part of the
overall plan.
Some of these subsidiary plans include, but are not limited to, the following:
• Project scope management plan
• Schedule management plan
• Cost management plan
• Quality management plan
• Process improvement plan
• Staffing management plan
• Communications management plan
• Risk management plan
• Procurement management plan

Page 106
Inputs, Tools and Techniques, and Outputs
The diagram below shows the inputs, tools and techniques, and outputs of the Develop Project
Management Plan process.

Inputs, Tools and Techniques, and Outputs - Develop Project Management Plan

Inputs to the Develop Project Management Plan Process

Preliminary Project Scope Statement
This document addresses and documents the characteristics and boundaries of the project scope and its
associated product or service. Each element of the preliminary project scope statement’s initial work
breakdown structure will drive planning activity in the other Planning processes.
Project Management Processes
The Project Management processes for all the other Knowledge Areas contribute to the overall project
management plan’s format and content.
Enterprise Environmental Factors
Elements of the organization’s enterprise environmental factors that will affect the decisions reflected in
the project management plan include:
• Organizational culture and structure
• Standards (both industry and regulatory)
• Infrastructure
• Available resources
• Stakeholder risk tolerances
• Marketplace conditions

Page 107
Organizational Process Assets
These are the organization’s processes and procedures for conducting project work, as well as the
organizational corporate knowledge base for project information. The assets that affect the project
management plan include:
• Standard processes and life cycles
• Quality procedures and tools
• Definitions of how product development activities are to be carried out
• Guidance on tailoring the standards processes to be used on individual projects
• Financial controls
• Issue and defect management procedures
• Change control procedures
• Risk management procedures and tools
• Work authorization procedures

Tools and Techniques for the Develop Project Management Plan Process
Project Management Methodology
Many of the standard processes, milestones, approvals, etc., are defined in an organization’s project
management methodology. Using a PM methodology has the following tangible benefits:
• Ensuring that all project team members have the same ideas about how things are organized
• Providing an accepted, well-balanced, and effective definition of activities that will produce the
required deliverables
• Assigning each activity to a specific project team role
• Communicating the responsibility, authority, and accountability for each role
• Ensuring that there is shared understanding about the purpose of the project’s deliverables and
their acceptance criteria, including applicable standards
Project Management Information System (PMIS)
The PMIS contains the automated set of tools to plan, manage, and control project activities and to serve
as a communications tool for the entire project team. Many of these tools also include templates and maps
that help in the planning process.
Configuration Management System: A Subsystem of PMIS
The configuration management system includes all the processes for submitting proposed changes,
tracking the review and approvals, authorizing approvals, and validating the approved changes.
Application of the configuration management system, which includes change control, provides:
• A process for consistently identifying, requesting, and assessing all change requests
• A chance to audit and improve Project Management processes by forcing the team to evaluate
each change in the light of its impact on the project’s objectives
• The communications system for change notification

Page 108
Change Control System – A Subsystem of PMIS
The change control system is a formal set of procedures that specifies how project deliverables and
documentation will be controlled, changed, and approved.
Expert Judgment
Subject matter experts (SMEs) can help define the technical details to be included in the project
management plan.

Outputs from the Develop Project Management Plan Process

Project Management Plan
The project management plan outlines all the details of the project, including expectations of scope, cost,
and schedule, and describes how project work will be performed to meet these expectations.
The project management plan documents:
• The tailoring of the project management processes selected by the project management team
• How work will be executed
• How changes will be monitored and controlled
• How configuration management will be performed
• How communications will be carried out with stakeholders
• The chosen project life cycle and any tailoring
• The timing and content of key management reviews
Project Management Plan Review
The project management plan should be formally reviewed and approved by stakeholders to ensure that
stakeholder expectations are correctly represented. All changes to the project management plan should be
approved; this facilitates consistent communication to all the stakeholders regarding the project’s
direction.
Approval of the project management plan or its components is a significant action on the part of the
project stakeholders, and may determine their level of commitment. Project stakeholders are likely to ask
a number of questions. The project manager should pay close attention to the questions most important to
the project sponsor. This helps the project manager understand the stakeholders’ criteria for success.
Listed below are some questions that project stakeholders may ask.
• How important is the problem or opportunity to the enterprise?
• How is the project related to the company’s business strategy?
• Do the project’s objectives address the business need effectively?
• Does the project solution seem likely to meet the project objectives?
• Are the project deliverables clear representations of the solution?
• Is there sufficient business value to warrant further expenditures on the project?
• Is the relationship between project deliverables and project objectives clearly established?
• Are the risks acceptable and manageable?

Page 109
 • What should the priority of this project be?
• How does this project fit in with other projects that are under way or being considered?
Remember that the project management plan is an ongoing working document. Sometimes an approved
project management plan is signed off, filed, and rarely revisited. The project manager should ensure that
project management plans are constantly being reviewed.
Approval Process
Approval of the project management plan components is a significant event that requires input from:
• Senior management: To state that the project management plan components meet their
expectations, and that project work should proceed
• Customers: To concur that the business need has been correctly described and that they are in
agreement with the solution being offered
• Project team: To indicate that the project has been clearly defined at the necessary level of
detail, and that the project work necessary to meet the expectations can be performed within the
proposed constraints of cost, quality and scope, and schedule

Page 110
3-5: Direct and Manage Project Execution
The Direct and Manage Project Execution process requires that the project manager and team execute all
of, and only, the work in the approved project management plan.
During project management plan execution, team members carry out the details of the plan and generate
work results. Change requests may result from variances in performance from the plan, or the need to
change scope to seize opportunities. Properly authorized corrective actions, preventive actions, and defect
repairs may also be implemented during this process.
The following pages will cover:
• Definition of Direct and Manage Project Execution
• Inputs, Tools and Techniques, and Outputs
• Inputs to the Direct and Manage Project Execution Process
• Tools and Techniques for the Direct and Manage Project Execution Process
• Outputs from the Direct and Manage Project Execution Process
• Defect Repair Process Flow

Page 111
Definition of Direct and Manage Project Execution
Direct and Manage Project Execution is the first process in the Executing Process Group, in which the
project management team carries out the approved plan and produces work results. The vast majority of
the project’s budget is typically spent in project execution.

Definition: Direct and Manage Project Execution

The process of executing the work defined in the project management plan to achieve
the project’s requirements defined in the project scope statement.
PMBOK® Guide, Third Edition, Appendix F, Summary of Project Management Knowledge Areas

The Direct and Manage Project Execution process is the “Do” of the Plan-Do-Check-Act cycle, in which
the project team produces the project deliverables and accepted products. They may also generate defects,
rework, and change requests.
Any requested changes are recommended during the Monitor and Control Project Work process,
approved as part of the Integrated Change Control process, and implemented during the Direct and
Manage Project Execution process.
The Integrated Change Control process implements approved corrective actions, preventive actions, and
change requests. It is the iterative nature of the PDCA cycle that allows this cycle to integrate adjustments
to project work, and enables the Project Management processes to keep the project on track.

Inputs, Tools and Techniques, and Outputs

The diagram below shows the inputs, tools and techniques, and outputs of the Direct and Manage
Project Execution process.

Inputs, Tools and Techniques, and Outputs – Direct and Manage Project Execution

The main goal of the Direct and Manage Project Execution process is to perform the work outlined in the
project management plan. The project manager’s primary responsibility in this process is to promote the
smooth execution of the project management plan, to implement change requests, defect repairs, and
corrective and preventive actions, and to collect data for monitoring progress.

Page 112
Inputs to the Direct and Manage Project Execution Process
Project Management Plan
The project management plan defines the details of the project work, including objectives of scope, cost,
and schedule, and describes how project work will be performed to meet these objectives.
Approved Corrective Actions
These are authorized actions that are required to bring the project’s future performance back into
conformance with the project management plan.
Approved Preventive Actions
These are authorized actions designed to reduce the probability or impact of forecasted deviations from
project plan.
Approved Change Requests
These are authorized changes to the project activities or work products.
Approved Defect Repair
These are authorized instructions to repair a defect found during the Perform Quality Control process.
Validated Defect Repair
This is a notification that defects have been repaired.
Administrative Closure Procedure
This is the procedure that governs the formal closing of a project within the organization. It entails the
collection and recording of project reports and documents to create project archives. The administrative
closure procedure describes who does what, and how, to collect project records, analyze the project’s
overall performance, and store the information for later use. As administrative closure is performed at the
end of a phase, the Direct and Manage Project Execution process applies the administrative closure
procedure to carry out the necessary tasks.

Tools and Techniques for the Direct and Manage Project Execution
Process
Project Management Methodology
The project management methodology will define the procedures required for executing the project
management plan. The disposition of deliverables and work performance information, standard reporting
procedures, and change control processes should all be outlined in the methodology.
Project Management Information System (PMIS)
The PMIS contains the automated set of tools to plan, manage, and control project activities, and to serve
as a communications tool for the entire project team. Many of these tools also support the team in
authorizing and executing the project work, reporting work performance information, and storing and
controlling deliverables.

Page 113
Outputs from the Direct and Manage Project Execution Process
Deliverables
The project team performs work to produce the deliverables as specified in the project management plan.
In addition to creating the deliverables, the team must control, verify, and validate them as well.
There are two types of deliverables: those related to the product or service that the project will deliver,
and project management deliverables.
The project management deliverables result from activities such as:
• Staffing, developing, and training the project team
• Obtaining quotes, bids, and proposals for outsourced work
• Selecting and managing contractors
• Implementing the planned quality objectives
• Monitoring and managing risk
• Communicating with the stakeholders
• Collecting project data and acting on any performance issues
• Collecting and documenting lessons learned
Requested Changes
Although the project may have been planned with great care and in great detail, plans will inevitably
change. Changes occur in many ways: from an internal source, as a way of performing differently than
planned, or as an external request from the customer.
Changes to the project management plan can also occur as work is performed. For example, an activity
duration estimate could be overly aggressive in the plan and in need of adjustment as a result of receiving
information regarding current performance. Such changes are first reflected in requested changes that are
forwarded to the Integrated Change Control process.
Implemented Change Requests
Approved changes to the project deliverables are completed.
Implemented Corrective Actions
If the performance of the project team is not in alignment with the baseline plan, then corrective action
may be needed to bring the performance level into conformance with the plan.
Implemented Preventive Actions
During the course of project execution, risks are monitored, responded to, or retired. Approved preventive
actions are actions that the team has implemented to reduce the probability or consequences of a project
risk, or of a forecasted deviation from plan.
Implemented Defect Repair
Project execution produces work results, which are then run through the Perform Quality Control process
to verify that they conform to requirements. For those work results that do not conform, the project team
needs to correct the defects, and then feed back into the Direct and Manage Project Execution process.
This sequence of events is illustrated on a later page.

Page 114
Work Performance Information
Work performance information can come in the form of status reports. The project manager reviews the
progress, identifying any areas that signal a need for change to one of the project parameters of scope,
time (schedule), cost, or quality.
Typical information would include:
• Schedule status
• Deliverable completion information
• Cost expenditure information
• Estimates to complete
• Percentage completed
• Resource utilization information
• Conformance to quality standards
• Documented lessons learned

Defect Repair Process Flow

Deliverables are both created and repaired during this process. This is because the project task may have
to be performed again (usually only partially) to remove any identified defects.

Defect Repair Process Flow

1. Deliverables and work performance information are passed by the Direct and Manage Project
Execution process to the Perform Quality Control process.
2. The Perform Quality Control process identifies any defects in the deliverables and passes the
quality control results to the Monitor and Control Project Work process.

Page 115
 3. The Monitor and Control Project Work process passes a recommended defect repair to the
Integrated Change Control process.
4. The approved defect repair is passed back to the Direct and Manage Project Execution process.
5. The Direct and Manage Project Execution process implements the repair.
6. The implemented defect repair is re-inspected in Perform Quality Control, and if satisfactory,
the validated defect repair is passed to the Integrated Change Control process.
7. The validated defect repair is passed from the Integrated Change Control process to the Direct
and Manage Project Execution process where the status of the deliverable is updated to
“completed.”

Page 116
3-6: Monitor and Control Project Work
The Monitoring and Controlling Process Group addresses not only the work being done within a Process
Group, but also the entire project effort. The Monitor and Control Project Work process is performed to
monitor and control all processes concerned with initiating, planning, executing, and closing a project or
phase.
The following pages will cover:
• Project Performance
• The Monitor and Control Project Work Process
• Inputs, Tools and Techniques, and Outputs
• Inputs to the Monitor and Control Project Work Process
• Tools and Techniques for the Monitor and Control Project Work Process
• Outputs from the Monitor and Control Project Work Process

Page 117
Project Performance
The project management team tracks project performance, measures it against the plan, and recommends
actions based on any variances from plan. They also concern themselves with the distribution of
information about any changes or variances.
Some of the areas of concentration are:
• Comparing actual project performance to planned performance
• Analyzing performance
• Analyzing, tracking, and monitoring project risks
• Maintaining accurate, timely information about project performance
• Providing information for status and progress reporting
• Providing forecasts
• Monitoring the implementation of approved changes

The Monitor and Control Project Work Process

The Monitor and Control Project Work process, together with the next process, Integrated Change
Control, represent the CHECK and ACT portions of the PDCA model. In this portion of the model,
variances are identified and measured, and corrective or preventive actions are taken to control the project
performance. The sooner an error or defect is uncovered and acted on, the easier and more cost effective it
is to fix. Therefore, it is a good practice to monitor and identify problems early and often to minimize the
impact to the project’s objectives.
Continuous monitoring provides insight into the health of projects, not only from the point of view of the
project activities, but also of the Project Management processes. Understanding project performance can
yield improvements within the both the project activities and the Project Management processes.

Inputs, Tools and Techniques, and Outputs

The diagram below shows the inputs, tools and techniques, and outputs of the Monitor and Control
Project Work process.

Page 118
Inputs, Tools and Techniques, and Outputs Monitor and Control Project Work

Inputs to the Monitor and Control Project Work Process

Project Management Plan
This is the document that outlines all the details of the project, including project objectives for scope,
cost, and schedule. It also addresses how project work will be performed to meet these objectives.
Work Performance Information
Information on the status of the project activities is routinely collected as part of the project management
plan execution. This information will indicate any problems in the performance of project activities.
Rejected Change Request
Rejected change requests include the change requests, their supporting documentation, and their change
review status showing the disposition of rejected change requests. Any change requests that are rejected
may need to be further analyzed to determine the impact of not being implemented. This in turn will yield
additional corrective or preventive actions or a different change request in order to reduce or eliminate the
deviation from the project management plan.

Tools and Techniques for the Monitor and Control Project Work Process
Project Management Methodology
The project management methodology will outline the processes required for monitoring and controlling
project performance. Templates, standard reports, and change control processes should all be outlined in
the methodology.
Project Management Information System (PMIS)
The PMIS contains the automated set of tools for planning, managing, and controlling project activities,
and serving as a communications tool for the entire project team. Many of these tools also include
templates and maps that help the team monitor and control project work.

Page 119
Earned Value Technique
Earned value is a technique used to forecast future performance using information about prior
performance. It is a means of quantifying project performance against the approved project baselines.
Earned value relates the actual cost of project work to the progress achieved. By comparing the earned
value to the planned value of the work, the project manager can obtain early warning about a pending
schedule or budget overrun. This information can then be used to develop forecasts, which can in turn be
used to initiate preventive or corrective actions or requested changes.
There are a few prerequisites for using earned value as a measurement technique:
• Project scope must be fully defined.
• The project’s baselines (schedule, cost, quality and scope) need to be fully integrated.
• A time-phased project budget must be in place.
Expert Judgment
Subject matter experts (SMEs) help monitor and control the technical and management details of the
project work. They can also help define corrective or preventive actions and suggest requested changes to
address project performance problems.

Outputs from the Monitor and Control Project Work Process

The Monitor and Control Project Work process is where work products, risks, and change requests are all
watched and where appropriate responses are recommended. These actions are approved in the Integrated
Change Control process and implemented in the Direct and Manage Project Execution process.
Recommended Corrective Actions
Corrective actions are recommended to bring future project performance back in line with the approved
project management plan.
Recommended Preventive Actions
Preventive actions are recommended to reduce the probability or impact of future project performance
variances. Risks are continually monitored and reported on during this process, and, if required,
preventive actions are recommended.
Forecasts
A forecast is an estimate or prediction of the project activities’ future performance. This prediction is
based on the most current information available at the time of the forecast, so forecasts need to be updated
and reissued continually based on work results and project performance.
Recommended Defect Repair
Quality control activities will uncover defects. In these cases, the project team will recommend repair
alternatives.
Requested Changes
Sometimes, as a result of monitoring the project work progress, the project management team determines
that it is necessary to make a change to the project scope or to one of the other parts of the project
management plan. This may be due to an error, a problem with a project process that does not perform as
expected, or an external factor beyond the project’s control. These requested changes are generated here
and transferred to the Integrated Change Control process for evaluation and approval.

Page 120
3-7: Integrated Change Control
Integrated Change Control is performed from project inception through completion, because change is
continuous on any project. Requested changes are reviewed, and if appropriate, approved. Additional
changes to other aspects of the project baselines may be necessary to maintain the balance among the
project’s objectives. The project performance baselines must be maintained whenever approved change
requests must be incorporated.
The following pages will cover:
• Definition of Integrated Change Control
• Integrated Change Control Process
• Integrated Change Control Factors
• Inputs, Tool and Techniques, and Outputs
• Inputs to the Integrated Change Control Process
• Tool and Techniques for the Integrated Change Control Process
• Outputs from the Integrated Change Control Process
• Charting a Typical Change Control Process
• Outcomes of Requested Changes

Page 121
Definition of Integrated Change Control
The Integrated Change Control process is performed from the project inception through completion.
Change control is necessary because a project never runs exactly according to the project management
plan.

Definition: Integrated Change Control

The process of reviewing all change requests, approving changes and controlling changes to
deliverables and organizational process assets.
PMBOK® Guide, Third Edition, Glossary

Integrated Change Control Process

The project management plan and the project scope statement and other deliverables must be maintained
by continuously managing changes, by either rejecting or approving them so that the approved changes
are incorporated into the revised baseline.
The Integrated Change Control process includes the following change management activities:
• Identifying whether a change needs to occur or has occurred
• Reviewing and approving or rejecting requested changes
• Managing the flow of requested and approved changes
• Maintaining the integrity of the performance measurement baselines by releasing only approved
changes
• Reviewing and approving all corrective and preventive actions
• Controlling changes to the scope, cost, schedule, and quality requirements across the entire
project
• Documenting the impact of all changes
• Validating defect repair

Integrated Change Control Factors

Requested changes can involve any aspect of the project, such as cost estimates, project activities,
estimated productivity rates, or resource requirements. These changes can affect the project management
plan, project scope statement, or other project deliverables. The applied level of change control depends
on the application area and the size, complexity, and risk of the project.
The Integrated Change Control process should define these factors:
• Who can request a change?
• What is the process for handling the change request?
• How is the impact of the change to the project determined?
• Who evaluates the impact to the project versus the benefit of the change?
• How are changes disposed of or incorporated into the project?

Page 122
Input, Tools and Techniques, and Outputs
The diagram below shows the inputs, tools and techniques, and outputs of the Integrated Change
Control process.

Inputs, Tools and Techniques, and Outputs – Integrated Change Control

Integrated Change Control uses the work performance information from the Direct and Manage Project
Execution process and compares performance to the project baseline to determine if changes are needed.
The change control process is initiated by change requests.
Recommended corrective and preventive actions are evaluated and approved.
During Integrated Change Control, recommended defect repairs are evaluated. After such repairs have
been attempted, their effectiveness is validated.

Page 123
Inputs to the Integrated Change Control Process
Project Management Plan
The project management plan describes how Integrated Change Control will be performed. It also
supports evaluating the impact of recommended requested changes and corrective and preventive actions
across the entire project’s deliverables and objectives.
Requested Changes
Requested changes include supporting documentation and the disposition of the changes. All requested
changes are analyzed for their cross-project impact, as well as their impact on the project objectives.
Work Performance Information
Information on the status of the project activities is routinely collected as part of executing the project
management plan. During Integrated Change Control, this information is analyzed to determine whether
corrective actions, preventive actions, or requested changes are justified.
Recommended Preventive Actions
Preventive actions are documented recommendations that reduce the probability of negative
consequences associated with project risks.
Recommended Corrective Actions
Corrective actions may be approved to bring future project performance back in line with the approved
project management plan.
Recommended Defect Repair
Any defects that are identified during the Perform Quality Control process can be recommended for
defect repair.
Deliverables
A deliverable is any unique and verifiable product, result, or capability that is identified in the project
management plan. Deliverables may be reviewed in conjunction with quality control to validate defect
repairs or to determine whether requested changes are warranted and represent the best solution to a
project performance problem.

Tools and Techniques for the Integrated Change Control Process

Project Management Methodology
The project management methodology may define how changes are to be controlled and approved in a
particular organization and may also specify how changes are to be evaluated.
Project Management Information System
The PMIS gathers, integrates, and disseminates information regarding project performance and the status
of deliverables and requested changes. It also serves to communicate and support the implementation of
corrective and preventive actions. The PMIS also supports the control of project deliverables and makes a
record of their status.
Expert Judgment
Subject matter experts (SMEs) will help evaluate corrective and preventive actions and the impact of
change requests. They can also recommend additional changes to balance the impact of requested changes
on the project objectives.

Page 124
Outputs from the Integrated Change Control Process
The Integrated Change Control process produces one of the largest varieties of outputs in the entire
Project Management Framework.
Approved Change Requests
These are authorized changes to expand or contract project scope or other baselines.
Rejected Change Requests
Rejected change requests include change requests, supporting documentation, and change review status
showing the disposition of a rejected change request.
Project Management Plan Updates
Updates to the project management plan are required if the changes necessitate an adaptation to the
original project management plan. These project management plan updates must be formally approved
and should be communicated to all affected stakeholders.
Project Scope Statement Updates
Updates to the project scope statement are required if an approved change affects the scope of work
performed.
Approved Corrective Actions
Corrective actions are taken to realign performance with the details of the project management plan.
Approved Preventive Actions
Preventive actions are approved to deal with risks or to reduce or eliminate the probability or impact of
future project variances.
Approved Defect Repairs
Defects that have been identified in the Monitor and Control Project Work process via the Perform
Quality Control process lead to the generation of defect repairs. The Perform Quality Control process
identifies the defect and recommends repair. The Direct and Manage Project Execution process
implements the defect repair.
Validated Defect Repair
Defect repairs that have been completed in the Direct and Manage Project Execution process are validated
in conjunction with the Perform Quality Control process.
Deliverables
These are deliverables that have been approved by the Integrated Change Control process.

Charting a Typical Change Control Process

Managing changes is handled at various levels in the project and stakeholder community. If the original
scope, quality, time, and cost objectives are being met and only a procedure or process within the project
needs to be changed, this can be handled by the project manager. The project manager can also resolve
any issues that only require the reallocation or redirection of project resources that are already under his
control.
The project manager may be also able to resolve the problem by using available schedule float (for
schedule) or contingency reserves (for schedule or cost).

Page 125
When these options are not available or sufficient to address the project performance problem, a requested
change to one of the project baselines must be submitted. This diagram illustrates the flow of a requested
change through the Integrated Change Control process.

A requested change may ripple through Scope Control, Schedule Control, Cost Control, Perform Quality
Control, Risk Monitoring and Control, and Contract Administration. Attention to all these areas and
others during the Integrated Change Control process will minimize problems later in the project that that
might result from changing an apparently isolated element of the project.
Many plans (quality, risk, procurement, etc.) are under configuration control and will have to be updated.
This forces an important part of change control: documentation. First, the project management team must
document the change request and the resulting assessment; then, the project management team must
follow through with updates to all affected subsidiary plans, baselines, and any related deliverables.

Outcomes of Requested Changes

Some of the possible outcomes of change that the team should consider are shown below. The outcomes
of the change may differ depending upon the original requested change and the magnitude of the solution.
Possible outcomes of requested changes include:
• There is no impact on schedule or budget.
• More time is needed – the project schedule must be altered.
• More resources are needed to accommodate the change so as not to impact the schedule; the
project budget must be altered.
• Major alteration of the project scope leads to considering multiple release versions; this requires
prioritizing deliverables across release dates.
• A major change to the project requires the scope of the project to be redefined and all baselines to
be altered.

Page 126
3-8: Close Project
The Close Project process closes the current phase. If this is the last phase in the project, the project is
also closed.
The following pages will cover:
• Definition of Close Project
• Inputs, Tools and Techniques, and Outputs
• Inputs to the Close Project Process
• Tools and Techniques for the Close Project Process
• Outputs from the Close Project Process

Page 127
Definition of Close Project
The PMBOK® Guide, Third Edition, definition of Close Project is presented below.

Definition: Close Project

The process of finalizing all activities across all of the project process groups to formally close
the project or phase.
PMBOK® Guide, Third Edition, Glossary

The outcome of closure may be:

• A successful completion
• The suspension of all activities perhaps to prepare for their later resumption or a wholesale
transfer to another performing organization
• The cancellation of the project

Inputs, Tools and Techniques, and Outputs

The diagram below shows the inputs, tools and techniques, and outputs of the Close Project process.

Inputs, Tools and Techniques, and Outputs – Close Project

The Close Project process develops the procedures for administrative closure and contract closeout for
use in other processes. It also generates changes to the organizational process assets, such as estimating
guidelines or project lifecycle templates, as a result of the project team’s experience on this project.

Page 128
Inputs to the Close Project Process
Project Management Plan
The project management plan defines the project scope and how it is to be addressed in each phase. The
Close Project process closes out each phase only when the associated scope is completed; the associated
scope is indicated by the deliverables that are attached to that project phase in the project management
plan.
Contract Documentation
Contract documentation includes the contract, changes to the contract, and other documentation, such as
criteria for accepting deliverables and procedures. Comparing the contractor’s work products and work
performance to the terms and conditions of the contract allows the project manager to determine whether
to accept the work products and close the contract.
Enterprise Environmental Factors
Enterprise environmental factors that influence the Close Project process include:
• The organizational culture and structure, which may dictate how formally such closure must be
observed and whether celebrations are appropriate
• Governmental and industry standards, which may necessitate the participation of certain oversight
bodies in the Close Project process
• Infrastructure of the organization, which may need to be returned to general use or turned over to
another project
• Human resources, who may be reclassified or subject to a review as a result of increased
capabilities and may be eligible for an out-of-cycle compensation review
• Work authorization system, which will dictate how and when entries related to the current project
phase are declared closed
• Marketplace conditions, which may result in supplementary efforts to retain project alumni or to
make the team members eligible for furlough
• Shareholder risk tolerances, which may dictate how strictly project closure for a phase must be
completed before the next phase may be initiated or the deliverables approved
Organizational Process Assets
Organizational process assets that are used during the Close Project process include:
• Standard process assets such as project life cycles, templates, and quality procedures that may
specify how project closure is to be conducted, and what deliverables are required to be
completed
• Tailoring guidance that may indicate how standard processes can be adapted for this project
• Organization communications requirements and options that will suggest how project phase
closure notification is to be published, what information stakeholders are to receive regarding the
closure, and when
• Financial controls procedures and practices that indicate how the project budget for the closing
phase is to be closed out
• Issue and defect management procedures that specify whether and how open issues and defects
are to be carried forward and resolved after the formal closure process is completed, if any remain

Page 129
Work Performance Information
Work performance information will indicate whether all relevant deliverables have been successfully and
satisfactorily completed.
Deliverables
Key phase-end deliverables will generally be presented to the sponsor and other governing representatives
for their formal review and approval. In some cases, the deliverable itself, such as a bridge or a company
headquarters building, may be involved only symbolically in the transfer of the product into operational
status, for instance, through a ceremony.

Tools and Techniques for the Close Project Process

Project Management Methodology
The project management methodology describes how the project management team defines the
administrative closure procedures and then executes them.
Project Management Information System (PMIS)
The PMIS supports the work of closing the contracts, phases, and projects.
Expert Judgment
Expert judgment can be employed in defining and executing the administrative and Contract Closure
procedures.

Outputs from the Close Project Process

Administrative Closure Procedure
Administrative closure is the process of formally closing a project within the organization. It entails
collecting and archiving project reports and documents to create project archives. The administrative
closure procedure describes who does what, and how, to collect project records, analyze the project’s
overall performance, and store the information for later use.
Contract Closure Procedure
The Contract Closure procedure describes how to settle any contracts that are fulfilled by the project, and
how these should be addressed as part of administrative closure. The main types of activities include
verifying and accepting the outsourced deliverables, and updating the contract records to reflect the
outcome of the contract. In many cases, the contract itself specifies some steps that must be taken in the
Contract Closure procedure, such as how to verify the deliverables, how to handle disputes, and when and
how non-performance can result in early contract termination. This procedure is an output of the Close
Project process, and is used as an input to the Contract Closure process in the Project Procurement
Management Knowledge Area.
Final Product, Service or Result
This is the formal acceptance of the project’s final deliverables. It includes formal acknowledgments that
the terms of all contracts have been met.
Organizational Process Assets
The performing organization also captures lessons learned from the project to develop an internal
knowledge base of project work in order to enhance performance on future projects. These lessons
learned are then used to update the organization’s process assets, such as the project methodology,
estimating data, meeting management tools, and so on.

Page 130
During the Close Project process, organizational process assets may be developed or updated in the
following ways:
• Formal acceptance documentation: These documents confirm that the customer or sponsor was
satisfied with the project’s final deliverables because they met the specifications.
• Project files: These include project management documentation, including baselines, the project
management plan, and risk management information.
• Project closure documents: These document the completion of the project and the transfer of the
deliverables to the organization that will use them. In the case of a cancellation, they describe
why the project was terminated and arrange for the transfer or suspension of any incomplete
deliverables.
• Historical information: This represents the lessons learned, as recorded for use by future project
teams.
• Standard process assets: Project life cycles, templates, quality procedures, and other assets may
be updated to reflect new practices that were successfully adopted during the project.
• Guidance on tailoring standard processes: This may be updated based on different uses of
these processes during the project.
• Organization communications requirements and options: These may be updated if new
communications vehicles were developed, or alternative vehicles were used with greater success
than the standard vehicles.
• Financial controls procedures and practices: These may be updated if they were improved on.
• Issue and defect management procedures: These may be updated to reflect practice
improvements implemented on the current project.

Summary
Project Integration Management is used to help project managers and the project management team
coordinate the various elements of a project throughout the project’s life cycle to meet the project’s needs
and demands.
A project charter is a very powerful statement, in which the organization announces its intention and,
more importantly, authorizes the project manager to employ resources to progressively elaborate the
scope of the project.
Develop Project Management Plan is a process in the Project Integration Management Knowledge
Area. It integrates all the results of the Planning processes into a valid and cohesive project management
plan with supporting detail. This plan then feeds into the other Process Groups, and is refined, if
necessary, until the project is formally closed.
Direct and Manage Project Execution requires that the project manager and team execute the approved
project management plan. During execution of the project management plan, team members perform their
duties in carrying out the details of the plan and generate work results.
The Monitor and Control Project Work process is performed to monitor and control all processes
concerned with Initiating, Planning, Executing, and Closing a project or phase. In this process, the project
manager and team watch project performance, measure it against the plan, and recommend actions based
on variance from plan. This process also involves distributing information about any changes or
variances.

Page 131
Integrated Change Control is performed from project inception through completion, because change is
inevitable on any project. The defined project scope and performance baseline must be maintained by
continuously managing changes to the baseline, either by rejecting new changes or by approving changes
and incorporating them into a revised project baseline.
The Close Project process closes the current phase. If this is the last phase in the project, the project is
also closed. The outcome of closure may be a successful completion, the suspension of all activities, or
even the cancellation of the project.

Page 132