How do you handle change requests during the Build phase?

Build-phase change requests test the project's discipline. Without process, they spiral; with process, they get managed.

Change request types:

1. Discovery gap — requirement that was missed in Discovery. Genuine need; needs to be in Build.
2. Stakeholder rethink — somebody changed their mind about a requirement.
3. External shift — regulation changed, business priority changed.
4. Refinement — small adjustment to an existing feature.
5. Net-new desire — additional feature outside original scope.

Each warrants different handling.

Process:

1. Capture: every change goes into a change request log. Description, requester, reason, impact assessment placeholder.

2. Triage: weekly (or more frequently for active projects). Classify each:

• Critical — blocks go-live; must address.
• Important — strong value; consider for current phase.
• Nice-to-have — defer to Phase 2.
• Not needed — politely decline.

3. Impact assessment: for changes being considered, estimate effort, schedule impact, budget impact, risk.

4. Decision: approve, defer, decline. Decision-maker depends on impact:

• Within sprint capacity, no schedule impact — Project Manager decides.
• Schedule impact within budget — Steering Committee.
• Budget impact — formal change order, sponsor signs.

5. Communicate: decision logged; requester informed; if approved, story added to backlog with priority.

6. Document the decision: rationale, implications, who decided. Future-proof.

Practical guidance:

• Don't say no without an alternative. "We can't fit that this phase, but here's how it could be Phase 2."
• Quantify trade-offs visibly. "If we add this, X is delayed by 2 weeks." Forces real decisions.
• Group changes for efficiency. Several small changes in one sprint reduce churn.
• Don't sneak changes in. Doing it without process erodes trust.
• Defend the original scope politely. "We'll deliver what we agreed; here's how to handle the new request."

When to push back hard:

• Requests that violate architectural principles (e.g., "let's customise this Industry Cloud heavily" defeats the purpose).
• Late-stage requests that destabilise testing.
• Requests driven by "shiny object syndrome" with no business case.

Senior consultant insight: change is the norm; managing it is the discipline. Projects without changes are either too short, too small, or in denial. Embrace process, not paranoia.

The art: be flexible enough to accommodate genuine changes, firm enough to protect the project. Skill comes with experience.