Project change requests: how to document one after a call
Turn a client request into a change request with the reason, difference from agreed scope, impact, and decision. Includes an example and template.
Distinguish clarification from new scope
“Let’s add a filter” sounds small, but it may affect data, permissions, and testing. Find out whether the client is clarifying agreed behavior or requesting a different result.
A change request keeps the decision from getting lost in the discussion. A short card linking the proposal, assessment, and approval may suffice for a small project. The contract remains a separate source of commitments.
Understand the request before promising a date
Keep the original wording
Find the point in the recording and note the problem the person wants to solve. If they suggest a button, ask for an example of an action they cannot take today. Name the requester and the version under discussion.
Compare with the original agreement
Put the agreed and proposed versions side by side. State the concrete difference. If the behavior was already promised, it may be a fix. Check the documents.
Assess what is affected
Ask the team to review data, interface, integrations, tests, and support. Mark time and effort as estimates with assumptions until agreed. List what information would make the estimate firm.
Record the decision and its consequences
Set a status: clarifying, estimating, approved, deferred, or rejected. Once approved, update the related plan and test criteria. Keep the previous version to show what changed and why.
Filtering a report by branch
This fictional example uses names, conditions, and outcomes solely to illustrate the method.
The report currently covers the whole company. We want to select a branch and keep the overall view. Some older requests have no branch recorded.
The request affects more than the interface. Decide how to display records without a branch and how to handle the company-wide total.
Until you clarify blank values, you cannot promise that adding a list is enough. A separate card keeps that condition visible after the call.
| Item | Details | Status |
|---|---|---|
| Reason | Need a separate branch view | Confirmed |
| Retain | Company-wide report | Include in testing |
| Clarify | Rule for requests without a branch | Open question |
Change request card
Use this template to discuss scope alongside your company’s approval process.
Change and requester: Reason and example situation: Current agreed behavior: Proposed behavior: What is retained: Data and processes affected: Estimate and assumptions: Open questions: Decision, decision maker, and date: Documents updated: How to check the result:
Make sure the decision can be traced
- The request is compared with the previous scope.
- The estimate is marked as preliminary.
- The decision has an authorized owner and date.
- Approval updates the work plan as well as the card status.
A closer look
Does every clarification need a change request?
No. Draw a clear line around changes to the result, timing, cost, or significant conditions. If the project rules allow it, record small wording clarifications in the log.
What if people remember the discussion differently?
Review the recording and agreed documents. Show the relevant passage and ask participants to confirm its meaning. Discuss interpretations before choosing one.