Change request template for software projects

Published 18 October 2026 · updated 22 October 2026

A change request is a written request to change something already agreed in a software project — the scope, the requirements, the price or the dates — with its impact worked out before anyone says yes. Below is a free template to copy, a filled-in example, a change request log, and the email that asks the client for a decision.

Record everything - don’t trust verbal comms. If a change was requested in a conversation reiterate it in an email back.

— r/projectmanagement, May 2026

What a change request form includes

Change request template

Copy it into Google Docs, Word or your tracker. Square brackets are yours to fill in.

CHANGE REQUEST

No.:            CR-[n]
Project:        [project name]
Requested by:   [name, role], [date]
Changes:        [document], version [x.y]
Decision by:    [date]

1. WHAT CHANGES
   Now:       [what the requirements say
              today]
   Proposed:  [what they should say
              instead]
   Why:       [the reason, in the
              requester's words]

2. WHAT IT TOUCHES
   Requirements:  [sections or ids]
   Built work:    [features, tickets or
                  code already done]
   Tests:         [acceptance criteria and
                  tests to redo]
   Integrations:  [other systems that
                  depend on it]

3. IMPACT
   Scope:   [added / removed / swapped]
   Effort:  [days]
   Cost:    [amount, or none]
   Dates:   [which dates move, and by how
            much]
   Risk:    [what could go wrong]

4. OPTIONS
   A. [as asked]
   B. [a smaller version]
   C. [a swap for something of equal size]

5. DECISION
   Decision:   [approved / declined /
               deferred], option [ ]
   By:         [name, role], [date]
   New version of the requirements: [x.y]

Each approved change request goes into the change log of the requirements sign-off, with the new version it produced.

Change request example

The same template, filled in for a customer portal:

CHANGE REQUEST

No.:            CR-7
Project:        Customer portal
Requested by:   Head of Sales (client),
                3 March
Changes:        Functional specification,
                version 1.2
Decision by:    10 March

1. WHAT CHANGES
   Now:       R-3: customers sign in with
              an email address and a
              password.
   Proposed:  R-3: customers sign in with
              an email address and a
              password, or with a Google
              account.
   Why:       "Half our customers ask why
              they need another password."

2. WHAT IT TOUCHES
   Requirements:  R-3 sign-in, R-9 account
                  deletion
   Built work:    sign-in page and
                  sessions (done)
   Tests:         R-3 criteria 1-4; R-9
                  criterion 2
   Integrations:  Google sign-in, to set
                  up

3. IMPACT
   Scope:   added
   Effort:  4 days
   Cost:    3,200 EUR (4 days at the SOW's
            day rate)
   Dates:   release 2 moves from 28 April
            to 2 May
   Risk:    an existing customer signs in
            with Google and gets a second
            account

4. OPTIONS
   A. Google sign-in, as asked: 4 days,
      3,200 EUR.
   B. Google sign-in for new customers
      only: 2 days, 1,600 EUR. No release
      date moves.
   C. Swap it for the PDF invoices in
      R-14, which have not been started:
      no change to cost or dates.

5. DECISION
   Decision:   approved, option B
   By:         Head of Sales (client),
               7 March
   New version of the requirements: 1.3

Account deletion (R-9) is the part nobody would have asked about — a customer who signs in with Google has no password to confirm before deleting the account. That is what “what it touches” is for.

How to assess the impact of a change request

1. Find what it touches. The requirements it changes, and those that depend on them; the work already built on them; the tests and acceptance criteria that check them; the integrations behind them. In one r/webdev thread, reordering a checkout form would have broken a CRM integration that “mapped fields by position, not name”.
2. Size the work, including what has to be redone and tested again — not only what is new.
3. Turn it into money and dates. Effort becomes cost at the rate in the contract; the dates move unless something else comes out.
4. Name the risk. What could go wrong if it is done, and if it is not.
5. Offer options. As asked, a smaller version, or a swap for something of equal size.

For a larger change, the change impact analysis template and example go through each of these in detail.

Change request approval process

1. Log it the day it is asked, even when it was asked on a call — and send it back in writing.
2. Assess it with the steps above, and fill in the template.
3. Send it for a decision, with a date — the email below.
4. Record the decision: approved, declined or deferred; by whom; when.
5. Update the requirements to a new version. The version signed before stays readable — the requirements baseline.
6. Build, test and accept against the new version, not against the email that started it.

The whole process, with one change followed from request to new version, is in requirements change management.

Who may approve is best written into the contract or the statement of work before the project starts. On larger projects a change control board often decides; on a small project it can be one named person on the client’s side, with the delivery lead. A commenter who has “been doing this for 30 years” ties it to milestones:

When they sign off of the milestone, everything up to that point gets locked in. If they want to change it, that’s when you break out the change orders.

— r/webdev, March 2026

The process step by step, and what it can borrow from a pull request: change request vs pull request.

The email that asks for a decision

Subject: Change request CR-[n]: [summary],
         decision by [date]

Hi [name],

You asked for [change] on [date]. The
change request is attached: [link]

In short:
- It changes [requirements], version
  [x.y].
- It adds [n] days and [amount], and moves
  [milestone] from [date] to [date].
- It also touches [what else is affected].

Three options:
A. [as asked]
B. [smaller version]
C. [swap]

Reply with A, B, C or "not now" by [date].
Nothing on this change starts until you
do.

Thanks,
[name]

It puts the question one commenter asks instead of saying no: “Do you accept that it’ll impact price and deadlines?” (r/webdev, June 2026). The first reply to the request, before the change request is written, is on the scope creep page.

Change request log template

One row per request, approved or not. What each one touches stays in the change request itself; what each approved one changed in the requirements goes in the change log; decisions that are not changes go in a decision log.

The log is what lets you answer “why did it cost more?” at the end — and it works best when the client sees it:

Document all of the change requests that the project manager has accepted, estimate the effort required to deliver those changes and put a dollar value to it. The dollar value is extremely important.

— r/projectmanagement, August 2024

One commenter’s habit: “Weekly client status meetings with an out of scope(OOS) slide,” kept “in the presentation even if there aren’t any OOS request so the client is reminded that it’s a thing and that you’re tracking it” (r/agency, 2021).

Change request, defect or new requirement?

Not everything a client raises is a change request:

The test is always the same: compare it with the version that was signed. That is why a change request names one.

Change request vs enhancement, user story and feature request

In a product team with a backlog, enhancements and feature requests wait in the backlog until the product owner picks them. On a client project, the same ideas become change requests the moment they would change what the client signed — because someone has to agree the cost.

A change request also changes the documents. Asked “Does a change request change the requirement specification?”, one answer on Project Management Stack Exchange was simple: “If the change makes anything in the document incorrect, then update the spec” (Project Management Stack Exchange, 2013). And a story that is already agreed does not quietly absorb the change: “If you change this story, this will induce a scope change of the original story,” as the accepted answer to “Is a new change request on a user story a different user story” put it (Stack Exchange, 2014). More on handling them in how to handle changing requirements.

Change request vs change order

A change request is the ask; a change order is the signed amendment to the contract that follows, with the new price and dates. Some teams use the two words for the same thing. More in change request vs pull request.

Where Specroot fits

This is the problem Specroot works on: a change kept apart from the signed-off requirements until the client approves it, with what it touches shown before the decision. Specroot for agencies and consultancies.