Change Request
How to treat change requests as a normal part of project operations by making the change, rationale, impact, decision, and new baseline explicit.
Change is normal
Projects operate in reality: stakeholders change, constraints move, user feedback arrives, dependencies slip, and objectives evolve.
Scope drift is different from a Change Request
Scope drift happens when work changes but the agreement does not.
A Change Request turns that change into an explicit decision.
Framework: Change → Reason → Impact → Decision → New Baseline
Change — what is being proposed?
Reason — why is it needed?
Impact — what changes in scope, effort, cost, timing, dependencies, and risk?
Decision — approve, reject, defer, or modify?
New Baseline — what becomes the new agreement?
Reason separates need from preference
Not all new requests carry the same weight.
A compliance requirement is different from a late-stage preference.
Impact should be viewed as a system
Adding one deliverable can change sequence, feedback cycles, QA load, and dependencies.
Decision authority must be clear
A Change Request needs a real decision owner.
If everyone can request changes but nobody owns the trade-off, control disappears.
Approved change must create a New Baseline
If a change is approved but scope, milestones, or timing remain unchanged on paper, the project is now operating with two realities.
Rejected changes also need rationale
A rejection without rationale feels arbitrary.
Rationale makes the trade-off visible.
Applying this on Forwork
Forwork can include a Change Request Block: Requested Change, Reason, Scope Impact, Timeline Impact, Cost Impact, Risks, Decision, Decision Owner, Date, New Baseline.
It can link to Scope, Milestones, Decision Log, and Work Tracking.
Conclusion
Do not only ask, “Can we add this?”
Ask: “If we accept this change, what part of the agreement changes, and what is the new baseline?”
Change → Reason → Impact → Decision → New Baseline.