Scope creep often arrives as a reasonable sentence: while you are there, can you also add this? Each addition may look small, yet several can change schedule, cost, risk, and acceptance. When changes remain informal, the team absorbs the consequence while stakeholders continue expecting the original commitment.
A lightweight change note makes expansion visible without turning every request into bureaucracy. It records the requested difference, reason, effect, options, decision owner, and approval. The goal is not to resist change. It is to ensure that changed expectations create changed plans.
Compare the request with the agreed baseline
Identify the existing outcome, inclusions, exclusions, and acceptance criteria. Then write exactly what the new request adds, removes, or changes. Without a baseline, conversations become arguments about memory. Link to the approved brief, proposal, or decision record rather than relying on personal recollection.
Do not label the requester unreasonable. Many changes are valuable responses to new information. Describe the difference neutrally and ask what problem the change solves. Understanding the purpose may reveal a smaller option that protects the essential benefit.
Trace the full consequence
Check effort, sequence, dependencies, review, cost, risk, and downstream deliverables. A new field may require data migration, testing, training, and reporting changes, not merely a screen edit. Consult the people doing the work rather than estimating impacts from a distance.
State uncertainty honestly. If the impact needs investigation, offer a short assessment task and time. Do not begin the full change merely to learn its cost unless the decision owner explicitly authorizes that exploratory work and understands its limit.
Offer a real choice
Present options such as add the change and move the date, trade it for an existing item, deliver it in a later phase, or decline it because risk exceeds value. Include a recommendation and reasoning. Choices turn a tense yes-or-no moment into a decision about priorities.
Avoid the false option of preserving scope, date, cost, and quality through extra effort nobody approved. Hidden overtime transfers the cost to the team and makes future estimates look inflated. If additional effort is a legitimate option, name who provides it and what risk remains.
Update every affected promise
After approval, update the task, schedule, budget, acceptance criteria, and stakeholder message. A change note that stays separate from execution creates two competing truths. Name the effective version and make the old expectation visibly superseded.
Review accumulated changes periodically. Several individually approved additions may produce a project nobody would have approved as a whole. A cumulative view helps decision-makers reconsider value, simplify, or stop. Integrity includes showing the total consequence, not only securing approval one request at a time. Include the combined schedule movement, budget movement, added dependencies, and support burden. Compare the changed project with the original intended benefit before authorizing another addition.
Write a six-line change note
- Link the current approved baseline and state the requested addition, removal, or modification in neutral, specific language.
- Write the business reason and assess effects on effort, date, cost, dependencies, risk, quality, and acceptance.
- Offer at least two viable choices, including what will move or be removed, and provide your evidence-based recommendation.
- Name the decision owner and, after approval, update all source plans and communicate the superseded commitment.
Common questions
Is a change note necessary for a tiny request?
Use proportionate detail. A brief task comment may be enough, but capture the change whenever it affects an agreed outcome, date, cost, risk, or another commitment.
What if the requester says there is no time for assessment?
State the uncertainty and propose the smallest safe assessment. If they choose immediate action, record who accepted which unknown consequences and define a review checkpoint.
