Record what changes, what depends on it and who must decide. A request becomes part of the work when its scope and conditions have been agreed.
Find the reference version
Before estimating effort, collect the approved brief, deliverables and later accepted clarifications. Identify the team’s version and the client’s. Resolve differences first: evaluating a new request against different documents produces two apparently reasonable answers.
Atlassian describes a project baseline as a reference for comparing the plan and its changes. For a small service, a dated document with scope, owners and open questions may suffice. Keeping it accessible supports a conversation around one shared reference.
Describe the change with a before and after
In a fictional example, a studio agreed to prepare four catalog pages using approved text. The client asks for a second version by market. Record whether this means translation, different information or another product selection; these involve different work despite the brief initial message.
Write one before sentence and one after sentence: “One four-page edition” and “Two editions with differences still to be defined.” Add the client’s stated reason. A correction needed to meet the existing agreement should be distinguished from a request expanding the outcome; review the case before classifying it.
Review effects on the whole
- Inputs: what new information or materials are needed.
- Work: which parts remain, change or need redoing.
- Dependencies: which review, supplier or delivery waits on the change.
- Conditions: which dates, resources or agreements need reconsideration.
- Decision: who can accept the new version and what is needed first.
Atlassian’s change-control guidance separates a request from evaluation and approval. Our lightweight record makes these questions visible. When important information is missing, retain a provisional estimate and identify the condition that could change it.
Offer a response that supports a choice
A fictional reply might say: “We can retain the agreed edition and prepare the second afterward, or review both together once the market-specific text is available. We need to choose a route before confirming a new schedule.” Explain what each option preserves and changes.
Keep the decision and its conditions in writing through the agreed channel. A received request and a proposed alternative are different states from an accepted change. Our proposal follow-up guide helps revisit an open decision with context.
Update the reference used by the team
Once agreed, record the new version, what it replaces and what remains in effect. Tell the people producing, reviewing or awaiting delivery. Check whether an old file is still circulating and where the current document belongs. The explanation can be brief if it makes the difference recognizable.
Our task-handoff record helps pass new inputs and criteria to another person. Update the review sample and approval point if delivery has changed. An instruction corrected on your computer still needs to reach everyone working from it.
Close the change with a useful observation
At completion, compare expectations with what the change actually required: missing material, additional review or an unseen dependency. Keep the observation with the closure record. If requests repeatedly expose the same uncertainty, clarify future proposal scope or prepare a specific option.
Our service-validation guide helps review delivery assumptions. A change record supplies evidence about those assumptions during the work. Its value lies in preserving decisions and learning from concrete cases without treating one experience as a rule for every client.
Follow the evidence.
Sources checked October 18, 2026. Illustrative scenarios and numbers are fictional. The records and exercises are original editorial proposals, without attributed customer results or provider tests. Our editorial standards.
