HKSM

A structured practice to evaluate requested changes, decide with the right authority, and implement approved changes in a controlled way by updating plans, baselines, product components, and records.

Purpose & When to Use

• Provide a consistent, transparent way to evaluate proposed changes and decide whether to proceed.
• Protect scope, schedule, cost, quality, and product integrity while enabling improvements and compliance.
• Use whenever a request may affect baselines, value, risks, resources, contracts, or regulatory obligations.
• Apply in all delivery approaches: predictive uses formal control boards, hybrid uses tiered authority, and adaptive uses backlog refinement and timeboxed planning.
• Use fast-track paths for urgent or safety-critical changes, followed by post-implementation review and documentation.

Mini Flow (How It’s Done)

• Capture the request: describe the need, benefits, urgency, and acceptance criteria; assign an owner; log it in the change log or backlog.
• Triage the type: defect repair, corrective action, preventive action, or enhancement; confirm required supporting information.
• Analyze impacts: assess scope, schedule, cost, quality, value, risks, resources, dependencies, technical feasibility, and compliance; outline options with estimates.
• Engage stakeholders: consult the team, product owner or sponsor, SMEs, vendors, and affected users to validate assumptions and constraints.
• Decide with the right authority: product owner, sponsor, project manager within limits, or change control board; document approve, defer, or reject with rationale.
• Plan implementation: define tasks, owner, timing, testing, acceptance, communications, training, and rollback; update the backlog or work plan.
• Update baselines and documents: revise scope, schedule, and cost baselines as needed; update configuration items, requirements, risks, and contracts.
• Communicate the decision: inform stakeholders, synchronize with vendors, and set expectations on delivery and impacts.
• Implement and validate: execute the change, perform testing and integration, verify acceptance criteria, and release as planned.
• Close and learn: update the change log, configuration records, lessons learned, and performance metrics; monitor realized benefits and residual risks.
• Adaptive note: the product owner reorders the backlog; the team estimates and schedules the item into an upcoming iteration unless it is a critical fix that meets defined entry rules.

Quality & Acceptance Checklist

• The change request is clearly stated with business reason, expected value, and acceptance criteria.
• Impact analysis covers scope, schedule, cost, quality, value, risks, resources, dependencies, and compliance.
• Alternatives, including do-nothing and minimal viable change, are considered with rough estimates.
• Decision authority and approval path are correct for the change size and risk.
• Decision and rationale are recorded in the change log or backlog tool.
• Baselines and relevant documents are updated when required and version-controlled.
• Implementation plan includes owner, timeline, testing, integration, communication, training, and rollback.
• Stakeholders are informed of impacts and timing; vendor or contract updates are addressed.
• Risks and issues are updated, including triggers and contingency plans.
• Post-implementation validation confirms acceptance criteria and no unintended side effects.
• Lessons learned and configuration records are updated for traceability.

Common Mistakes & Exam Traps

• Implementing changes without proper approval or outside delegated limits.
• Skipping impact analysis before seeking a decision or escalating prematurely.
• Updating the schedule but not cost, scope, risks, or contracts, leading to misalignment.
• Assuming every change needs a formal board in agile settings; backlog prioritization by the product owner is a valid control mechanism.
• Changing in-flight iteration scope without defined urgent-change rules and team agreement.
• Confusing change control with configuration control; both are needed to manage versions and traceability.
• Ignoring non-functional requirements, regulatory impacts, or data and security implications.
• Lack of rollback or recovery plan for higher-risk changes.
• Not documenting emergency changes and skipping post-implementation review.
• Equating defect fixes with scope changes; repairs may still require analysis and coordination.

PMP Example Question

A stakeholder submits a change that improves compliance but may extend delivery by two weeks. What should the project manager do first?

1. Implement the change immediately to avoid compliance risk.
2. Log the request and work with the team to assess impacts before seeking approval.
3. Send the request directly to the sponsor for a decision without analysis.
4. Reject the change because it threatens the schedule baseline.

Correct Answer: B — Log the request and work with the team to assess impacts before seeking approval.

Explanation: The proper first step is to document and analyze impacts, then route to the appropriate decision authority. Implementing or rejecting without analysis bypasses change control.