PMI-CP™ Cheatsheet — Contracts, Claims, Interfaces, Change & Governance

Use this as your last-mile PMI-CP™ review. Pair it with the Syllabus for coverage and Practice for speed.

For official exam policy details, see Overview.

Construction delivery in one picture (commercial + coordination)

    flowchart TD
	  A["Define outcomes + scope boundaries"] --> B["Choose delivery + contract structure"]
	  B --> C["Plan interfaces + risk process"]
	  C --> D["Execute with disciplined documentation"]
	  D --> E["Manage change orders + claims early"]
	  E --> F["Govern decisions + close contracts cleanly"]
	  F --> C

Best-answer pattern: reduce downstream pain by making work decision-ready (clear boundaries, owners, thresholds, documentation).

Contract models (what to recognize)

Exam-useful lens: contract structure is an incentive system. Ask: who owns what risk, and how are decisions made?

Contract clause “red flags” to watch for

• Change clause + notice requirements: late notice can destroy entitlement.
• Scope definition + exclusions: vague scope → disputes.
• Payment terms: retainage, milestones, pay-if-paid, certification.
• Schedule + LDs: delay responsibility, concurrency, mitigation duties.
• Differing site conditions: who carries subsurface risk and how it’s proven.
• Dispute resolution: escalation ladders, DRB, mediation/arbitration requirements.

Claims vs change orders (don’t mix them)

Claims lifecycle (early resolution beats perfect paperwork)

    flowchart LR
	  A["Early warning signal"] --> B["Contract notice + documentation"]
	  B --> C["Analyze cause + entitlement"]
	  C --> D["Quantify time/cost impact"]
	  D --> E["Negotiate / resolve early"]
	  E --> F["Formal dispute path (if needed)"]

Good actions early: clarify facts, preserve records, separate “change” from “claim”, and propose resolution options.

Interface management (mega-project muscle)

Interface register should answer:

• What is the boundary?
• Who owns it?
• What is the deliverable and acceptance evidence?
• When is it needed (dependency date)?
• What are the risks if it slips?

Common interface failure modes

• “Everyone thought the other party had it.”
• Assumptions not written down (dimensions, tolerances, data formats).
• Late design changes ripple across packages without impact analysis.
• Weak governance: no single place to resolve conflicts.

Risk tooling (what it’s for)

• Risk register: ownership + actions + tracking; avoid “pretty lists”.
• Probabilistic analysis (concept): use when uncertainty drives decisions (buffers, contingency, strategy choices).
• Interpretation: outputs only matter if they change decisions (thresholds, trade-offs, options).

Communication patterns that prevent rework

• Single source of truth: document control + clear “current” artifacts.
• Decision log: what was decided, by whom, why, and what changed.
• Big room / Obeya (when used well): visual metrics + fast decisions + clear actions.
• Feedback loops: surface communication gaps before they become claims.

Change orders (scope → impact → decision)

When a change request appears, answer these in order:

1. Is it a real scope change under the contract?
2. What is the impact (cost, schedule, interfaces, risk, safety, permits, operations)?
3. Who must approve (thresholds + decision rights)?
4. What must be updated (baselines, drawings/specs, logs, register)?

Governance (what “good” looks like)

• Clear decision rights and escalation paths
• Defined thresholds (who approves what changes)
• Cadence that matches project volatility
• Metrics that connect to decisions, not vanity reporting
• Audit-ready documentation (especially around changes and claims)