# Chapter 28: Change Happens

## Why Change Management is Needed

- Impossible to define all requirements at once; requirements change as development proceeds

- External conditions change (market opportunities, regulations, policies, internal business needs)

- Change is inherently not bad, but necessary

- Objectives of change management:

- Ensure changes are carefully evaluated before commitment

- Decisions made by appropriate personnel (not privately agreed upon by developers)

- Change information is transparent to stakeholders

- Change content is clearly notified and tracked

- Execute changes in a consistent and effective manner

## Problems with Uncontrolled Change

- Private communication on requirements causes requirements to enter through the back door

- Leads to project chaos, schedule delays, and quality degradation

- Inconsistency between documentation and code

- System becomes brittle (destroys architecture, causes hidden impacts)

- Causes massive extra rework in testing and documentation

## Scope Creep

### Causes of Requirement Growth

- Unclear customer requirements

- The larger the product, the more new functional requirements are encountered

- Monthly increase rate usually falls between 1%–3%

### Problems

- Continuously adding features without adjusting schedule / manpower / budget

- Leads to never-ending work

### Methods to Control Scope Creep

- Clearly define:

- Business goals

- Product vision

- Project scope and constraints

- Every requirement must be verified against business needs for necessity

- Deep customer involvement in requirement exploration

- Prototyping to avoid misunderstandings

- Use short cycles (iterations) for rapid adjustment

- Most effective technique: Dare to say "No" or "Not now"

## Change Control Policy

- All changes must be submitted according to the process

- No design or implementation allowed without review

- Submitting a change ≠ It will definitely be accepted

- Change Control Board (CCB) is responsible for deciding on changes

- Change database content must be visible to all stakeholders

- Every change requires Impact Analysis

- All changes must be traceable to the change request

- Change decisions must record the rationale

- Minor changes can go through the Fast Path (rapid review)

## Change Control Process

### Process Composition

1. Entry Criteria — Submit a valid change request

2. Tasks — Evaluate, Decide, Implement, Verify

3. Verification Steps — Ensure change is completed correctly

4. Exit Criteria — Change completed or closed

### 1. Roles and Responsibilities

- CCB Chair - Chairs the CCB, assigns Evaluator / Modifier, final decision maker

- CCB (Change Control Board) - Reviews and approves/rejects changes

- Evaluator - Conducts Impact Analysis (cost, risk, technical feasibility)

- Modifier - Implements the change

- Originator - The person who initiates the change request

- Request Receiver - Receives new change requests

- Verifier - Confirms if the change was completed correctly

### 2. Change Request Status (State Machine)

- Submitted → Received → Evaluating → Approved / Rejected → Change Made → Closed

- Only change state when transition conditions are met

### 3. Major Tasks

#### 5.1 Evaluate Change (Evaluate)

- Analyze cost, feasibility, risk, and consistency with requirements

- Conduct Impact Analysis (see later section)

#### 5.2 Decision

- CCB judgment: Approve, Reject, Defer

- Schedule priority, iteration, version

- Update status and notify the team

#### 5.3 Implement

- Modifier updates all affected artifacts

- Update traceability links

#### 5.4 Verify

- Peer review to check modification completeness

- Testing or document inspection

- Version control and document storage

### 4. Exit Criteria

- Status is Rejected / Closed / Canceled

- All artifacts updated and stored correctly

- Stakeholders have been notified

## Change Control Reports

- Show number of change requests in each status

- Show average processing time

- Project Manager uses to track progress

## Recommended Change Request Attributes

- Source of change (marketing, management, customer, dev…)

- Change ID

- Type (Requirement Change / Function Improvement / Defect)

- Submission / Update Date

- Description

- Priority (originator, CCB)

- Modifier / Verifier

- Scheduled Version

- Status

- Other response records

---

# Change Control Board (CCB)

## Functions and Purpose

- Decide which changes are acceptable

- Decide priorities, version scheduling

- Effectively balance:

- Business value

- Cost

- Impact (schedule, quality, risk)

## Composition Suggestions

- Project / Product Management

- Business Analysis / Product Management

- Development

- Testing / QA

- Sales / Customer Representative

- Technical Support

- If hardware is involved, include System / Hardware Engineer

## CCB Charter should include:

- Purpose, Scope of Authority

- Members and Roles

- Decision-making method (voting, consensus, whether chair has veto power)

- Meeting Frequency

- When special meetings are required

- What kind of changes need to be escalated to a higher-level CCB

---

# Impact Analysis

## Why It Is Important

- Small changes can cause a huge ripple effect

- Ignoring impact analysis leads to incorrect estimates, delays, and rework

## Three Steps of Impact Analysis

1. Understand potential impacts of the change

- Does it affect other requirements, architecture, or quality attributes

2. Identify all artifacts that need modification

- Documents, requirement specs, design, code, test cases

3. Estimate required work items and effort cost

## Common Tools

- Traceability matrix

- Affected component list (Figure 28-6)

- Effort estimation table (Figure 28-7)

- Result report template (Figure 28-8)

## Process Suggestions

- Evaluated by a small team (not a single developer)

- Use checklist to avoid omissions

- Compare actual costs with estimates to continuously improve the estimation model

---

# Change Management in Agile Projects

## Core Concepts of Agile

- Welcome change

- Continuously dynamic sorting in the product backlog

- Pick the highest value items for every iteration

- Iteration content can be fixed or adjustable (depending on team decision)

## Backlog-Driven Process

- New requirements → Enter backlog → Re-prioritize with other items

- High-priority items enter the next iteration

- Small scale, short cycles reduce the impact of change

## Equivalent Roles of CCB in Agile

- Product Owner / Customer decides priorities

- Team collectively evaluates change costs

- If change affects overall cost or schedule → Escalate to Sponsor

## Key Principles

- Avoid excessive turbulence (too many changes to complete iteration)

- Also avoid excessive rigidity (rejecting all new requirements)

- Adjust iteration length to adapt to change frequency

---

# Next Steps

- Establish your project CCB (and charter)

- Define the state diagram for change requests

- Write the Change Control Process (operate manually first to confirm effectiveness)

- Select a suitable Issue Tracking tool and customize the process

- Compare: Old estimation methods vs Impact Analysis methods → Continuously optimize