Software Change Request Template: Four Delivery Decisions

A software change request template records what a client wants to change, how it affects the agreed work, and who decides. Use the copyable template below to assess a request before committing to it. The worked example follows one CSV export request through approval, decline, deferral and a scope swap.

Keep the request beside the scope version it changes. When someone later asks why a feature moved, the record should identify the decision and the acceptance criteria that followed it.

Compare the request with the agreed scope

A client asks for an export button on the orders screen. Before estimating it, open the agreed specification. If export was included and fails its criteria, record a correction. If the specification leaves the behavior unclear, clarify it with the client. If export adds a capability outside the agreement, assess the proposed change.

The Association for Project Management describes change control as recording and evaluating proposed baseline changes before a decision. Its guidance includes assessing effects on scope, time, resources and risk. For a software team, the baseline can be an approved specification and its acceptance criteria.

Write down the relevant section and version. A link to a document that keeps changing leaves the reviewer guessing what the team had agreed.

Copy the software change request template

Use one record for a decision that can be reviewed together. Complete the assessment before asking for approval. If a dependency is unresolved, say what must be checked and who will check it.

Download the editable Markdown template, or copy the text below into your tracker or shared document. The download also contains the fictional CSV example.

SOFTWARE CHANGE REQUEST

Request ID / revision:
Project / requested by / request date:
Decision owner / decision needed by:

AGREED BASELINE
Scope document / version / section:
Existing deliverable and acceptance criteria:

PROPOSED CHANGE
Requested outcome:
Add or change:
Remove, if proposing a scope swap:
Keep outside this request:

IMPACT ASSESSMENT
Affected screens, data, permissions and interfaces:
Implementation, testing and documentation effort:
Dependencies / unknowns / assessment owner:
Commercial impact / agreement reference:
Current delivery commitment:
Proposed delivery commitment / assumptions:

REVIEW CRITERIA
Proposed acceptance criteria and exclusions:
Expected review evidence / client reviewer:

DECISION
Approve / decline / defer / approve scope swap:
Exact request revision and selected option:
Decision maker / date / response reference:
Conditions or reason:
Revisit trigger and owner, if deferred:

DELIVERY HANDOFF
Revised scope and acceptance criteria version:
Linked implementation work / delivery owner:
Submitted build or commit / review evidence:
Acceptance outcome / reviewer / date:

Keep commercial terms tied to your agreement. If you record a fee or a credit in a real request, identify what it covers and the condition for starting work. The fictional example below uses effort and scope assumptions only.

Work through a CSV export request

The project is a wholesale order portal. Scope S3 includes an orders list, status and date filters, plus saved filter presets. Staff can see orders only for their own organization. Export is outside S3.

The client's operations lead asks for a CSV to prepare the weekly order report. The delivery lead records CR-014 revision 1. The client owner has decision authority; the operations lead will review the result.

Bound the export before estimating it

The proposal exports orders matching the current date and status filters. It includes order ID, order date, status and total, capped at 5,000 rows. Customer contact details, scheduled exports and accounting integrations stay outside the request.

That boundary leaves several questions for the team to assess:

• Does the export enforce the same organization and role permissions as the orders screen?
• Which date boundary and time zone determine the rows?
• How does the application handle a result above the row limit?
• What tests and reviewer instructions need to change?

For this example, assume the team estimates two working days for implementation, one for testing and half a day for documentation and review preparation. That is 3.5 person-days of effort. The delivery date still depends on reviewer availability and other work; effort alone does not establish a calendar commitment.

Make the review observable

CR-014 revision 1 proposes these acceptance criteria:

1. With a prepared set of orders, the export contains exactly the rows matching the selected date and status filters.
2. An authorized operations user receives the four agreed columns. A role without export permission cannot download the file.
3. A prepared cross-organization test returns none of the other organization's orders.
4. An empty result produces a file containing column headers only. A result above 5,000 rows shows a message asking the user to narrow the filters.
5. The review package identifies the tested build and includes a sample file, filter settings and expected row count.

These criteria make the proposed boundary reviewable. An implementation team must still assess file handling, security and operational requirements before treating the example as a complete engineering specification.

Record one of four delivery decisions

The following are alternative outcomes for the same request. Only the selected outcome belongs in the project's active commitment.

Approve the additional work

The client owner approves CR-014 revision 1, including its criteria and a revised review date. The delivery lead creates scope S4, preserves S3 and links the implementation work to the decision. Saved filter presets remain included.

Record any commercial agreement before starting. An approval that mentions the feature but leaves its timing unresolved still needs clarification.

Decline and retain the baseline

The client owner declines CR-014 revision 1 because the report is outside the current project's priorities. Scope S3 remains active, including saved filter presets. Record the reason and keep the request accessible so the team can explain why export was omitted.

Defer with a revisit condition

The client owner defers the export until operations has reviewed a manual reporting cycle. Scope S3 remains active. The operations lead owns the follow-up and will provide the required fields and expected row volume after that review.

Keep the request outside committed delivery until a later decision approves it. On reopening, reassess capacity and dependencies before offering a date.

Approve a scope swap

The client needs the export before launch and can defer saved filter presets. The delivery lead prepares CR-014 revision 2: add the bounded CSV export and remove saved filter presets from this release.

The team compares the remaining effort and dependencies for both features. A swap requires a fresh assessment even when the initial estimates appear similar. Work already spent on presets cannot be recovered by removing them.

If capacity and dependencies support the swap, the client owner approves revision 2 and its review date. Scope S4 includes the export criteria and explicitly removes the preset criteria. Basic date and status filters remain. Record deferred presets separately, with an owner and revisit condition.

Do not attach this decision to revision 1: that revision added export while keeping presets. The selected revision tells the developer and reviewer which combination was approved.

Carry the approved revision into delivery and acceptance

Continue with the scope-swap outcome. The delivery record links CR-014 revision 2, scope S4 and the work implementing the export. The reviewer receives build B17, the test results and a sample CSV produced from the agreed test data.

Suppose B17 exports all orders, ignoring the selected status filter. Record a failed criterion and request a correction. The approved export behavior already requires that filter; this example needs a fix against S4.

The team submits build B18 with revised evidence. The reviewer checks the export against the same criteria and records the acceptance outcome for B18. Preserve B17's failed review alongside the correction so the next person can follow what changed.

If the client then requests customer email addresses in the file, assess that request separately. It changes the approved columns and requires another look at permissions and data exposure.

Use your existing tracker when the record stays clear

A tracker ticket and an attached decision can hold this workflow. That may be enough when the client can review the request, the team preserves the scope revision, and the delivery owner keeps the links current.

Before asking anyone to adopt another platform, try the template on one actual request. Check whether the developer and client reviewer can identify the selected option and the same acceptance criteria from that record.

ProjectHubs is being developed around connected delivery work, client decisions and human approvals. Read the product overview for that direction. The example above is a workflow you can use in your existing tools; available product capabilities need to be confirmed in a walkthrough.

Bring one client change request to a ProjectHubs walkthrough. Use the request and the completed template to discuss where the decision or review record becomes difficult to follow.