Lecture 15 — Change Happens

Simple Study Notes

Slide 2 — Why Does Change Happen?

Requirements change during a project for 4 reasons:
• Business needs evolve — company goals shift
• Market/regulations change — new laws force new requirements
• Stakeholders learn — they understand what they want better after seeing early results
• Technology advances — better tools become available
Example: A new data privacy law passes midway through a banking project — security requirements
must be added.

Slide 3 — Why Manage Changes?

• Prevent scope creep — stop uncontrolled growth of requirements
• Control cost & schedule — know the price of every change before doing it
• Improve quality — reviewed changes are better than random ones
• Enable informed decisions — decision-makers see full impact before saying yes

Slide 4 — Scope Creep

Scope creep = requirements keep growing with no control.
• Caused by informal requests — someone asks verbally and the developer just does it
• Leads to delays and budget overruns
Example: Developer keeps getting small requests via chat: 'add dark mode', 'add PDF export', 'add
notifications'... Each seems small but together they blow the deadline.

Key Point: Scope creep is the #1 cause of project failure. Each small addition seems harmless —
together they are fatal.

Slide 5 — Managing Scope Creep

• Clear scope baseline — agree exactly what IS and ISN'T included from the start
• Formal change process — every change, even small ones, must be submitted officially
• Impact analysis — analyse cost, time, and risk BEFORE approving any change
• Stakeholder awareness — everyone must know and follow the process

Slide 6 — Change Control Policy

A document that defines the rules for handling changes. It answers:
• How are changes handled? (step-by-step process)
• Who can request changes?
 • Who approves changes?
• How are changes tracked?
Example: Policy: 'Any stakeholder submits a form. BA analyses impact. CCB reviews weekly. All
decisions recorded in the requirements document.'

Slide 7 — Change Control Process — 4 Steps

Step Name What happens

Step 1 Submit Change Request Fill in a form: what is the change, why is it needed, what value
does it add?

Step 2 Impact Analysis Analyse: How much will it cost? How long? What risks? What
else is affected?

Step 3 Review by CCB The Change Control Board meets and reviews the request +
analysis together.

Step 4 Approve / Reject / Defer Approve = do it now. Reject = don't do it. Defer = do it in a later
version.

Slide 8 — Impact Analysis — 4 Things to Check

• Cost impact — how much money will this change cost?
• Schedule impact — how many extra days/weeks does it add?
• Technical risk — could it break something? Introduce security issues?
• Affected artifacts — which documents, code, and test cases need updating?
Example: Change: 'Add SMS notifications.' Cost: +$5,000. Schedule: +2 weeks. Risk: needs external
SMS provider. Affected: notification module, 8 test cases, database.

Key Point: Never approve a change without impact analysis. 'Quick fixes' that skip this cause the
biggest disasters.

Slide 9 — Change Control Board (CCB)

A group of people who review and decide on change requests. Usually 4 members:
• Project Manager — checks if change fits budget and schedule
• Business Analyst — checks if change aligns with requirements and goals
• Customer Representative — confirms if the change is truly needed
• Technical Lead — checks technical feasibility and risk
Example: Request: add fingerprint login. Technical Lead: '3 weeks of work.' BA: 'high user value.'
Customer Rep: 'users are asking for it.' PM: 'schedule to Version 1.1.' → Decision: DEFERRED.

Slide 10 — Requirements Baseline

Baseline = the officially approved version of requirements at a specific point in time.
• All stakeholders have signed off on it
 • Any change to the baseline needs formal CCB approval
• Supports version control — v1.0, v1.1, v1.2 of requirements
Example: Baseline v1.0 approved on March 1. A stakeholder asks for a new feature on March 15. It
cannot be quietly added — it needs a change request and CCB approval. If approved → Baseline
v1.1 is created.

Slide 11 — Change in Agile Projects

Agile handles change differently — it is built into the process:
• Product backlog — new changes are added as backlog items, not disruptive events
• Re-prioritisation — instead of rejecting changes, they are ranked by value and scheduled
• Continuous stakeholder involvement — stakeholders review every sprint, so changes are
planned naturally
Example: Midway through Sprint 3, stakeholder asks for 2FA. BA writes a user story, adds to
backlog, Product Owner prioritises it for Sprint 5. No crisis — just planning.

Key Point: Agile doesn't mean 'no control'. It means change is managed continuously through the
backlog instead of a separate formal CCB process.

Slide 12 — Common Mistakes

• Verbal changes — developer gets a hallway request and just does it. No record, no review.
• Skipping impact analysis — approving a 'quick fix' without analysis → it breaks 5 other things
• Poor documentation — changes approved but never written down → confusion about what was
agreed
• Weak communication — CCB approves a change but not everyone on the team is told →
conflicts
Example: 'Just change the date format' — without analysis nobody notices it's used in 47 places. A
1-hour task becomes 3 weeks.

Slide 13 — Best Practices

• Simple change process — if the process is too complex, people bypass it
• Always do impact analysis — make it a hard rule, no exceptions
• Maintain traceability — know which requirement links to which code and tests so you know what
to update
• Align with business goals — if a change doesn't serve a business goal, reject it
Example: Change: 'Add 3D animated logo.' No business goal link → Rejected. Change: 'Add bulk
import.' Business goal: reduce admin workload → Approved.

Slide 14 — Key Takeaways

• Change is inevitable — don't try to stop it, prepare to manage it
• Control avoids chaos — formal process turns change from a crisis into a routine
• Impact analysis is critical — every change must show its cost, time, and risk before approval
• Agile still manages change — through backlog and sprint planning, not a separate CCB
■ Quick Reference
Uncontrolled growth of requirements from informal requests → delays &
Scope Creep
overruns

Change Control Policy Rules document: who requests, who approves, how tracked

4-Step Process Submit → Impact Analysis → CCB Review → Approve/Reject/Defer

Impact Analysis Check: cost, schedule, technical risk, affected artifacts

CCB Project Manager + BA + Customer Rep + Technical Lead

Officially approved version of requirements — changes need formal CCB

Baseline
approval

Approve Do the change now

Reject Don't do the change

Defer Do it later in a future version

Agile change Added to product backlog → re-prioritised → no disruption

4 Reasons Change Business evolves · Regulations change · Stakeholders learn · Technology

Happens advances

4 Common Mistakes Verbal changes · Skip impact analysis · Poor docs · Weak communication

4 Best Practices Simple process · Always analyse · Traceability · Align with business goals

Good luck! ■