Change Request Form: Decide What Changes Before You Add Work

A change request form records a proposed alteration to an agreed project, its likely effects, and the decision about whether to proceed. Use it before extra work becomes an invisible commitment. The form should make clear what changes, what stays, and who has authority to approve the trade-off.

Download the editable change request form. It includes a blank working copy, a completed fictional example, and a checklist for updating the plan after approval. You can use it without an account or a project-management app.

The point is not to discourage useful changes. It is to stop saying yes to the benefit while leaving the cost, delay, or displaced work unspoken.

What belongs on the form?

Record the current agreement, the proposed change, the reason, the effects, the alternatives, and the decision. A requester should be able to explain the need without pretending to know every delivery consequence.

The UC Berkeley project toolkit describes a change form that considers schedule, cost, quality, alternatives, and sponsor approval. That is the useful discipline: assess the change against an existing commitment instead of evaluating the request in isolation.

Link the form to the approved project brief. If no baseline exists, first establish what everyone believes was promised. You cannot tell whether something is additional work when the original agreement is still unclear.

Keep the request separate from its decision. “Submitted by Casey” identifies who raised it; it does not establish that Casey can authorize a different deadline or another team's effort.

What does a completed request look like?

A completed request describes a concrete difference and shows what must give way. The following example is fictional; its hours and dates illustrate a decision, not measured productivity or a standard estimate.

Request CR-04: add a translated expense FAQ.

Current agreement: publish one English FAQ answering six approved questions, with a working link in the welcome message. Casey accepts the completed delivery on Friday.

Requested change: add a Spanish version and a language-selection link for the same six questions.

Reason: the next onboarding group includes colleagues who would benefit from Spanish instructions.

Assessment: Morgan estimates four additional hours to coordinate the adaptation and layout. A qualified reviewer estimates two hours to verify the translated policy wording. Those six staff-hours are separate from waiting for the reviewer's available slot.

Dependency: Lee must confirm who is authorized and available to check the translation. Until that is confirmed, a firm publication date for the translated version is not established.

Option A: keep Friday's English release and schedule the translated version separately after reviewer availability is confirmed.

Option B: publish both versions together, with a revised date agreed after the review slot is booked.

Option C: retain the current release and record the translation as a separate future request, with a named person responsible for the decision.

Decision: Casey approves Option A, conditional on Lee confirming an appropriate reviewer. Morgan updates the delivery plan and communicates that the English release remains Friday; the translated release date is still uncommitted.

This decision preserves the original benefit without pretending the extra version is free. It also distinguishes “approved in principle” from “ready to schedule.”

If the new version is essential for the intended audience to use the original delivery, Option A may be unacceptable. The example is a way to expose that question, not a recommendation to release inaccessible or unsuitable material.

How do you assess impact without inventing certainty?

Ask the people doing and accepting the work to validate the estimate, assumptions, and dependencies. Label unknowns plainly rather than turning an optimistic guess into a promised date.

Work through five checks:

1. Scope: what new output or changed acceptance condition is involved?
2. Effort: which activities must be performed, by whom?
3. Timing: what review, access, or external dependency affects the calendar?
4. Quality: what checks remain necessary under each option?
5. Displacement: what already-promised work moves if this is accepted?

A six-hour estimate does not mean the change can be delivered tomorrow. Two people may need separate work windows, and the second activity may depend on the first. Use the existing workback schedule to check that dependency instead of compressing every hour into one imaginary afternoon.

Do not write “no impact” when you mean “impact not assessed.” If an estimate needs a review, give that review an owner and a completion condition. For example: “Lee confirms reviewer availability before a translated release date is offered.”

Asana's change request guidance separates capturing requests from reviewing impacts and managing approval status. You can preserve that separation in a plain document; automation is not required to make the decision traceable.

For a request that is actually a different project, use the project intake form. A change form should not become a back door through which an unrelated initiative bypasses normal prioritization.

Who decides, and how is it recorded?

The person authorized to change the commitment should make or confirm the decision. A team member can assess the work without having authority to approve additional funding, a new deadline, or another team's contribution.

Record the decision date, decision-maker, selected option, conditions, and rationale. “Approved” alone is too vague when the approval depends on a reviewer, a budget check, or another deliverable being removed.

Use clear states:

• Approved: proceed within the recorded conditions.
• Rejected: do not implement this request; preserve the reason.
• Deferred: revisit at a named date or trigger.
• More information needed: identify the missing answer and its owner.

These are suggested working states, not a universal standard. Use your organization's required controls where they exist.

The Berkeley toolkit also distinguishes the request form from the change log. The form holds the assessment; the log helps people find requests and see their current status. Link them using the same request identifier.

How do you prevent hidden overload after approval?

Update the baseline, working plan, and affected people before treating approval as complete. A decision that remains only in the form leaves the team working from different versions of the commitment.

Record the previous agreement in the change history, then publish the revised one. Do not silently replace the old deadline and erase the reason it moved.

Confirm who will implement the change, who will verify the result, and which existing commitment has been adjusted. If nothing can move and capacity is full, the decision is not yet operationally workable.

Bring the accepted work into your weekly plan. Stop carrying both the old plan and the revised plan as if both can still be delivered unchanged.

Do Only 3 Things a Day helps with that daily consequence: choosing the outcomes you can realistically finish and giving them protected attention. This form records the trade-off. The next day's plan needs to reflect it.

Frequently asked questions

Is every small correction a change request?

No. Correcting work so it meets an already-agreed requirement may be ordinary delivery. Use change control when the commitment itself changes, and follow any stricter rules your organization requires.

Can work begin before approval?

Usually, wait until the required decision is recorded. If your organization permits an urgent exception, use its authorized process and document the exception; urgency alone does not create permission.

What if the impact is unknown?

Request a bounded assessment before committing to implementation. State what needs investigation, who will do it, and what decision the assessment will enable. Do not disguise uncertainty as zero impact.

How is a change log different from a request form?

The log summarizes multiple requests and their status. An individual form explains one proposed change, its assessment, and its decision. Keep a shared identifier so readers can move between them.