HKSM

A change request is a formal proposal to modify a deliverable, process, agreement, or baseline. It is analyzed to understand impacts and feasibility, then routed for a decision such as approve, defer, or reject.

Key Points

• Change requests can be corrective, preventive, defect repairs, or enhancements and may come from any stakeholder.
• Analysis evaluates impacts across scope, schedule, cost, quality, resources, risks, value, and compliance.
• The level of rigor scales with governance and delivery approach; agile teams often handle small changes via backlog refinement.
• Each request is uniquely logged and traceable to requirements and baselines using a change log.
• Decision outcomes typically include approve (with conditions), defer, or reject, and must be communicated promptly.
• Only approved changes lead to updates of baselines, plans, and product backlog items.
• Urgent changes may use an expedited path, followed by formal review and documentation.

Purpose of Analysis

• Provide objective decision support by clarifying benefits, risks, and trade-offs.
• Protect baselines and commitments by quantifying impacts before implementation.
• Ensure alignment with strategy, product vision, and stakeholder expectations.
• Maintain transparency and traceability for governance, contracts, and audits.

Method Steps

• Capture and log the request with a unique ID, source, and clear description of the need and desired outcome.
• Triage urgency, category (corrective, preventive, defect repair, enhancement), and completeness of information.
• Gather references: affected requirements, scope statements, schedules, budgets, quality criteria, and constraints.
• Analyze impacts on scope, schedule, cost, quality, resources, risks, value, compliance, and contracts; note assumptions.
• Identify alternatives (including do nothing), estimate effort and cost ranges, and assess feasibility.
• Consult subject matter experts and key stakeholders to validate impacts and dependencies.
• Recommend a disposition (approve, defer, reject) and any conditions or mitigation actions.
• Route the request for decision per governance (e.g., product owner or change control board) and record the outcome.
• Communicate the decision; for approved changes, update relevant plans/baselines or backlog and implement, verify, and close.

Inputs Needed

• Completed change request description or form, including rationale and acceptance criteria.
• Current scope, schedule, and cost baselines; product backlog or requirements documentation.
• Risk register, assumptions log, dependency map, and resource availability data.
• Quality standards, compliance requirements, and definition of done/acceptance criteria.
• Contracts, service-level agreements, and governance policies.
• Recent performance data (progress reports, velocity, burn charts, earned value, defects).

Outputs Produced

• Impact analysis summary with quantified effects, assumptions, and alternatives.
• Disposition recommendation and decision record (approve, defer, reject) with conditions.
• Updated change log with status, ownership, and traceability links.
• Updates to plans, baselines, backlog items, or contracts for approved changes.
• Stakeholder communications and updated risk/issue registers as applicable.
• Implementation and verification evidence for approved changes.

Interpretation Tips

• Treat the analysis as decision support, not advocacy; present balanced options and trade-offs.
• Right-size the effort: keep lightweight for minor backlog tweaks and rigorous for baseline-impacting changes.
• Quantify where possible (cost, time, value, risk probability/impact); avoid vague language.
• Maintain traceability from the request to affected requirements, tests, and baselines.
• Watch cumulative effects of multiple small changes; re-forecast when thresholds are crossed.
• Align the path to decision with the delivery approach and governance (PO authority vs. CCB).

Example

A sponsor requests adding a new regulatory field to a delivered form. The team logs the request, maps the requirement, and analyzes impacts: one week of development, test updates, user training, and minor schedule slip. Alternatives include delaying to the next release or bundling with related changes. The change control authority approves it for the next iteration, the backlog and test cases are updated, and the decision is communicated to stakeholders.

Pitfalls

• Bypassing governance and implementing changes without documented analysis.
• Vague problem statements that describe solutions instead of outcomes.
• Approving changes without considering cost, schedule, quality, and risk trade-offs.
• Ignoring dependencies and downstream testing, training, or compliance impacts.
• Overanalyzing trivial changes or underanalyzing major baseline impacts.
• Failing to update the change log, baselines, or backlog after decisions.
• Poor communication of decisions leading to misalignment and rework.

PMP Example Question

Mid-project, a senior stakeholder asks to add a new feature. What should the project manager do first?

1. Update the scope and schedule baselines to reflect the stakeholder request.
2. Implement the change quickly to maintain stakeholder satisfaction.
3. Log the request and analyze its impacts before routing it for a decision.
4. Ask the team to start estimating hours while the manager informs the sponsor.

Correct Answer: C — Log the request and analyze its impacts before routing it for a decision.

Explanation: The proper first step is to document and assess the change to understand impacts and options, then follow the defined change control path. Baselines are only updated after an approved decision.