A change request should compare the agreed baseline with the requested difference and explain why it matters. Describe effects on outputs, effort, dependencies and timing, then present a clear decision for an authorized person. Keep the request distinct from approval and update the working plan only when the decision is actually confirmed.
Anchor the request to an identifiable baseline
Name the version of the scope, brief or deliverable that the request would change. Without a baseline, people can disagree about whether something is new work or part of the original understanding. Quote the relevant boundary accurately and describe the proposed difference in concrete terms. A request to add a second language version is easier to assess than a general instruction to make the project more complete.
Explain the reason for the request. A changed policy, a newly identified audience or a corrected factual assumption can each justify reconsidering scope. Do not imply that every change is unreasonable. The purpose is to make consequences visible so the right person can choose. Distinguish a correction needed to meet an existing commitment from an addition that changes what was originally agreed.
When that distinction is disputed, record both interpretations and the evidence needed to resolve them. A change process should not become a device for treating every review comment as extra work. Equally, an informal message should not silently require a substantial new deliverable. Clear baseline references help the discussion remain factual rather than relying on memory or whoever speaks most confidently.
Describe impact and realistic options
Assess what the request changes: quantity, specialist input, approval, access, cost or schedule. State what you know and where an estimate remains provisional. Include dependencies on the client or other providers. If a new requirement affects an already reviewed artifact, explain which checks would need to be repeated. Avoid presenting the change as a small edit when it creates a different delivery obligation.
Offer options when they help the decision. The client might replace a lower-priority output, extend the schedule or commission a separate phase. Describe the consequence of declining or deferring the request as well. Keep figures and dates consistent with the actual proposal and capacity. A decision note can be useful without pretending that every impact is precisely measurable before investigation.
Fictional example: an added audience after outline approval
In a fictional handbook project, a client asks for a volunteer edition after approving a staff-focused outline. The writer references the approved version and explains that the new audience requires different examples and review by the volunteer lead. The request is framed as an additional output rather than a routine wording correction. The estimate remains provisional until sample content is reviewed.
The decision note offers a separate volunteer supplement or a later phase, with the implications for the current deadline explained. The client’s coordinator can gather input but must obtain the publication owner’s decision. Until then, the writer continues only with unaffected agreed tasks. The scenario illustrates a change request and its status; it does not invent approval, fees or a completed additional edition.
A checklist for your next step
- Identify the agreed baseline.
- Describe the requested difference.
- Explain impact and uncertainty.
- Present a clear choice.
- Update records after approval.
Common questions
Is every revision a change request?
No. Corrections and revisions already included in the agreed scope should be handled accordingly. Use the baseline to assess the actual difference.
Can work start while the decision is pending?
Only within an explicitly understood boundary. Keep unaffected agreed work separate from unapproved additions and explain any resulting schedule dependency.
Further reading
These primary resources provide related background. They do not validate the illustrative example or endorse AliveProfile.
AI-assisted drafting and automated technical checks. Examples are illustrative; no independent expert review or real-world outcome validation is claimed. Read our editorial policy.