An outsourced project change request should explain what changes in the agreed work, what that affects and who can authorise the trade-off. The new request may be worthwhile. The team still needs a common understanding of whether it adds work, replaces something already planned or corrects a deliverable that did not meet the existing agreement.
That distinction affects people as well as budgets. A remote specialist can appear late when a manager has inserted new work without moving the deadline. A business owner can feel surprised by an extra estimate when they thought the request clarified the original brief. A reviewable change note gives both sides a shared object to discuss.
Identify the brief, agreed outcome or acceptance criteria the request relates to. Use the relevant version and decision record. If the baseline itself is ambiguous, name the ambiguity before presenting an apparently precise estimate. The first task may be to clarify the agreement rather than to price additional work.
For an illustrative reporting project, a request to add a regional breakdown could be new scope, an agreed requirement that was missed or a refinement within an existing allowance. The words in the latest message do not settle that question by themselves. Compare the request with the agreed brief and discuss the intended treatment with the authorised people.
The UK Government’s guidance on user stories connects acceptance criteria to the outcomes that demonstrate a user need has been met. That is useful when defining a baseline: a clear outcome makes it easier to discuss whether a later request changes the expected result. The project’s own commercial agreement still governs its terms.
Ask what the requester needs to do differently once the change is complete. “Add another export button” specifies a possible solution. “Allow the operations lead to send only approved regional records to the partner” describes a need that design, data and access decisions may all affect.
Keep the request understandable to the person making the business decision. Include enough detail for the delivery team to investigate, but avoid turning the decision note into an implementation log. Link supporting material where necessary. A requester should be able to recognise their intended outcome and correct any misunderstanding before work begins.
A useful change record names the request, its reason, the baseline affected and the proposed acceptance outcome. It also distinguishes confirmed requirements from assumptions and open questions. This gives the estimate a visible foundation instead of hiding uncertainty inside a single number.
Ask the delivery team to identify affected tasks, dependencies and reviews. A change to one report may require new source data, revised calculations, a different permission rule and another acceptance check. Those consequences should be considered before the team commits to a date.
Explain the available choices in practical terms. The business might add budget and preserve the original scope, replace a lower-priority deliverable, stage the new outcome or defer the request. Each option should state what the requester would receive and what would move. Avoid suggesting that reprioritisation is free when another commitment is being displaced.
Use estimate ranges or explicit assumptions where the information does not support a fixed figure. Separate investigation from delivery when the team first needs to establish feasibility. Identify the point at which a refined estimate will be available and who decides whether to proceed after that investigation.
The agreement for outsourced project support should name who can approve scope, cost and timing. A helpful colleague may be able to explain the need without being authorised to commit the business. The team should know how to obtain the decision without asking every contributor to interpret commercial authority.
Record the decision, its date and the scope it covers. If approval is conditional, state the condition in usable terms. An illustrative note might approve a defined investigation allowance while reserving the delivery decision until the findings and revised estimate are reviewed. It should not be described as approval of the whole feature.
Where a decision is pending, identify the affected work and the next action. The team can continue other agreed tasks that do not depend on the unresolved choice. This keeps progress understandable without allowing a vague request to alter the project informally.
Once approved, update the relevant brief, priorities and acceptance criteria. Tell the people whose work changes, including reviewers and downstream users. An approval stored only in a message may not reach the colleague maintaining the delivery plan.
At acceptance, compare the delivered change with the approved outcome and retain the relevant evidence. If another request emerges, relate it to the updated baseline. This preserves a coherent history instead of a chain of overlapping messages that nobody can confidently interpret later.
When a request waits for a commercial decision, keep that dependency visible in planning. The guide to decision delays and capacity gaps helps distinguish an unanswered choice from a shortage of delivery hours.
The next change decision can be concise: identify the baseline, describe the revised outcome, show what would move and record the authorised choice. Scale the review to the consequence of the request. A small adjustment may need a short note; a consequential revision needs enough evidence for both sides to understand the cost, timing and unresolved assumptions before work is reassigned.