6.3 Predictive Project Controls and Artifacts

Integrated Change Control

In predictive work, the baselines (scope, schedule, cost) are set early, so the discipline that protects them is Perform Integrated Change Control — the process of reviewing all change requests, approving or rejecting changes, and managing changes to deliverables, project documents, and the project management plan. The defining rule: no change to a baseline is made without an approved change request.

The change control workflow

1. Submit — anyone may raise a change request, but it must be documented in writing
2. Log — record it in the change log with a unique ID and status
3. Analyze impact — assess effects on scope, schedule, cost, quality, risk, and resources
4. Review — the Change Control Board evaluates the request
5. Decide — approve, reject, defer, or request more information
6. Implement — if approved, update the project management plan and baselines
7. Communicate — notify stakeholders of the decision and its impacts

Common trap: A stakeholder verbally asks the PM to "just add one small feature." The exam-correct first action is not to implement it and not to refuse outright — it is to have a change request submitted and run through integrated change control. Acting on a verbal request bypasses control and is wrong.

The Change Control Board (CCB)

The Change Control Board (CCB) is a formally constituted group responsible for reviewing change requests and deciding their fate.

The PM may hold delegated authority for minor changes, but significant changes — especially anything touching a baseline — go to the CCB.

Types of change requests

Memorize the difference: corrective action responds to an existing variance; preventive action heads off a risk that has not yet caused a variance; defect repair fixes something already built wrong.

Configuration Management

Configuration management ensures the descriptions and the functional and physical characteristics of the project's product, service, or result are correct and complete. It answers "is this the right, current version of the deliverable and its documentation?" — distinct from change control, which governs whether a change is approved.

Key Predictive Artifacts

Data -> Information -> Reports

Work Performance DATA (raw observations)
  -> analyzed and given context
Work Performance INFORMATION (e.g., SPI, CPI)
  -> compiled and formatted
Work Performance REPORTS (status reports, dashboards)

Variance and Trend Analysis

In predictive projects, variance from the baseline is the primary control signal:

Trend analysis examines results over time to forecast future performance, spot patterns needing corrective action, and support Estimate at Completion (EAC) forecasts. A negative-and-worsening CV trend, for example, signals that a corrective action — routed through change control — is warranted.

Baselines: The Yardsticks Being Protected

Everything in predictive control exists to protect three baselines, the approved versions against which actual performance is measured.

Together these are the performance measurement baseline. A change request that is approved updates the relevant baseline; an approved change is the only legitimate way a baseline changes. This is why the exam treats "update the baseline before getting approval" as always wrong.

Logs and Registers You Must Distinguish

The exam frequently tests which log holds what, so keep them straight:

• Change log — every change request and its disposition (approved/rejected/deferred)
• Issue log — current problems that need resolution, with an owner and target date
• Risk register — potential future events (an issue is a risk that has occurred)
• Assumption log — assumptions and constraints, started in Initiating
• Lessons learned register — what worked and what did not, fed into the final report at closing

Common trap: An "issue" is something happening now; a "risk" is something that might happen. If a risk materializes, it moves from the risk register to the issue log.