|Project Integration Management
includes the processes required to ensure that the
various elements of the project are properly coordinated.
It involves making trade-offs among competing objectives
and alternatives in order to meet or exceed stake-holder
needs and expectations. While all project management
processes are integrative to some extent, the processes
described in this chapter are primarily integrative.
Figure 41 provides an overview of the
following major processes:
4.1 Project Plan Developmenttaking the
results of other planning processes and putting them into
a consistent, coherent document.
4.2 Project Plan Executioncarrying out
the project plan by performing the activities included
4.3 Overall Change Controlcoordinating
changes across the entire project.
These processes interact with each other and with the
processes in the other knowledge areas as well. Each
process may involve effort from one or more individuals
or groups of individuals based on the needs of the
project. Each process generally occurs at least once in
every project phase. Although the processes are presented
here as discrete elements with welldefined interfaces, in
practice they may overlap and interact in ways not
Process interactions are discussed in detail in Chapter
3. The processes, tools, and techniques used to integrate
project management processes are the focus of this
chapter. For example, project integration management
comes into play when a cost estimate is needed for a
contingency plan or when risks associated with various
staffing alternatives must be identified. However, for a
project to be completed successfully, integration must
also occur in a number of other areas as well. For
work of the project must be integrated with the
ongoing operations of the performing
scope and project scope must be integrated (the
difference between product and project scope is
discussed in the introduction to Chapter 5).
from different functional specialties (such as
civil, electrical, and mechanical drawings for an
engineering design project) must be integrated.
al tope de la página
Project plan development uses the outputs of the other
planning processes to create a consistent, coherent
document that can be used to guide both project execution
and project control. This process is almost always
iterated several times. For example, the initial draft
may include generic resources and undated durations while
the final plan reflects specific resources and explicit
dates. The project plan is used to:
- Guide project
- Document project
- Document project
planning decisions regarding alternatives chosen.
communication among stakeholders.
- Define key management
reviews as to content, extent, and timing.
- Provide a baseline
for progress measurement and project control.
4.1.1 Inputs to
Project Plan Development
.1 Other planning outputs. All
of the outputs of the planning processes in the other
knowledge areas (Section 3.3 provides a summary of these
project planning processes) are inputs to developing the
project plan. Other planning outputs include both base
documents such as the work breakdown structure as well as
the supporting detail. Many projects will also require
application area-specific inputs (e.g., most construction
projects will require a cash flow forecast).
.2 Historical information. The
available historical information (e.g., estimating
databases, records of past project performance) should
have been consulted during the other project planning
processes. This information should also be available
during project plan development to assist with verifying
assumptions and assessing alternatives that are
identified as part of this process.
.3 Organizational policies. Any and
all of the organizations involved in the project may have
formal and informal policies whose effects must be
considered. Organizational policies which typically must
be considered include, but are not limited to:
managementprocess audits, continuous
administrationhiring and firing guidelines,
employee performance reviews.
controlstime reporting, required
expenditure and disbursement reviews, accounting
codes, standard contract provisions.
Constraints are factors that will limit the
project management teams options. For example, a
predefined budget is a constraint that is highly likely
to limit the teams options regarding scope,
staffing, and schedule. When a project is performed under
contract, contractual provisions will generally be
.5 Assumptions. Assumptions are factors that, for
planning purposes, will be considered to be true, real,
or certain. For example, if the date that a key person
will become available is uncertain, the team may assume a
specific start date. Assumptions generally involve a
degree of risk.
4.1.2 Tools and
Techniques for Project Plan Development
.1 Project planning methodology. A
project planning methodology is any structured approach
used to guide the project team during development of the
project plan. It may be as simple as standard forms and
templates (whether paper or electronic, formal or
informal) or as complex as a series of required
simulations (e.g., Monte Carlo analysis of schedule
risk). Most project planning methodologies make use of a
combination of "hard" tools such as project
management software and "soft" tools such as
facilitated start-up meetings.
.2 Stakeholder skills and knowledge. Every
stakeholder has skills and knowledge which may be useful
in developing the project plan. The project management
team must create an environment in which the stakeholders
can contribute appropriately (see also Section 9.3, Team
Development). Who contributes, what they contribute, and
when will vary. For example:
- On a construction
project being done under a lump sum contract, the
professional cost engineer will make a major
contribution to the profitability objective
during proposal preparation when the contract
amount is being determined.
- On a project where
staffing is defined in advance, the individual
contributors may contribute significantly to
meeting cost and schedule objectives by reviewing
duration and effort estimates for reasonableness.
.3 Project management
information system (PMIS). A project
management information system consists of the tools and
techniques used to gather, integrate, and disseminate the
outputs of the other project management processes. It is
used to support all aspects of the project from
initiating through closing and generally includes both
manual and automated systems.
4.1.3 Outputs from Project Plan Development
.1 Project plan. The
project plan is a formal, approved document used to
manage and control project execution. It should be
distributed as defined in the communications management
plan (e.g., management of the performing organization may
require broad coverage with little detail, while a
contractor may require complete details on a single
subject). In some application areas, the term integrated
project plan is used to refer to this document. A
clear distinction should be made between the project plan
and the project performance measurement baselines. The
project plan is a document or collection of documents
that should be expected to change over time as more
information becomes available about the project.
The performance measurement baselines represent a management
control that will generally change only
intermittently and then generally only in response to an
approved scope change.There are many ways to organize and
present the project plan, but it commonly includes all of
the following (these items are described in more detail
- Project charter.
- A description of the
project management approach or strategy (a
summary of the individual management plans from
the other knowledge areas).
- Scope statement,
which includes the project deliverables and the
- Work breakdown
structure (WBS) to the level at which control
will be exercised.
- Cost estimates,
scheduled start dates, and responsibility
assignments to the level of the WBS at which
control will be exercised.
measurement baselines for schedule and cost.
- Major milestones and
target dates for each.
- Key or required
- Key risks, including
constraints and assumptions, and planned
responses for each.
- Subsidiary management
plans, including scope management plan, schedule
management plan, etc.
- Open issues and
Other project planning outputs should be included in the
formal plan based upon the needs of the individual
project. For example, the project plan for a large
project will generally include a project organization
.2 Supporting detail. Supporting
detail for the project plan includes:
- Outputs from other
planning processes that are not included in the
information or documentation generated during
development of the project plan (e.g.,
constraints and assumptions that were not
documentation such as requirements,
specifications, and designs.
- Documentation of
This material should be
organized as needed to facilitate its use during project
al tope de la página
Project plan execution is the primary process
for carrying out the project planthe vast majority
of the projects budget will be expended in
performing this process. In this process, the project
manager and the project management team must coordinate
and direct the various technical and organizational
interfaces that exist in the project. It is the project
process that is most directly affected by the project
application area in that the product of the project is
actually created here.
4.2.1 Inputs to
Project Plan Execution
.1 Project plan. The project plan is
described in Section 184.108.40.206. The subsidiary management
plans (scope management plan, risk management plan,
procurement management plan, etc.) and the performance
measurement baselines are key inputs to project plan
.2 Supporting detail. Supporting
detail is described in Section 220.127.116.11.
.3 Organizational policies. Organizational
policies are described in Section 18.104.22.168 Any and all of
the organizations involved in the project may have formal
and informal policies which may affect project plan
.4 Corrective action. Corrective
action is anything done to bring expected future project
performance into line with the project plan. Corrective
action is an output of the various control
processesas an input here it completes the feedback
loop needed to ensure effective project management.
4.2.2. Tools and Techniques for Project Plan
.1 General management skills. General
management skills such as leadership, communicating, and
negotiating are essential to effective project plan
execution. General management skills are described in
.2 Product skills and knowledge.
The project team must have access to an
appropriate set of skills and knowledge about the project
product. The necessary skills are defined as part of
planning (especially in resource planning, Section 7.1)
and are provided through the staff acquisition process
(described in Section 9.2).
.3 Work authorization system. A
work authorization system is a formal procedure for
sanctioning project work to ensure that work is done at
the right time and in the proper sequence. The primary
mechanism is typically a written authorization to begin
work on a specific activity or work package.
The design of a work authorization system should balance
the value of the control provided with the cost of that
control. For example, on many smaller projects, verbal
authorizations will be adequate.
.4 Status review meetings. Status
review meetings are regularly scheduled meetings held to
exchange information about the project. On most projects,
status review meetings will be held at various
frequencies and on different levels (e.g., the project
management team may meet weekly by itself and monthly
with the customer).
.5 Project management information
system. The project management information system is
described in Section 22.214.171.124.
.6 Organizational procedures. Any
and all of the organizations involved in the project may
have formal and informal procedures useful during project
4.2.3 Outputs from Project Plan Execution
.1 Work results. Work
results are the outcomes of the activities performed to
accomplish the project. Information on work
resultswhich deliverables have been completed and
which have not, to what extent quality standards are
being met, what costs have been incurred or committed,
etc.is collected as part of project plan execution
and fed into the performance reporting process (see
Section 10.3 for a more detailed discussion of
.2 Change requests. Change
requests (e.g., to expand or contract project scope, to
modify cost or schedule estimates, etc.) are often
identified while the work of the project is being done.
al tope de la página
Overall change control is concerned with (a)
influencing the factors which create changes to ensure
that changes are beneficial, (b) determining that a
change has occurred, and (c) managing the actual changes
when and as they occur. Overall change control requires:
- Maintaining the
integrity of the performance measurement
baselinesall approved changes should be
reflected in the project plan, but only project
scope changes will affect the performance
- Ensuring that changes
to the product scope are reflected in the
definition of the project scope (the difference
between product and project scope is discussed in
the introduction to Chapter 5).
- Coordinating changes
across knowledge areas as illustrated in Figure
42. For example, a proposed schedule change
will often affect cost, risk, quality, and
4.3.1 Inputs to
Overall Change Control
.1 Project plan. The
project plan provides the baseline against which changes
will be controlled (see Section 126.96.36.199).
.2 Performance reports. Performance
reports (described in Section 10.3) provide information
on project performance. Performance reports may also
alert the project team to issues which may cause problems
in the future.
.3 Change requests. Change
requests may occur in many formsoral or written,
director indirect, externally or internally initiated,
and legally mandated or optional.
4.3.2 Tools and
Techniques for Overall Change Control
.1 Change control system.
A change control system is a collection of
formal, documented procedures that defines the steps by
which official project documents may be changed. It
includes the paperwork, tracking systems, and approval
levels necessary for authorizing changes.
In many cases, the performing organization will have a
change control system that can be adopted "as
is" for use by the project. However, if an
appropriate system is not available, the project
management team will need to develop one as part of the
Many change control systems include a change control
board (CCB) responsible for approving or rejecting change
requests. The powers and responsibilities of a CCB should
be well-defined and agreed upon by key stakeholders. On
large, complex projects, there may be multiple CCBs with
The change control system must also include procedures to
handle changes which may be approved without prior
review; for example, as the result of emergencies.
Typically, a change control system will allow for
"automatic" approval of defined categories of
changes. These changes must still be documented and
captured so that they do not cause problems later in the
.2 Configuration management. Configuration
management is any documented procedure used to apply
technical and administrative direction and surveillance
- Identify and document
the functional and physical characteristics of an
item or system.
- Control any changes
to such characteristics.
- Record and report the
change and its implementation status.
- Audit the items and
system to verify conformance to requirements .
In many application areas,
configuration management is a subset of the change
control system and is used to ensure that the description
of the project product is correct and complete. However,
in some application areas, the term configuration
management is used to describe any rigorous change
.3 Performance measurement. Performance
measurement techniques such as earned value (described in
Section 10.3.2.4) help to assess whether variances from
the plan require corrective action.
.4 Additional planning. Projects
seldom run exactly according to plan. Prospective changes
may require new or revised cost estimates, modified
activity sequences, analysis of risk response
alternatives, or other adjustments to the project plan.
.5 Project management information
system. Project management information
systems are described in Section 188.8.131.52.
4.3.3 Outputs from Overall Change Control
.1 Project plan updates. Project
plan updates are any modification to the contents of the
project plan or the supporting detail (described in
Sections 184.108.40.206 and 220.127.116.11, respectively). Appropriate
stakeholders must be notified as needed.
.2 Corrective action. Corrective
action is described in Section 18.104.22.168.
.3 Lessons learned. The causes of
variances, the reasoning behind the corrective action
chosen, and other types of lessons learned should be
documented so that they become part of the historical
database for both this project and other projects of the
al tope de la página