TULISAN
Nama
: Sains Fadhilah
NPM
: 26112788
Kelas
: 2KB05
Chapter 4
Project Integration
Management
Project
Integration Management includes the processes required to ensure that the
various elements of the project are properly coordinated. It involves making tradeoffs
among competing objectives and alternatives 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 4-1
provides an overview of the following major processes:
4.1
Project Plan Development — integrating and coordinating all project plans to create
a consistent, coherent document.
4.2
Project Plan Execution — carrying out the project plan by performing the
activities included therein.
4.3
Integrated Change Control — coordinating 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 indi viduals 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 well-defined
interfaces, in practice they may overlap and interact in ways not detailed here.
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 anumber of other areas
as well. For example:
ٱ
The work of the project must be integrated with the ongoing operations of the performing
organization.
ٱ
Product scope and project scope must be integrated (the difference between product
and project scope is discussed in the introduction to Chapter 5).
One of the techniques
used to both integrate the various processes and to measure the performance of
the project as it moves from initiation through to completion is Earned Value
Management (EVM). EVM will be discussed in this chapter as a project
integrating methodology, while earned value (EV), the technique, will be
discussed in other chapters as a tool to measure performance against the project
plan.
Project
management software is a tool that aids integration within a project. And it
may span all project management processes.
4.1
PROJECT PLAN DEVELOPMENT
Project
plan development uses the outputs of the other planning processes, including
strategic planning, 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
resource requirements and an undated sequence of activities while the subsequent
versions of the plan will include specific resources and explicit dates. The
project scope of work is an iterative process that is generally done by the project
team with the use of a Work Breakdown Structure (WBS), allowing the team to
capture and then decompose all of the work of the project. All of the defined
work must be planned, estimated and scheduled, and authorized with the use of
detailed integrated management control plans sometimes called Control Account Plans , or CAPs, in the
EVM process. The sum of all the integrated management control plans will
constitute the total project scope.
The
project plan is used to:
ٱ
Guide project execution.
ٱ
Document project planning assumptions.
ٱ
Document project planning decisions regarding alternatives chosen.
ٱ
Facilitate 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 WBS, and the supporting detail. Many projects will also
require application area-specific inputs (e.g., most major 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 that typically
must be considered include, but are not limited to:
ٱ Quality
management—process audits, continuous improvement targets.
ٱ Personnel administration hiring and firing
guidelines, employee performance reviews.
ٱ Financial controls time
reporting, required expenditure and disbursement reviews, accounting codes,
standard contract provisions.
.4 Constraints. A
constraint is an applicable restriction that will affect the perfor- mance of
the project. For example, a predefined budget is a constraint that is highly
likely to limit the team’s options regarding scope, staffing, and schedule. When
a project is performed under contract, contractual provisions will generally be
constraints.
.5 Assumptions. Assumptions
are factors that, for planning purposes, are considered to be true, real, or
certain. Assumptions affect all aspects of project planning, and are part of
the progressive elaboration of the project. Project teams frequently identify,
document, and validate assumptions as part of their planning process. For
example, if the date that a key person will become available is uncertain, the
team may assume a specific start date. Assumptions generally involvea 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 startup meetings.
.2 Stakeholder skills and
knowledge. Every stakeholder has skills and knowledge that 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
they contribute 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 PMIS consists of the tools and techniques used to
gather, integrate, and disseminate the outputs of project management processes.
It is used to support all aspects of the project from initiating through
closing, and can include both manual and automated systems.
.4 Earned value
management (EVM). A technique used to integrate the project’s scope, schedule,
and resources and to measure and report project performance from initiation to
closeout. Further discussions on EVM can be found in Section 7.4.2.3.
4.1.3 Outputs from Project Plan Development
.1 Project plan. The
project plan is a formal, approved document used to manage project execution.
The project schedule lists planned dates for performing activities and meeting
milestones identified in the project plan (see Section 6.4.3.1). The project
plan and schedule 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 will usually change
only intermittently, and then generally only in response to an approved scope
of work or deliverable 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 else where):
ٱ 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 objectives and the project deliverables.
ٱ WBS to the level at
which control will be exercised, as a baseline scope document.
ٱ Cost estimates,
scheduled start and finish dates (schedule), and responsibility assignments for
each deliverable within the WBS to the level at which control will be
exercised.
ٱ Performance
measurement baselines for technical scope, schedule, and costi.e., the schedule
baseline (project schedule) and the cost baseline (time phased project budget).
ٱ Major milestones and
target dates for each.
ٱ Key or required staff
and their expected cost and/or effort.
ٱ Risk management plan,
including: key risks, including constraints and assumptions, and planned
responses and contingencies (where appropriate) for each.
ٱ Subsidiary management
plans, namely:
_Scope management plan
(Section 5.2.3.3).
_Schedule management
plan (Section 6.4.3.3).
_Cost management plan
(Section 7.2.3.3).
_Quality management
plan (Section 8.1.3.1).
_Staffing management
plan (Section 9.1.3.2).
_Communications
management plan (Section 10.1.3.1).
_Risk response plan
(Section 11.5.3.1).
_Procurement management
plan (Section 12.1.3.1). Each of these plans could be included if needed and
with detail to the extent required for each specific project.
ٱ Open issues and
pending decisions. 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
chart.
.2 Supporting detail. Supporting
detail for the project plan includes:
ٱ Outputs from other
planning processes that are not included in the project plan.
ٱ Additional
information or documentation generated during development of the project plan
(e.g., constraints and assumptions that were not previously known).
ٱ Technical
documentation; such as, a history of all requirements, specifications,and
conceptual designs.
ٱ Documentation of
relevant standards.
ٱ Specifications from
early project development planning.
This material should be
organized as needed to facilitate its use during project plan execution.
4.2 PROJECT PLAN EXECUTION
Project plan
execution is the primary process for carrying out the project plan the vast
majority of the project’s 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. Performance against the project baseline must be continuously
monitored so that corrective actions can be taken based on actual performance
against the project plan. Periodic forecasts of the final cost and schedule
results will be made to support the analysis.
4.2.1 Inputs to Project Plan Execution
.1
Project plan. The project plan is described in Section 4.1.3.1. The subsidiary management
plans (scope management plan, risk management plan, procurement management
plan, configuration management plan, etc.) and the performance measurement
baselines are key inputs to project plan execution.
.2
Supporting detail. Supporting detail is described in Section 4.1.3.2.
.3
Organizational policies. Organizational policies are described in Section
4.1.1.3. Any and all of the organizations involved in the project may have
formal and informal policies that may affect project plan execution.
.4
Preventive action. Preventive action is anything that reduces the probability
of potential consequences of project risk events.
.5
Corrective action. Corrective action is anything done to bring expected future project
performance in line with the project plan. Corrective action is an output of
the various control processes—as an input here it completes the feedback loop needed
to ensure effective project management.
4.2.2 Tools and Techniques for Project Plan
Execution
.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 Section 2.4.
.2
Product skills and knowledge. The project team must have access to an
appropriate set of skills and knowledge about the project’s 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 PMIS is described in Section
4.1.2.3.
.6
Organizational procedures. Any and all of the organizations involved in the
project may have formal and informal procedures that are useful during project
execution.
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 results which 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 performance reporting). It
should be noted that although outcomes are frequently tangible deliverables
such as buildings, roads, etc., they are also often intangibles such as people
trained who can effectively apply that training.
.2
Change requests. Change requests (e.g., to expand or contract project scope, to
modify cost [budgets], or schedule estimates [dates, etc.]) are often
identified while the work of the project is being done.
4.3 INTEGRATED CHANGE CONTROL
Integrated
change control is concerned with a) influencing the factors that create changes
to ensure that changes are agreed upon , b) determining that a change has
occurred, and c) managing the actual changes when and as they occur. The original
defined project scope and the integrated 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. Integrated change control requires:
ٱ
Maintaining the integrity of the performance measurement baselines.
ٱ
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 4-2 . For example, a proposed schedule
change will often affect cost, risk, quality, and staffing.
4.3.1 Inputs to Integrated Change Control
.1
Project plan. The project plan provides the baseline against which changes will
be controlled (see Section 4.1.3.1).
.2
Performance reports. Performance reports (described in Section 10.3) provide information
on project performance. Performance reports may also alert theproject team to
issues that may cause problems in the future.
.3
Change requests. Change requests may occur in many forms oral or written,
director indirect, externally or internally initiated, and legally mandated or
optional.
4.3.2 Tools and Techniques for Integrated Change
Control
.1
Change control system. A change control system is a collection of formal,
documented procedures that defines how project performance will be monitored
and evaluated, and includes the steps by which official project documents may
be changed. It includes the paperwork, tracking systems, processes, 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 project.
Many
change control systems include a group responsible for approving or rejecting
proposed changes. The roles and responsibilities of these groups are clearly
defined within the change control system and agreed upon by all key stakeholders.
Organizations vary by the definition of the board; however, some common
occurrences are Configuration Control Board (CCB), Engineering Review Board
(ERB), Technical Review Board (TRB), Technical Assessment Board (TAB), and a
variety of others. The change control system must also include procedures to
handle changes that 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 the evolution of the baseline can be
documented.
.2
Configuration management. Configuration management is any documented pro- cedure
used to apply technical and administrative direction and surveillance to:
ٱ
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’s product is
correct and complete. In other application areas, change control refers to any systematic
effort to manage project change.
.3
Performance measurement. Performance measurement techniques such as EV (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,
schedules, resource requirements, analysis of risk response alternatives, or
other adjustments to the project plan.
.5
Project management information system. PMIS is described in Section 4.1.2.3. 4.3.3 Outputs from Integrated 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 4.1.3.1 and
4.1.3.2, respectively). Appropriate stakeholders must be notified as needed.
.2
Corrective action. Corrective action is described in Section 4.2.1.5.
.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
performing organization. The database is also the basis for knowledge
