HKSM

A structured way to evaluate, approve, and coordinate changes across the entire project. It ensures each change is impact‑assessed, decided by the right authority, and implemented in a controlled manner to protect baselines and benefits.

Key Points

• Provides a single, consistent path for all change requests.
• Assesses cross-impacts to scope, schedule, cost, quality, resources, risks, and contracts.
• Uses defined decision rights (e.g., change control board or delegated thresholds).
• Maintains traceability from request through decision, implementation, and verification.
• Protects approved baselines; updates occur only after formal approval.
• Sets service levels for turnaround time, documentation standards, and communication.

Purpose of Analysis

To determine whether a proposed change increases value, reduces risk, or is necessary for compliance, and whether it is worth the trade-offs. Analysis informs a go/no-go decision and guides sequencing and funding of approved changes.

Method Steps

• Capture: Log the request with clear need, rationale, and benefits.
• Triage: Check completeness, categorize (defect, enhancement, compliance), and route to the right authority.
• Analyze: Estimate impacts on scope, schedule, cost, quality, resources, risk, procurement, and benefits; identify options.
• Recommend: Prepare alternatives with impacts, assumptions, and a preferred option.
• Decide: Obtain approval, rejection, or deferral per the governance rules.
• Plan Implementation: Update plans, create tasks, assign owners, and define acceptance criteria.
• Communicate: Notify stakeholders of the decision and next steps.
• Implement and Verify: Execute the approved change, confirm results, and update configuration records.
• Close and Learn: Update the change log, baselines, reports, and lessons learned.

Inputs Needed

• Completed change request form with rationale, benefits, and urgency.
• Project management plan components: change management plan, configuration management plan, scope baseline, schedule baseline, cost baseline, quality management plan, resource plan, communications plan, and risk management plan.
• Work performance data and reports, issue log, and risk register.
• Business case, benefits management plan, and product roadmap.
• Contracts, vendor proposals, and service-level agreements.
• Assumption log, constraints, and organizational policies or compliance requirements.

Outputs Produced

• Approved change requests with implementation instructions and acceptance criteria.
• Rejected, deferred, or withdrawn requests recorded with reasons.
• Updated baselines and subsidiary plans, when applicable.
• Change log and configuration documentation updated with versions and status.
• Implementation tasks scheduled, resourced, and tracked.
• Stakeholder communications and status report updates.
• Lessons learned register entries on impacts, decisions, and cycle times.

Interpretation Tips

• Align decision thresholds with risk and authority; not every change needs full board review.
• Separate defect repair and preventive actions from scope additions; both still follow control but may have fast tracks.
• Quantify impacts using ranges and confidence levels; include secondary risks and opportunity costs.
• Measure and manage cycle time for decisions to avoid bottlenecks.
• Maintain an auditable trail linking requests to implemented changes and baseline updates.

Example

A customer requests a reporting filter mid-release. The PM logs the request, has the team estimate two options: add now (adds two weeks, $25k, minor risk) or bundle in next release (no current delay, higher future rework risk). The board approves bundling, the schedule remains intact, the backlog and release plan are updated, and stakeholders receive a clear decision note with rationale.

Pitfalls

• Approving or implementing changes without quantified impact analysis.
• Letting urgent requests bypass governance without defined emergency protocols.
• Failing to update baselines and configuration records after approval.
• Gold-plating features without a formal request and business rationale.
• Using vague change descriptions that hide scope creep.
• Mixing issue resolution with formal changes, resulting in poor traceability.
• Ignoring cumulative impact of many small changes on schedule and budget.

PMP Example Question

Mid-project, a sponsor asks to add a feature that may increase cost and extend the schedule. What should the project manager do next?

1. Approve the change and direct the team to start immediately.
2. Analyze the impacts and submit the request through the established change process.
3. Update the scope baseline and inform stakeholders of the new delivery date.
4. Ask the sponsor to negotiate scope directly with the team lead.

Correct Answer: B — Analyze the impacts and submit the request through the established change process.

Explanation: The PM follows the change management plan: perform impact analysis, document options, and route for formal decision before updating baselines or starting work.