Sprints and planning · Taskending editorial team
How to manage a project change request: example and template
A change request proposes a different scope or delivery condition for agreed work. Recording it does not approve it. A useful process makes the expected benefit and impact on existing commitments visible before a decision is made.
Updated: · 3 min read
Separate defects, clarification and new scope
If an agreed acceptance condition is not met, the issue may be a defect or incomplete delivery. Behavior that was never agreed may represent new scope. Clarifying an ambiguous sentence can either explain the existing agreement or reveal additional work. Do not decide solely from the request’s label. Write the existing condition and requested difference side by side first.
Describe the intended outcome
Who wants the change, why do they need it and which workflow improves? Is there a real deadline? Is the proposed implementation the only option? “Let a regional manager isolate their own orders” may expose a smaller solution than “Add three report filters.” Collect the information needed for a decision; a large document is not automatically more useful than a clear short request.
Compare options and impact
Describe scope, capacity, dependencies, testing and communication separately. In a fictional example, a team has eight unallocated hours and the first estimate for a request is twelve hours. Instead of silently converting the four-hour gap into overtime, consider removing another item, narrowing the solution or deferring it. State uncertainty in the estimate. These numbers support a decision; they are not a guaranteed delivery promise.
Record the decision and reason
The decision owner can accept, reject, defer or request more investigation. Record the date, rationale, affected work and condition for reconsideration. A deferred request needs a review date or trigger so it does not wait forever without explanation. Keep the earlier assessment discoverable when the request returns. If your organization has a formal approval policy, apply this general workflow within that policy.
Update the plan after approval
Create a separate change issue in Taskending and link affected work. Once accepted, update descriptions, acceptance conditions, sprint or release assignments and realistic dates together. Inform owners of dependent work. Closing the request itself does not automatically change earlier delivery commitments or notify every stakeholder. Verify that the people relying on the old plan can see the new one.
Learn why changes happen
At the end of a period, distinguish changes caused by missing initial information, new needs and external dependencies. The goal is not to prohibit change but to understand repeated surprises. Adjust the amount of documentation to the size and consequences of the decision. A workflow useful for one project should not become mandatory overhead for every small task.
Change request and decision record
| Field | Information to complete |
|---|---|
| Existing agreement | [Related issue and acceptance condition] |
| Requested difference | [New outcome and reason] |
| Impact | [Scope, capacity, testing, dependencies] |
| Options | [Narrow / replace other work / defer] |
| Decision | [Owner, date and rationale] |
| Updated plan | [Affected issues, communication and review date] |
Recording a request does not approve it. Update the plans of affected issues after the decision.
Download template (.md) ↓Free. No registration needed. Use it in a text editor or an issue description.
Try it in your own workflow.
Create a company workspace and your first issue. Taskending is currently free.
Start for free