Why Change Management Exists
Change is inevitable in IT projects. Requirements evolve, technology shifts, stakeholders discover new needs, and market conditions change. The question is not whether change will happen — it is whether change will be controlled or chaotic. Uncontrolled change leads to scope creep, budget overruns, and missed deadlines.
Change management ensures that every change is evaluated, approved, tracked, and communicated. It does not prevent change — it ensures that change is intentional and its impacts are understood before implementation.
Change Request Process
- 1. Submit: Anyone can submit a change request (CR) with a description and justification
- 2. Log: PM records the CR in the change log with a unique ID
- 3. Analyze: Team performs impact analysis (scope, schedule, cost, quality, risk)
- 4. Review: Change Control Board (CCB) reviews the CR and impact analysis
- 5. Decide: CCB approves, rejects, or defers the change
- 6. Implement: If approved, update the project plan, baselines, and communicate to the team
- 7. Verify: Confirm the change was implemented correctly
Change Request Template
// Change Request Data Model
interface ChangeRequest {
id: string;
title: string;
requestedBy: string;
requestDate: Date;
priority: 'critical' | 'high' | 'medium' | 'low';
type: 'scope' | 'schedule' | 'cost' | 'quality' | 'resource' | 'technical';
status: 'submitted' | 'analyzing' | 'pending-approval' | 'approved' | 'rejected' | 'deferred' | 'implemented';
description: string;
justification: string;
businessValue: string;
impactAnalysis: {
scopeImpact: string;
scheduleImpact: string;
costImpact: string;
qualityImpact: string;
riskImpact: string;
resourceImpact: string;
alternativesConsidered: string[];
};
decision: {
decidedBy: string;
decisionDate: Date | null;
outcome: 'approved' | 'rejected' | 'deferred' | null;
conditions: string[];
rationale: string;
};
implementation: {
assignedTo: string;
targetDate: Date | null;
actualDate: Date | null;
verifiedBy: string | null;
};
}
// Example change request
const changeRequest: ChangeRequest = {
id: 'CR-2024-015',
title: 'Add Apple Pay to checkout flow',
requestedBy: 'Maria Garcia (VP E-Commerce)',
requestDate: new Date('2024-06-15'),
priority: 'high',
type: 'scope',
status: 'pending-approval',
description: 'Add Apple Pay as a payment option in the mobile app checkout flow. This was originally planned for Phase 2 but competitive pressure requires earlier delivery.',
justification: 'Competitor launched Apple Pay support last week. Our mobile payment conversion rate is 15% below industry average. Apple Pay users convert 30% higher.',
businessValue: 'Estimated $1.2M additional annual revenue from improved mobile checkout conversion.',
impactAnalysis: {
scopeImpact: 'Adds 3 user stories (8, 5, 3 points = 16 total). Requires Apple Developer Program enrollment and merchant ID setup.',
scheduleImpact: 'Delays launch by 1 sprint (2 weeks) unless we defer the product recommendations feature.',
costImpact: 'Apple Developer fee: $99/year. Engineering effort: ~$25K. Total impact: ~$25K.',
qualityImpact: 'Minimal — Apple Pay SDK is well-documented. Additional E2E tests required.',
riskImpact: 'Low risk — Apple Pay is a proven integration. Risk of app rejection if guidelines not followed.',
resourceImpact: 'Requires iOS specialist (already on team). Backend engineer needed for 3 days.',
alternativesConsidered: [
'Defer to Phase 2 (original plan) — rejected due to competitive pressure',
'Add Apple Pay but remove product recommendations from this release — recommended option',
'Hire contractor to implement in parallel — too expensive and coordination overhead'
]
},
decision: {
decidedBy: '',
decisionDate: null,
outcome: null,
conditions: [],
rationale: ''
},
implementation: {
assignedTo: '',
targetDate: null,
actualDate: null,
verifiedBy: null
}
};Scope Creep vs. Gold Plating
| Aspect | Scope Creep | Gold Plating |
|---|---|---|
| Definition | Uncontrolled expansion of scope | Adding unrequested features or quality |
| Source | Stakeholders, users, external changes | The team themselves (engineers, PM) |
| Example | "Can you also add Apple Pay while you are building checkout?" | Engineer adds advanced animation to a simple button |
| Prevention | Change control board, formal CR process | Clear DoD, code reviews, sprint scope protection |
| Impact | Schedule delays, budget overruns | Wasted effort, opportunity cost, potential bugs |
Change Management Best Practices
- Every Change Has a Cost: Even "small" changes have integration, testing, and documentation costs. Make requestors aware.
- Aggregate Small Changes: Small CRs can accumulate into significant scope creep. Review total accumulated change monthly.
- Baseline First: You cannot manage change without a baseline. Establish scope, schedule, and cost baselines before execution.
- Say "Yes, and...": Do not simply reject changes. Say "Yes, we can add Apple Pay if we defer product recommendations. Here is the trade-off."