A small request can change more than one sentence. Adding a new example may require another tool check, a screenshot, a reviewer, and a later publication date. If those consequences remain unstated, a team can agree to the wording of a request without realizing that it has also changed the project.

A change request note makes the proposal concrete before work begins. It is not automatically an approval, a contract amendment, or a commitment to a new deadline. Use the approval process that applies to your project and let the note preserve the information needed for that decision.

State the requested change plainly

Describe the difference between the current agreed deliverable and the proposed one. In a fictional guide project, the existing scope covers exporting one note as text. The request is to add a section comparing three export formats. That is more specific than “make the guide comprehensive.”

Include the reason. The requester may have a genuine reader problem that can be solved in more than one way. If the problem is that readers confuse export formats, a short decision aid might help without requiring three complete demonstrations. Understanding the need allows useful alternatives.

Preserve the current baseline

Point to the version of the brief, schedule, or deliverable being changed. A change is meaningful only relative to a known baseline. If several people have different assumptions about the current scope, resolve those assumptions before estimating the proposal.

Do not overwrite the original brief as soon as a request arrives. Keep the proposal separate until it is accepted, rejected, or revised. Otherwise the record can make an unapproved suggestion look like a requirement everyone already agreed to deliver.

Assess the affected work

List the tasks and dependencies the change introduces. The fictional format comparison may require new sample files, checks in each format, revised headings, and another editorial review. Identify the work that becomes unnecessary as well as the work that is added.

If you cannot estimate the impact yet, name the investigation needed. “Check whether the existing tool supports the requested format” is an honest next step. A precise estimate without that knowledge can be less useful than a clearly bounded uncertainty.

A usable change request entry

Request ID: CH-04.
Baseline: Export guide brief, version 2.
Proposal: Add a three-format comparison section.
Reason: Readers need help selecting a format for review.
Affected work: Sample preparation, output checks, wording and review.
Alternative: Add a short format-selection paragraph linking existing guides.
Unknown: Whether the third format preserves the sample list.
Decision owner: Project editor.
State: Proposed; not yet approved.
Next action: Check the third format with harmless sample text.

This entry separates a useful request from a commitment. The decision owner can compare the full proposal with the smaller alternative instead of choosing between doing everything and doing nothing.

Record the decision and its conditions

When the authorized person decides, add the date, outcome, and any conditions. An approval may depend on moving the publication date or removing another section. Those conditions are part of the decision, not optional background.

If the request is rejected, keep the reason briefly. A future colleague may otherwise raise the same proposal without knowing it was considered. If it is deferred, state what would trigger reconsideration rather than placing it in an indefinite holding area.

Update connected records once

After approval, update the brief, relevant tasks, and schedule in their working systems. Link them to the change request so the reason remains discoverable. Do not maintain separate competing dates in the request note and the task board.

Notify the people whose work is affected through the team's agreed channel. Writing a changed deadline in a private note does not tell a reviewer that their availability is now needed on a different day. The note supports coordination; it does not perform it automatically.

Watch for a series of small additions

Several individually small requests can produce a large change. Keep a simple list of accepted changes against the baseline and review the combined effect. The issue is not whether each request sounded reasonable, but whether the final project still matches its time and capacity.

Do not label every correction as scope expansion. Fixing an error in an agreed deliverable is different from adding a new deliverable. When the distinction is disputed, refer to the baseline and completion criteria rather than relying on how difficult the work feels.

Close the request when the change is verified

A request is not complete merely because someone edited the draft. Check the approved outcome: the section exists, the sample result is accurate, and the required review happened. Record unresolved parts separately.

A good change note lets a later reader see what was proposed, why it mattered, who decided, and what was actually delivered. That is enough structure to protect the project from accidental expansion while still allowing useful changes.

Use the BiNotePads online notepad to adapt this example. For a separate copy of important work, follow the browser-note backup guide.