Guide · Project management
How to Handle a Project Change Request Without Losing the Plan
Turn an informal request into a clear decision about scope, dependencies, acceptance, and timing.
"Could we also add a client dashboard?" might arrive as a quick comment during a review. It could be a small improvement or a second project. Give the request enough shape to make a decision before it becomes an unplanned promise.
Find the job behind the request
Ask what the client needs to see or do that they can't do today. A request for a dashboard might really mean they want to check the status of three open items. It might also mean they need accounts, permissions, uploads, and reports. Those lead to very different work.
Write a short example using the client's situation. "The account owner signs in and sees the next due task for each active project" is more useful than "a portal like the one we saw." It gives the team a behavior to discuss and eventually test.
Compare it with the agreement
Look at the accepted scope and the assumptions used to plan the work. Determine whether the request changes an existing deliverable, clarifies something already included, or adds a new capability. Don't treat every correction as an extra, and don't let every new feature hide inside the word "tweak."
For a hypothetical booking site, correcting the displayed appointment time may be necessary to meet the original requirement. Adding a second booking workflow for another business unit could be new scope. The distinction should be explainable from the agreement and the behavior being requested.
Trace the effect before estimating
List what the change touches. A new field may affect the form, storage, validation, notifications, exports, and the screen where staff review submissions. The visible interface change might be the smallest part of the job.
Ask which decisions are still missing. If the client hasn't chosen who can view the data, a precise implementation estimate would hide a major unknown. State the assumption or propose a short discovery step to resolve it. Keep the estimate tied to the version of the request you actually assessed.
Offer a decision the client can make
Present the requested outcome, the proposed scope, the important assumptions, and the effect on the current plan. Depending on the situation, the options might be adding it now, replacing a lower-priority item, or scheduling it after the original delivery.
Avoid presenting an option that sounds free of tradeoffs when it isn't. Deferring a feature may protect the launch date but leave a temporary manual step. Adding it now may delay another deliverable. Let the client see what they're choosing rather than discovering the consequence later.
Update the work record after the decision
Once the change is accepted, link the decision to its tasks and revise the relevant acceptance conditions. Tell the people whose work depends on it. A comment from the client shouldn't be the only evidence that the plan changed.
If the change is declined or deferred, keep that outcome visible too. Otherwise the same request may resurface as an assumed commitment during the next review. A short, dated decision record keeps the conversation clear and gives the team a reliable place to check what they are actually building.