The Intent Ledger
← All articles

Design Change Request: How to Write, Review and Record One

Design Change Request: How to Write, Review and Record One

A design change request is a written proposal to alter something about a design after its scope, budget or direction has been agreed. It names the change, says why it is needed, and shows what it does to time, cost and quality, so someone with authority can approve, reject or defer it. This guide covers when to file one, what the form needs, who decides, and how to keep the reasoning findable long after the decision.

Theintentledger
Keep the Reason Behind Each Change
The Intent Ledger turns design conversations and client comments into source-backed records of decisions, risks, actions, and unresolved questions.
Explore project memory software

TL;DR

  • File a design change request when a change moves outside the agreed scope or affects cost, schedule or deliverables. Routine tweaks inside scope are revisions.
  • A usable form carries the requestor, the reason, the impact on scope, time, cost, resources and quality, the decision, and sign-off.
  • Assess before you decide: classify the request, weigh the options (including doing nothing), then approve, reject or defer.
  • Keep the original request, the signed decision and the rationale together, and close the request after verification.
  • The form records what changed. The conversation behind it explains why, so link the two.

Table of Contents

What a design change request is, and what it is not

A design change request (often shortened to CR, as in “CR in project management”) is a formal ask to change an approved part of a project. The part might be the scope, the budget, the schedule, a specification or a drawn solution. The key word is approved. Before approval, you are simply designing. After it, any change has a price somebody has to accept.

That is why teams separate two things that clients often blur together: revisions and change requests. One design studio’s guidance puts the line this way: revisions fine-tune work inside the initial scope, while a change request goes outside it and usually affects timelines and costs. The same author argues that drawing this line clearly is what keeps a design process smooth.

In practice, here is how it looks on an architecture or design job:

Situation Revision or change request?
Client wants the lobby tile a shade warmer, within the allowance Revision
Client wants a second-floor terrace that was never in the program Change request
Reviewer asks for clearer dimensions on a sheet Revision
Client asks to swap the structural system after schematic design sign-off Change request
Crit feedback shifts a student’s concept midway through the term Judgment call: record it, and treat it as a change if the brief itself moves

When a client calls something “just a small change,” the table is your test. Ask whether it touches scope, money, time or a deliverable already approved. If yes, it goes on a form.

Design change request vs. engineering change request

The two share a skeleton: a described change, a justification, an impact assessment, an approval and a record. The difference is mostly in what is being controlled. An engineering change request usually targets a released specification, part or manufacturing process, and its approval often triggers verification and validation work. A design change request in architecture, product or digital work more often targets scope, program or an agreed design direction, with the client or a project sponsor as a key approver. Use the engineering style of rigor when a change can affect safety, compliance or built performance, and the lighter style when it is a matter of scope and fees.

When to file one

Official agencies spell out their triggers, and they are a useful model even for a small studio. The New Jersey Department of Transportation, for example, says to submit a Design Change Request during Roadway Plan preparation when a design change appears necessary or desirable. It is required for design-stage scope changes, and for cost increases past set thresholds within a fiscal year: more than $500,000 for design, $500,000 or 10% for right-of-way, or $500,000 or 5% for construction.

Your thresholds will be smaller, but the pattern carries over. Write down your own triggers before the project starts, for example:

  1. Any change to the agreed scope or program.
  2. Any change that adds hours or fees beyond a set amount or percentage.
  3. Any change after a design freeze or a client sign-off milestone.
  4. Any change that alters a deliverable, a consultant’s scope or a regulatory submission.

A supplier-facing example makes the same point from the manufacturing side. Rolls-Royce’s design change proposal guidance says its process applies to changes tied to contractual scope after agreement, and to changes after design freeze, whichever party spots the change first. The lesson: it does not matter who raised it. Once the baseline is set, the process applies.

What a design change request form should include

A form is only as good as its fields. A widely used template lists the project name and number, project manager, requestor, request and resolution dates, a description of the change and the reason for it, the effect on scope, deliverables, time, cost, resources and quality, the decision, and sign-off signatures. That is a good baseline. Here is the same list adapted for a design studio, with the reason each field earns its place:

Field What to write Why it matters
Project name and number Match your fee proposal Keeps the request tied to one baseline
Requestor and date Who asked, when, through what channel Shows where the change originated
Description of change One or two plain sentences The approver should grasp it in seconds
Reason The problem or goal behind it Separates a want from a need
Impact: scope and deliverables Which drawings, models or documents change Prevents silent scope creep
Impact: time and cost Added hours, fee, schedule shift The core of the decision
Impact: resources and quality Who is needed, what risk to quality Surfaces consultant and review needs
Options considered Including doing nothing Makes the decision defensible
Planned activities Checks, reviews or validation after the change Closes the loop on quality
Decision Approved, approved with conditions, rejected, deferred The result, with date
Sign-off Names and signatures of deciders Gives the change formal authority

One template author adds a section for planned activities such as verification and validation. For a small studio this can be as light as “who checks the revised sheets, and by when.”

A short worked example

A client of a small residential studio asks, during design development, to turn the covered porch into an enclosed sunroom. The request form might read:

  • Change: Enclose the rear porch as a conditioned sunroom.
  • Reason: Client wants year-round use for a home office.
  • Impact on scope: New wall and glazing details, updated energy calculations, revised structural sheet.
  • Impact on time and cost: Added design hours and fee, plus a schedule shift for the structural consultant.
  • Options: Enclose now, keep the porch and add the sunroom as a later phase, or do nothing.
  • Decision: Approved with conditions, pending fee acceptance.

Notice what makes it work: nobody has to guess what was asked, why, or what it costs.

How to assess, decide and close a request

The UK Government’s project delivery guidance on change control gives a clean sequence. In its description, teams validate and classify the request, assess the effects on baselines and interdependent work, consider whether the change is necessary or desirable, use evidence and options (including doing nothing), and plan implementation. The decision to approve, reject or defer follows from that assessment. Afterward the register and status are updated, stakeholders are told, approved changes are implemented and monitored, affected documents are updated, and the request is closed.

The same guidance treats change control as governance and traceability: do not decide from an impact you do not fully understand, and escalate anything beyond the responsible manager’s tolerance.

Translated into a studio workflow:

  1. Log it. Give the request a number and put it in a register the day it arrives.
  2. Classify it. Revision, change request, or something that belongs in a later phase.
  3. Pause before reacting. One agency advises a 24-hour rule: wait a day after receiving feedback to confirm what is being asked and why it matters to the business goal.
  4. Assess the impact. Time, fee, consultants, other drawings, risks. Write numbers, not adjectives.
  5. Lay out the choices. Accept now, defer, split into phases, or decline. The same author suggests a change-control meeting with key stakeholders to walk through those choices.
  6. Decide and record. Capture the decision, conditions and date.
  7. Implement and verify. Update the affected documents, then check the work.
  8. Close it. Mark the request closed in the register.

Skipping step 4 is the most common failure. A “yes” given in a meeting before the impact is known becomes a fee dispute three weeks later.

Who approves a design change request

The approver depends on your agreements, but the principle is constant: someone with authority over the baseline signs. Larger organizations layer this. Under the NJDOT procedure, the project manager prepares and submits the request, the Executive Regional Manager reviews it and obtains the DPM Director’s concurrence, and the board then reviews and records its decision. The Assistant Commissioner then concurs with or rejects that decision. Board members can approve all or part of a request, with or without conditions, or reject it. The project file keeps the original request and the signed decision.

A small studio does not need a board. It needs clarity:

  • Who can request: the client, the project team, a consultant, a reviewer.
  • Who assesses: usually the project manager or project architect.
  • Who decides: one named decision owner. A digital agency’s guidance recommends naming a single decision owner with authority to approve budget or schedule shifts.
  • Who must agree on the client side: whoever signs your contract, which may not be the person who sent the email.

For a freelance architect, this often means two people: you assess, and the client signs. Put that in the agreement so a change request is understood as a standing step, not a negotiation tactic.

Keeping the decision and its rationale on the record

A closed form tells you what was approved. It rarely tells you why the team considered three options and chose the second. Six months later, a junior designer asks why the sunroom is glazed on two sides instead of three, and the answer lives in a meeting nobody wrote down properly.

Good change management links the pieces. One UK program’s design change procedure describes formal change records that link the request, the impact analysis, the approved decision and the associated documentation, with status tracking until each change is closed after verification or review. It also mandates a post-implementation review to verify the history of activities and capture lessons learned.

You can adopt a lightweight version of that:

  • Store the request, the decision and the supporting material in one place, by request number.
  • Record the conditions attached to an approval, not just the approval.
  • Note the options you rejected and the reason.
  • After implementation, spend ten minutes asking what the change actually cost compared with the estimate.
  • Link each decision to the conversation it came from: the email thread, the call, the critique.

That last step is where most teams fall down, because the conversation is exactly the thing that never gets filed. Our decision record template articles and our notes on the importance of decision records go deeper on structuring what you capture.

Where change requests come from: the review and feedback loop

Most change requests are born in a feedback moment: a client comment, a design review, a critique, a site call. The request form is the formal end of a much messier conversation. If your reviews are disciplined, requests arrive better formed. A structured review pass, like the one in our three-phase design review checklist, helps separate comments that are revisions from those that change the brief. For the client-facing side, see how we write about the client approval process and design feedback sessions.

Our perspective

We think the change request form is the right tool for the wrong half of the problem. It captures the what: the field values, the cost, the signature. What teams lose is the why. Why did the client really want the sunroom? Which option did we argue against, and what risk did someone flag before we moved on? That reasoning is spoken in meetings and typed in comments, then it evaporates.

Ledger-style project memory is our answer. When a conversation, transcript or critique note is turned into a structured, source-backed record of decisions, design intent, risks, actions and open questions, a change request stops being an isolated form. It becomes a point you can trace back to the exact discussion that produced it.

We built The Intent Ledger for architecture studios, small design teams, freelance architects, project managers and students who need that continuity. A junior designer should be able to open a record and see not only that the scope changed, but who asked, what was weighed and what is still unresolved. In our view, that is what makes a change process a project memory rather than a paperwork habit.

Rajas

Turn the conversation behind each change into a record

If your change requests start in calls, critique sessions and client comments, The Intent Ledger turns that material into ILM Records: structured entries for decisions, design intent, risks, actions, commitments and unresolved questions, each traceable to its source. You can start with a one-off pack, such as the Working Set at $12 or the Project Record at $29, or choose a monthly plan like Working Memory at $29 per month. Compare them on the pricing page, or see the overview on The Intent Ledger.

Theintentledger

Prices are those published on our site at the time of writing. Check the pricing page for what each option includes.

Common mistakes to avoid

  • Verbal approvals. If it is not written and signed, it did not happen when the invoice arrives.
  • One form for everything. Reserve the form for real changes so it keeps its weight.
  • Vague impact lines. “Some additional time” invites disputes. Give hours and dates.
  • No decision owner. Requests stall when three people each assume another will answer.
  • Closing without verification. Confirm the revised documents reflect the approved change before you mark it done.
  • Losing the reasoning. Keep the rationale attached to the record, not scattered across inboxes.

FAQ

What is a design change request form?

It is the document used to propose a change to an approved design and to get it assessed and decided. It records who asked, what changes, why, the effect on scope, time, cost and quality, and the final decision with signatures. NJDOT, for instance, uses one to seek board review of design-stage scope or cost changes.

Who approves a design change request?

The person or body with authority over the baseline being changed. In a large agency that may be a review board with management concurrence. In a small studio it is usually a named decision owner on your side and the contract signatory on the client’s side. Name them in the agreement before the first request arrives.

What is the difference between a revision and a change request?

A revision refines the design within the agreed scope. A change request moves outside that scope and typically affects timelines and costs. If a request touches approved scope, fees, schedule or a deliverable, treat it as a change request.

How long should a design change request take to process?

It depends on the size of the change and your agreement, so set a target in your process, such as a response time for the impact assessment. Allow a short pause to confirm what is really being asked before you commit, then give the approver a clear set of options so the decision does not stall.

How do I keep a record of why a change was approved?

Store the request, impact assessment, decision and any conditions together, and note the options you rejected. Then link the record to the conversation that led to it. Review it after implementation to capture what you learned.

Sources