HKSM

A formal process to review, decide on, and track all change requests so only approved changes are implemented. It evaluates impacts across the entire project, updates baselines and plans, and communicates decisions to stakeholders.

Purpose & When to Use

• Keep the project baselines credible by controlling what changes are allowed and how they are implemented.
• Ensure each proposed change is assessed for impacts on scope, schedule, cost, quality, resources, risks, benefits, and contracts.
• Apply whenever a change is requested to requirements, deliverables, baselines, or plans, including corrective, preventive, and defect repair actions.
• Used throughout the project. In adaptive approaches, backlog changes are frequent, but formal approval is still needed for contract, budget, or baseline shifts.

Mini Flow (How It’s Done)

• Submit and capture the request: The requester documents the change, reason, urgency, and expected benefits; the project manager logs it in the change log with an ID.
• Screen for completeness: The project manager checks clarity and required data; incomplete requests are returned for more information.
• Analyze impacts: Team and experts assess effects on scope, schedule, cost, quality, resources, risks, procurement, benefits, and technical feasibility; consider alternatives, including doing nothing.
• Update supporting information: Draft updates to estimates, the schedule, budget, risk register, requirements traceability, and configuration items as needed.
• Form a recommendation: Summarize options, costs, benefits, risks, and priority; propose approve, defer, or reject with rationale.
• Decision by authority: The Change Control Board (or defined authority) decides using agreed decision rules; record the outcome, conditions, and date.
• If approved: Update baselines and relevant plans, create work packages or backlog items, allocate resources, and communicate the decision.
• Implement and monitor: Execute the approved change via project work, track results, and verify the change achieved the intended outcome.
• If rejected or deferred: Record the decision, rationale, and any follow-up date; inform stakeholders.

Quality & Acceptance Checklist

• Change request describes the problem/opportunity, justification, and measurable acceptance criteria.
• Impact analysis covers scope, schedule, cost, quality, resources, risks, benefits, procurement, and dependencies, including cumulative effects.
• Alignment with business case, constraints, policies, and contractual terms is confirmed.
• Relevant stakeholders (including product owner and vendors, if applicable) were consulted; traceability to requirements or user stories is updated.
• Risks, assumptions, and reserves are reviewed and updated; contingencies are adequate.
• Configuration items affected are identified; versions and traceability are maintained.
• Decision authority followed; approvals recorded with conditions and effective date.
• Baselines, subsidiary plans, and backlog are updated; communications sent to all impacted parties.
• Implementation plan, owner, schedule, and success metrics are defined.
• Change log is current and lessons learned are captured.

Common Mistakes & Exam Traps

• Implementing a change before formal approval or without documenting the decision.
• Assuming the sponsor or product owner can approve all changes; follow the defined governance and CCB rules.
• Analyzing only one constraint (e.g., cost) and ignoring integrated impacts on scope, time, quality, risk, and benefits.
• Failing to update baselines and plans after approval, leading to misaligned performance reporting.
• Confusing defect repair with scope expansion; both still require control and approval.
• Treating verbal or informal agreement as sufficient evidence of approval.
• Blending backlog refinement with formal change control in predictive contracts that require baseline and budget changes.
• Overlooking procurement or contract implications, such as change orders and claims.
• Skipping benefit/cost analysis or ignoring the effect on management and contingency reserves.
• Using change requests for routine execution choices that the team can manage within existing baselines.

PMP Example Question

Midway through the project, a key stakeholder asks to add a new feature and urges the team to start work immediately because “it will delight users.” What should the project manager do first?

1. Ask the product owner to approve and immediately add the work to the next iteration.
2. Record the request in the change log and begin an impact analysis with the team.
3. Update the scope baseline and notify the team of the new requirement.
4. Escalate to the sponsor for an urgent decision and bypass normal review.

Correct Answer: B — Record the request in the change log and begin an impact analysis with the team.

Explanation: The first step is to log and assess the change so an informed decision can be made by the proper authority. Implementing or updating baselines before review violates change control governance.