THE PROJECT MANAGEMENT KNOWLEDGE AREAS
12. Project Procurement Management
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 dis- cussed 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.
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
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 the project team to issues that may cause problems in the future.
.3 Change requests. Change requests may occur in many forms—oral or written, direct or 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, docu- mented 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.
.1.2 .3
Project plan Performance reports Change requests
.1.2 .3.4 .5
Change control system Configuration management Performance measurement Additional planning Project management information system
.1.2 .3
Project plan updates Corrective action Lessons learned
Inputs Tools & Techniques Outputs
Figure 4–2. Coordinating Changes Across the Entire Project
Subsidiary Change Control
• Scope Change Control
• Schedule Change Control
• Cost Change Control
• Quality Control
• Risk Change Control
• Contract Administration 4.3 Integrated Change Control 10.3
Performance Reporting
Communications Integration
4.3.1|4.3.3.3
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
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 pro- cedures 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 proj- ects of the performing organization. The database is also the basis for knowledge management.
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
Project Scope Management
Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully (1). It is primarily concerned with defining and control- ling what is or is not included in the project. Figure 5-1provides an overview of the major project scope management processes:
5.1 Initiation—authorizing the project or phase.
5.2 Scope Planning—developing a written scope statement as the basis for future project decisions.
5.3 Scope Definition—subdividing the major project deliverables into smaller, more manageable components.
5.4 Scope Verification—formalizing acceptance of the project scope.
5.5 Scope Change Control—controlling changes to project scope.
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 components 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.
In the project context, the term scopemay refer to:
■ Product scope—the features and functions that characterize a product or service.
■ Project scope—the work that must be done to deliver a product with the spec- ified features and functions.
The processes, tools, and techniques used to manage projectscope are the focus of this chapter. The processes, tools, and techniques used to manage product scope vary by application area and are usually defined as part of the project life cycle (the project life cycle is discussed in Section 2.1).
A project generally results in a single product, but that product may include subsidiary components, each with its own separate but interdependent product scopes. For example, a new telephone system would generally include four sub- sidiary components—hardware, software, training, and implementation.
Completion of the project scope is measured against the project plan, but com- pletion of the product scope is measured against the product requirements. Both types of scope management must be well integrated to ensure that the work of the project will result in delivery of the specified product.
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
A Guide to the
Project
Management Body of
Knowledge
SAMPLE
Figure 5–1. Project Scope Management Overview
PROJECT SCOPE MANAGEMENT
5.2 Scope Planning 5.3 Scope Definition 5.1
.1 Inputs
.2 Tools and Techniques
.3 Outputs
.1 Product description .2 Strategic plan
.3 Project selection criteria .4 Historical information .1 Project selection
methods .2 Expert judgment .1 Project charter .2 Project manager
identified/assigned .3 Constraints .4 Assumptions
.1 Inputs
.2 Tools and Techniques
.3 Outputs
.1 Product description .2 Project charter .3 Constraints .4 Assumptions .1 Product analysis .2 Benefit/cost analysis .3 Alternatives identification .4 Expert judgment .1 Scope statement .2 Supporting detail .3 Scope management plan
.1 Inputs
.2 Tools and Techniques
.3 Outputs
.1 Scope statement .2 Constraints .3 Assumptions
.4 Other planning outputs .5 Historical information .1 Work breakdown
structure templates .2 Decomposition .1 Work breakdown
structure .2 Scope statement
updates Initiation
5.5 Scope Change Control 5.4
.1 Inputs
.2 Tools and Techniques .3 Outputs
.1 Work results
.2 Product documentation .3 Work breakdown
structure .4 Scope statement .5 Project plan .1 Inspection .1 Formal acceptance
.1 Inputs
.2 Tools and Techniques
.3 Outputs
.1 Work breakdown structure
.2 Performance reports .3 Change requests .4 Scope management plan .1 Scope change control
system .2 Performance
measurement .3 Additional planning .1 Scope changes .2 Corrective action .3 Lessons learned .4 Adjusted baseline Scope Verification
|Figure 5–1|5.1.1.1