QUESTIONS

1. Should Jerry go to the general manager?
2. Should the key people be supported on overhead?
3. If this were a cost-plus program, would you consider approaching the customer with your problem in hopes of relief?
4. If you were the customer of this cost-plus program, what would your response be for additional funds for the bathtub period, assuming cost overrun?
5. Would your previous answer change if the program had the money available as a result of an underrun?
6. How do you prevent this situation from recurring on all yearly follow-on contracts

__________________________________________________________________________________

4.6 PERFORM INTEGRATED CHANGE CONTROL

Perform Integrated Change Control is the process of reviewing all change requests; approving changes and managing changes to deliverables, project documents, and the project management plan; and communicating the decisions. This process reviews all requests for changes to project documents, deliverables, or the project management plan and determines the resolution of the change requests. The key benefit of this process is that it allows for documented changes within the project to be considered in an integrated manner while addressing overall project risk, which often arises from changes made without consideration of the overall project objectives or plans. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-12. Figure 4-13 depicts the data flow diagram for the process.

The Perform Integrated Change Control process is conducted from project start through completion and is the ultimate responsibility of the project manager. Change requests can impact the project scope and the product scope, as well as any project management plan component or any project document. Changes may be requested by any stakeholder involved with the project and may occur at any time throughout the project life cycle. The applied level of change control is dependent upon the application area, complexity of the specific project, contract requirements, and the context and environment in which the project is performed.

Before the baselines are established, changes are not required to be formally controlled by the Perform Integrated Change Control process. Once the project is baselined, change requests go through this process. As a general rule, each project’s configuration management plan should define which project artifacts need to be placed under configuration control. Any change in a configuration element should be formally controlled and will require a change request.

Although changes may be initiated verbally, they should be recorded in written form and entered into the change management and/or configuration management system. Change requests may require information on estimated schedule impacts and estimated cost impacts prior to approval. Whenever a change request may impact any of the project baselines, a formal integrated change control process is always required. Every documented change request needs to be either approved, deferred, or rejected by a responsible individual, usually the project sponsor or project manager. The responsible individual will be identified in the project management plan or by organizational procedures. When required, the Perform Integrated Change Control process includes a change control board (CCB), which is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project and for recording and communicating such decisions.

Approved change requests can require new or revised cost estimates, activity sequences, schedule dates, resource requirements, and/or analysis of risk response alternatives. These changes can require adjustments to the project management plan and other project documents. Customer or sponsor approval may be required for certain change requests after CCB approval, unless they are part of the CCB.

4.6.1 PERFORM INTEGRATED CHANGE CONTROL: INPUTS

4.6.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Change management plan. Described in Section 4.2.3.1. The change management plan provides the direction for managing the change control process and documents the roles and responsibilities of the change control board (CCB).
• Configuration management plan. Described in Section 4.2.3.1. The configuration management plan describes the configurable items of the project and identifies the items that will be recorded and updated so that the product of the project remains consistent and operable.
• Scope baseline. Described in Section 5.4.3.1. The scope baseline provides the project and product definition.
• Schedule baseline. Described in Section 6.5.3.1. The schedule baseline is used to assess the impact of the changes in the project schedule.
• Cost baseline. Described in Section 7.3.3.1. The cost baseline is used to assess the impact of the changes to the project cost.

4.6.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Basis of estimates. Described in Section 6.4.3.2. Basis of estimates indicate how the duration, cost, and resources estimates were derived and can be used to calculate the impact of the change in time, budget, and resources.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix helps assess the impact of the change on the project scope.
• Risk report. Described in Section 11.2.3.2. The risk report presents information on sources of overall and individual project risks involved by the change requested.

4.6.1.3 WORK PERFORMANCE REPORTS

Described in Section 4.5.3.1. Work performance reports of particular interest to the Perform Integrated Change Control process include resource availability, schedule and cost data, earned value reports, and burnup or burndown charts.

4.6.1.4 CHANGE REQUESTS

Many processes produce change requests as an output. Change requests (described in Section 4.3.3.4) may include corrective action, preventive action, defect repairs, as well as updates to formally controlled documents or deliverables to reflect modified or additional ideas or content. Changes may or may not impact the project baselines—sometimes only the performance against the baseline is affected. Decisions on those changes are usually made by the project manager.

Change requests that have an impact on the project baselines should normally include information about the cost of implementing the change, modifications in the scheduled dates, resource requirements, and risks. These changes should be approved by the CCB (if it exists) and by the customer or sponsor, unless they are part of the CCB. Only approved changes should be incorporated into a revised baseline.

4.6.1.5 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Perform Integrated Change Control process include but are not limited to:

• Legal restrictions, such as country or local regulations;
• Government or industry standards (e.g., product standards, quality standards, safety standards, and workmanship standards);
• Legal and regulatory requirements and/or constraints;
• Organizational governance framework (a structured way to provide control, direction, and coordination through people, policies, and processes to meet organizational strategic and operational goals); and
• Contracting and purchasing constraints.

4.6.1.6 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Perform Integrated Change Control process include but are not limited to:

• Change control procedures, including the steps by which organizational standards, policies, plans, procedures, or any project documents will be modified, and how any changes will be approved and validated;
• Procedures for approving and issuing change authorizations; and
• Configuration management knowledge base containing the versions and baselines of all official organizational standards, policies, procedures, and any project documents.

4.6.2 PERFORM INTEGRATED CHANGE CONTROL: TOOLS AND TECHNIQUES

4.6.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge of or training in the following topics:

• Technical knowledge of the industry and focus area of the project,
• Legislation and regulations,
• Legal and procurement,
• Configuration management, and
• Risk management.

4.6.2.2 CHANGE CONTROL TOOLS

In order to facilitate configuration and change management, manual or automated tools may be used. Configuration control is focused on the specification of both the deliverables and the processes, while change control is focused on identifying, documenting, and approving or rejecting changes to the project documents, deliverables, or baselines.

Tool selection should be based on the needs of the project stakeholders including organizational and environmental considerations and/or constraints. Tools should support the following configuration management activities:

• Identify configuration item. Identification and selection of a configuration item to provide the basis for which the product configuration is defined and verified, products and documents are labeled, changes are managed, and accountability is maintained.
• Record and report configuration item status. Information recording and reporting about each configuration item.
• Perform configuration item verification and audit. Configuration verification and configuration audits ensure that the composition of a project’s configuration items is correct and that corresponding changes are registered, assessed, approved, tracked, and correctly implemented. This ensures that the functional requirements defined in the configuration documentation are met.

Tools should support the following change management activities as well:

• Identify changes. Identifying and selecting a change item for processes or project documents.
• Document changes. Documenting the change into a proper change request.
• Decide on changes. Reviewing the changes; approving, rejecting, deferring, or making any other decision about changes to the project documents, deliverables, or baselines.
• Track changes. Verifying that the changes are registered, assessed, approved, and tracked and communicating final results to stakeholders.

Tools are also used to manage the change requests and the resulting decisions. Additional considerations should be made for communications to assist the change control board (CCB) members in their duties, as well as to distribute the decisions to the appropriate stakeholders.

4.6.2.3 DATA ANALYSIS

Data analysis techniques that can be used for this process include but are not limited to:

• Alternatives analysis. Described in Section 9.2.2.5. This technique is used to assess the requested changes and decide which are accepted, rejected, or need to be modified to be finally accepted.
• Cost-benefit analysis. Described in Section 8.1.2.3. This analysis helps to determine if the requested change is worth its associated cost.

4.6.2.4 DECISION MAKING

Decision-making techniques that can be used for this process include but are not limited to:

• Voting. Described in Section 5.2.2.4. Voting can take the form of unanimity, majority, or plurality to decide on whether to accept, defer, or reject change requests.
• Autocratic decision making. In this decision-making technique, one individual takes the responsibility for making the decision for the entire group.
• Multicriteria decision analysis. Described in Section 8.1.2.4. This technique uses a decision matrix to provide a systematic analytical approach to evaluate the requested changes according to a set of predefined criteria.

4.6.2.5 MEETINGS

Change control meetings are held with a change control board (CCB) that is responsible for meeting and reviewing the change requests and approving, rejecting, or deferring change requests. Most changes will have some sort of impact on time, cost, resources, or risks. Assessing the impact of the changes is an essential part of the meeting. Alternatives to the requested changes may also be discussed and proposed. Finally, the decision is communicated to the request owner or group.

The CCB may also review configuration management activities. The roles and responsibilities of these boards are clearly defined and agreed upon by the appropriate stakeholders and are documented in the change management plan. CCB decisions are documented and communicated to the stakeholders for information and follow-up actions.

4.6.3 PERFORM INTEGRATED CHANGE CONTROL: OUTPUTS

4.6.3.1 APPROVED CHANGE REQUESTS

Change requests (described in Section 4.3.3.4) are processed according to the change management plan by the project manager, CCB, or an assigned team member. As a result, changes may be approved, deferred, or rejected. Approved change requests will be implemented through the Direct and Manage Project Work process. Deferred or rejected change requests are communicated to the person or group requesting the change.

The disposition of all change requests are recorded in the change log as a project document update.

4.6.3.2 PROJECT MANAGEMENT PLAN UPDATES

Any formally controlled component of the project management plan may be changed as a result of this process. Changes to baselines are only made from the last baseline forward. Past performance is not changed. This protects the integrity of the baselines and the historical data of past performance.

4.6.3.3 PROJECT DOCUMENTS UPDATES

Any formally controlled project document may be changed as a result of this process. A project document that is normally updated as a result of this process is the change log. The change log is used to document changes that occur during a project.