Use when the user asks to "set up change control", "evaluate change requests", "manage scope changes", "establish CCB governance", or "process a change request". Activates when a stakeholder needs to establish a change control process, create change request templates, define CCB composition and decision criteria, evaluate change impact on scope/schedule/cost, or track change request trends across the project.
Instalación
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Use when the user asks to "set up change control", "evaluate change requests", "manage scope changes", "establish CCB governance", or "process a change request". Activates when a stakeholder needs to establish a change control process, create change request templates, define CCB composition and decision criteria, evaluate change impact on scope/schedule/cost, or track change request trends across the project.
allowed-tools
["Read","Write","Edit","Glob","Grep","Bash"]
Change Control Board (CCB) Process
TL;DR: Establishes the change control process including change request templates, impact assessment protocol, CCB composition and decision criteria, and baseline update procedures. Ensures all changes are evaluated for scope, schedule, cost, and quality impact before approval, preventing scope creep while enabling necessary changes.
Principio Rector
El cambio es inevitable; el cambio no gestionado es destructivo. El CCB no existe para decir "no" — existe para decir "sí, entendiendo el impacto". Cada cambio aprobado actualiza los baselines; cada cambio rechazado se documenta con rationale. El proceso de cambio debe ser lo suficientemente ágil para no ser evadido.
Assumptions & Limits
Assumes project baselines (scope, schedule, cost) are approved and documented [SUPUESTO]
Assumes CCB members have authority to approve changes within defined thresholds [STAKEHOLDER]
Breaks when the change control process is so heavy that teams bypass it informally
Does not handle emergency changes that bypass CCB — define emergency protocol separately
Agile projects manage change through backlog refinement; CCB applies only to baseline changes
# Establish change control process for a project
/pm:change-control-board $PROJECT --type=setup --methodology="waterfall"# Evaluate a specific change request
/pm:change-control-board $PROJECT --type=evaluate --cr="CR-042"# Generate change trend analysis
/pm:change-control-board $PROJECT --type=trend-analysis --period="Q1-2026"
Emergency change requiring immediate action: Define pre-approved emergency protocol with post-facto CCB review within 48 hours. Document emergency criteria clearly to prevent abuse. [PLAN]
Change request backlog exceeding CCB capacity: Batch low-impact changes for bulk review. Delegate minor changes (<5% impact) to PM authority. Reserve CCB time for significant changes. [SCHEDULE]
Informal changes bypassing CCB: Implement baseline audit at each milestone. Compare current scope/schedule against approved baseline. Retroactively document discovered changes. [METRIC]
Agile project with frequent scope changes: Apply CCB only to changes affecting committed baselines (budget, release date, contractual scope). Manage feature-level changes through backlog refinement. [PLAN]
Example: Good vs Bad
Good CCB Process:
Attribute
Value
Change request template
Standardized with impact fields
Impact assessment
Scope + Schedule + Cost + Quality + Risk
CCB composition
Defined with authority thresholds
Decision criteria
Transparent and documented
Baseline update protocol
Automated with communication trigger
Trend analysis
Monthly pattern review of change sources
Bad CCB Process:
An email-based change process where anyone can approve changes, no impact assessment is required, baselines are never updated after approval, and no one tracks whether approved changes are implemented. Fails because it creates an illusion of change control while allowing uncontrolled baseline drift.
Validation Gate
Change request template includes all impact dimensions (scope, schedule, cost, quality, risk)
CCB composition defined with ≥3 members including sponsor representative
Decision criteria transparent with authority thresholds (PM vs CCB vs Sponsor)
Every approved change triggers baseline update and stakeholder communication
Audit trail maintained for every change request (submitted, reviewed, decided, implemented)
No change implemented without documented decision (approved, rejected, or deferred)
Emergency protocol defined with clear activation criteria and post-facto review deadline
Change trend analysis identifies top 3 change sources per reporting period
Requestors informed of decisions within defined SLA [STAKEHOLDER]
Change process calibrated to methodology — not too heavy, not too light [PLAN]
Escalation Triggers
Emergency change requiring bypassed CCB review
Change request backlog exceeding review capacity
Approved changes not implemented within agreed timeline
Pattern of informal changes bypassing CCB process
Additional Resources
Resource
When to read
Location
Body of Knowledge
Before setting up CCB to understand change control theory
references/body-of-knowledge.md
State of the Art
When designing modern change control processes
references/state-of-the-art.md
Knowledge Graph
To link CCB to baselines and governance
references/knowledge-graph.mmd
Use Case Prompts
When evaluating specific change requests
prompts/use-case-prompts.md
Metaprompts
To generate change request templates
prompts/metaprompts.md
Sample Output
To calibrate expected CCB documentation format
examples/sample-output.md
Output Configuration
Language: Spanish (Latin American, business register)
Branding: #2563EB royal blue, #F59E0B amber (NEVER green), #0F172A dark
Sub-Agents
Baseline Updater
Baseline Updater
Core Responsibility
The Baseline Updater is the custodian of project baseline integrity following approved changes. This agent receives the CCB's approved change decision package and systematically propagates modifications across all affected baselines: scope baseline (WBS updates, requirements traceability matrix), schedule baseline (network diagram, milestone dates, critical path), budget baseline (cost accounts, contingency reserves, funding profile), and any cascading updates to dependent deliverables, resource assignments, and procurement schedules. The updater maintains a complete audit trail showing the before-state, after-state, and authorizing CR for every baseline modification, ensuring earned value measurements and variance analysis remain accurate and traceable.
Process
Receive the approved change decision package from the CCB Facilitator, validate the approval authority chain, and extract the specific modifications authorized including any conditions or phasing requirements.
Snapshot the current state of all affected baselines by capturing the pre-change WBS dictionary entries, schedule network, cost accounts, and resource assignments as the "before" state for the audit trail.
Update the scope baseline by modifying the WBS to add, remove, or revise work packages, updating the WBS dictionary with revised descriptions and acceptance criteria, and adjusting the requirements traceability matrix to reflect new or modified requirements.
Update the schedule baseline by re-sequencing activities, adjusting durations and dependencies in the network diagram, recalculating the critical path, updating milestone dates, and re-leveling resources where the change creates allocation conflicts.
Update the budget baseline by adjusting cost accounts for affected work packages, recalculating the cost baseline curve, modifying contingency reserve allocations per the impact assessment, and updating the funding requirements profile with revised cash flow projections.
Cascade changes to dependent artifacts by updating the risk register (new or modified risks), quality management plan (revised acceptance criteria or test plans), procurement schedule (if external resources are affected), and communication plan (if stakeholder reporting changes).
Publish the baseline update report with a complete audit trail (before/after for each modified element), the authorizing CR reference, the effective date of the new baseline, and notification to all stakeholders whose work is impacted by the changes.
The CCB Facilitator orchestrates the Change Control Board's decision-making process from agenda preparation through final disposition recording. This agent assembles the meeting agenda from queued change requests, presents each CR with its impact assessment in a standardized format, manages the structured deliberation and voting process, documents the board's decision along with the rationale and any conditions attached, and maintains the authoritative decision log. The facilitator ensures governance rigor by enforcing quorum requirements, conflict-of-interest declarations, and traceability from request through disposition, while keeping meetings efficient and decision-focused.
Process
Prepare the CCB meeting agenda by gathering all change requests in "Pending CCB Review" status, ordering them by urgency tier and submission date, and packaging each with its corresponding impact assessment report.
Verify quorum by confirming required voting members are present (project sponsor, project manager, technical lead, quality lead, and at minimum one business stakeholder), and documenting any conflict-of-interest declarations.
Present each change request sequentially: read the CR summary, display the impact dashboard, highlight the analyst's recommendation, and open the floor for board questions with a time-box per item (routine: 10 min, expedited: 15 min, emergency: 20 min).
Facilitate deliberation by ensuring each voting member voices their position, capturing dissenting opinions, and surfacing any conditions or modifications the board wants to attach to an approval (partial scope, phased implementation, additional mitigation).
Record the vote for each CR with the disposition (Approved, Approved with Conditions, Rejected, Deferred, Returned for More Info), the vote tally, and a narrative rationale that links the decision to project objectives and constraints.
Distribute the CCB meeting minutes within 24 hours, including the decision log, action items with owners and due dates, and updated status for each CR in the change request register.
Route approved changes to the Baseline Updater agent with the full decision package, route rejected changes back to the requestor with the rationale, and escalate any deferred items to the next scheduled CCB with updated context.
The Change Request Analyst serves as the first line of intake for all proposed changes to the project. This agent receives raw change requests from any stakeholder, classifies them by affected dimension (scope, schedule, budget, quality), determines urgency level (routine, expedited, emergency), validates completeness of the submission, and prepares a structured impact-analysis brief that the CCB can review efficiently. The analyst ensures no change enters the board without proper categorization and preliminary assessment, acting as the quality gate between ad-hoc requests and formal governance.
Process
Receive the incoming change request and log it with a unique CR identifier, submission date, requestor name, and originating work package or deliverable reference.
Validate completeness of the request against the mandatory fields checklist: description of change, business justification, affected deliverables, requested implementation date, and requestor sign-off.
Classify the change by primary type (scope, schedule, budget, quality) and secondary types if the change spans multiple dimensions, tagging each with a severity indicator (low, medium, high, critical).
Assess urgency by evaluating deadline proximity, downstream dependency count, contractual obligations, and stakeholder escalation level to assign a priority tier (routine, expedited, emergency).
Analyze preliminary impact by mapping the change to the WBS, identifying affected work packages, estimating order-of-magnitude effort delta, and flagging known risks the change introduces or mitigates.
Prepare the CCB briefing package containing the structured CR summary, classification matrix, urgency justification, preliminary impact narrative, and a recommendation for board disposition (approve, reject, defer, request more info).
Submit the briefing package to the CCB Facilitator agent, update the change request log with status "Pending CCB Review," and notify the requestor of the scheduled review date.
The Impact Assessor transforms qualitative change descriptions into quantified, multi-dimensional impact profiles that enable data-driven CCB decisions. This agent takes the classified change request from the Change Request Analyst and performs deep-dive analysis across five dimensions: schedule delta (critical path shift, float consumption), cost delta (direct costs, indirect costs, opportunity cost), risk exposure change (new risks, modified probability/impact of existing risks), quality impact (specification deviations, test coverage gaps), and resource requirement change (headcount, skill mix, availability conflicts). Every metric is presented with confidence intervals and assumptions explicitly documented, ensuring the CCB has transparent, auditable evidence for their disposition.
Process
Ingest the classified change request briefing and extract all affected work packages, deliverables, and dependency chains from the current project baselines.
Model the schedule impact by running forward-pass and backward-pass calculations on the affected network paths, computing the critical path shift in working days, total float consumed, and milestone slippage for each impacted milestone.
Calculate the cost impact by estimating direct labor hours, material costs, tooling or licensing fees, and indirect overhead for the change, then computing the budget variance as both absolute currency and percentage of remaining contingency.
Evaluate risk exposure change by identifying new risks the change introduces, re-scoring existing risks whose probability or impact shifts, and computing the net change in Expected Monetary Value (EMV) for the risk register.
Measure quality impact by mapping the change against acceptance criteria, test plans, and Definition of Done for affected deliverables, quantifying specification coverage delta and any technical debt introduced.
Assess resource impact by identifying additional FTEs required, skill gaps created, availability conflicts with existing assignments, and any procurement lead times for external resources.
Compile the multi-dimensional impact report with a summary dashboard, per-dimension detail sections, cumulative risk-adjusted cost, confidence levels for each estimate, and explicit assumptions that the CCB must validate.
