ExamFinch.com My Study

Study guide

6.3 Predictive Project Controls and Artifacts

Practice this exam

CAPM Certified Associate in Project Management Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & CAPM Exam Overview

1.1 About the CAPM Exam 1.2 PMBOK 7th Edition Overview 1.3 Exam Content Outline (ECO) 1.4 CAPM vs. PMP: Understanding the Differences

2 Chapter 2: Project Life Cycles and Processes (Domain 1, Tasks 1-2)

2.1 Projects, Programs, and Portfolios 2.2 Project Life Cycle Phases 2.3 The Five Process Groups 2.4 The Ten Knowledge Areas

3 Chapter 3: Project Management Planning (Domain 1, Task 2)

3.1 The Project Management Plan 3.2 Scope Management and the WBS 3.3 Schedule Management 3.4 Cost Management and Earned Value 3.5 Quality Management

4 Chapter 4: Project Roles, Responsibilities, and Ethics (Domain 1, Tasks 3-4)

4.1 Project Roles and Responsibilities 4.2 Leadership and Emotional Intelligence 4.3 Risk Management Fundamentals 4.4 PMI Code of Ethics and Professional Conduct 4.5 Problem-Solving Tools and Techniques

5 Chapter 5: Resource, Communication, and Stakeholder Management (Domain 1, Tasks 2-3)

5.1 Resource Management 5.2 Communications Management 5.3 Stakeholder Management 5.4 Procurement Management 5.5 Issues, Risks, Assumptions, and Constraints

6 Chapter 6: Predictive, Plan-Based Methodologies (Domain 2)

6.1 When to Use a Predictive Approach 6.2 WBS, Work Packages, and Activity Definition 6.3 Predictive Project Controls and Artifacts 6.4 Critical Path and Schedule Calculations

7 Chapter 7: Agile Frameworks and Methodologies (Domain 3, Tasks 1-3)

7.1 When to Use an Adaptive (Agile) Approach 7.2 The Scrum Framework 7.3 Kanban, XP, and SAFe 7.4 Agile Planning, Estimation, and Metrics 7.5 Agile Project Controls and Artifacts

8 Chapter 8: Business Analysis Roles and Stakeholder Communication (Domain 4, Tasks 1-2)

8.1 Business Analysis Roles and Responsibilities 8.2 Stakeholder Communication in Business Analysis 8.3 Business Case and Needs Assessment

9 Chapter 9: Requirements Gathering and Product Roadmaps (Domain 4, Tasks 3-4)

9.1 Requirements Gathering Approaches 9.2 Requirements Traceability Matrix 9.3 Product Roadmaps

10 Chapter 10: BA Methodologies and Requirements Validation (Domain 4, Tasks 5-6)

10.1 Business Analysis in Predictive and Agile Approaches 10.2 Acceptance Criteria and Requirements Validation 10.3 Business Analysis Tools and Techniques Summary

6.3 Predictive Project Controls and Artifacts

Key Takeaways Explain This Topic AI

Perform Integrated Change Control evaluates every change request and ensures only approved changes modify the project baselines

The Change Control Board (CCB) is a formally constituted group that approves, rejects, defers, or requests more information on changes

Configuration management keeps the product's functional and physical descriptions correct via identification, status accounting, and verification/audit

Work performance data becomes information, then reports — raw observations are analyzed in context, then formatted for stakeholders

Corrective action realigns future work to the plan; preventive action reduces a future risk; defect repair fixes a non-conforming deliverable

Last updated: June 2026

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
  • Submit — anyone may raise a change request, but it must be documented in writing
  • Log — record it in the change log with a unique ID and status
  • Analyze impact — assess effects on scope, schedule, cost, quality, risk, and resources
  • Review — the Change Control Board evaluates the request
  • Decide — approve, reject, defer, or request more information
  • Implement — if approved, update the project management plan and baselines
  • 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.

  • Aspect Details
  • Members Sponsor, PM, key stakeholders, subject-matter experts
  • Authority May approve, reject, or defer changes
  • When active Once baselines are established
  • Record Maintains a change log of every request and decision

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

  • Type What it does
  • Corrective action Realigns future performance with the project management plan
  • Preventive action Reduces the probability or impact of a potential future variance
  • Defect repair Modifies a non-conforming deliverable to meet requirements
  • Update A change to a formally controlled document, plan, or baseline

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.

  • Activity Purpose
  • Configuration identification Identify and document items and their characteristics
  • Configuration status accounting Track the status of items and approved changes
  • Configuration verification and audit Confirm items conform to requirements

Key Predictive Artifacts

  • Artifact Purpose Mostly created during
  • Project charter Formally authorizes the project; names the PM Initiating
  • Project management plan Integrated guide for execution; holds the baselines Planning
  • Work performance data Raw observations during execution Executing
  • Work performance information Analyzed data placed in context Monitoring & Controlling
  • Work performance reports Compiled, formatted output for decisions Monitoring & Controlling
  • Change log Records all change requests and status Throughout
  • Issue log Tracks issues and their resolution Throughout
  • Lessons learned register Captures what worked and what did not Throughout
  • Final report Summarizes overall performance at handover Closing
  • 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)
  • Level Example
  • Data 47 of 60 activities complete; $450,000 spent
  • Information SPI = 0.92 (behind schedule); CPI = 1.05 (under budget)
  • Report Status report with a schedule-recovery plan and cost forecast
  • Variance and Trend Analysis

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

  • Variance Formula Meaning
  • Schedule variance SV = EV - PV Ahead (+) or behind (-) schedule, in cost terms
  • Cost variance CV = EV - AC Under (+) or over (-) budget

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.

  • Baseline What it fixes Source artifact
  • Scope baseline What will be delivered Scope statement + WBS + WBS dictionary
  • Schedule baseline When work finishes Approved project schedule
  • Cost baseline How much it will cost over time Time-phased budget (the S-curve)

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.