A client’s project scope change needs a record of the difference and a decision about implementation. Separate receiving an idea from approving additional work. Compare the new need with the agreed outcome, explain its impact and give the team an unambiguous execution scope.
Compare the request with the latest agreed scope first
A team is preparing three pages in Polish when the client requests a second language. “Let us add German” is short but may involve content, navigation, a form and review of the new view. Do not add it as a minor correction before establishing scope. A brief message does not necessarily mean a brief piece of work.
Check the latest agreement: page count, language, elements and required outcome. Do not rely only on the initial plan if later changes were approved. Boundaries are easier to preserve when the first days working with a client leave clear agreements. Their current state is now the reference for deciding what the new request changes.
Not every new message adds scope. Correcting an inaccurate amount may bring work into alignment with the agreed result. Another language may be a separate need. Small corrections like this are easier to assess together when the client sends them in agreed review rounds with one feedback list.
Distinguish them by the outcome, not whether the client calls it a “fix”. The purpose is shared clarity rather than winning an argument over the name of the request. After launch, the same principle separates maintenance work from new jobs, as the guide to client requests after a website launch shows.
Record the change in five concrete fields
A simple card should let someone absent from the conversation understand the request without guessing. Include the current scope, new need, impact, options and decision.
“German version” alone is insufficient. Identify where content comes from and which elements the client actually wants changed, including uncertainty that must be resolved before implementation is accepted.
Scroll the table sideways to see all columns.
| Field | Example record |
|---|---|
| Current scope | Three identified Polish pages with an agreed form. |
| New need | German equivalents of the pages, navigation and form. |
| Required input | The client will supply approved translations; they are not yet available. |
| Impact to assess | Additional content, layout, link checking and publication. |
| Decision | Proposal awaiting option selection and scope confirmation. |
Record: “Change request: German versions of pages A, B and C and agreed form elements. Reference: we are currently delivering these pages in Polish. Input: translations need to be supplied and approved. We will assess the option and sequence impact before implementation. Recording the request does not yet mean additional scope has been accepted.”
If the client wants one page, do not automatically extend the card to the whole site. If they need the complete flow, do not describe it as one text. The boundary should include relevant visible elements not previously specified. Name missing scope details before estimating impact; an apparently clear language title can conceal several separate outcomes.
Assess work, inputs and sequence instead of guessing a date
A second language can require label lengths, links and available content to be adjusted even when page structure is similar. Check actual work with the performer. Do not present an automatic multiplier as a completed estimate or date. This assessment approach is a proposed process rather than an estimating feature supplied by the tool.
- Describe the new outcome.Identify pages and elements of the new version. Separate content from behavioural changes so another form is not hidden inside translation.
- Check required inputs.Establish who supplies and approves texts. Missing translations change start readiness even when the technical work is simple.
- Compare the work sequence.Check whether the change interrupts started work or requires another review. Do not move the agreed outcome without explaining that difference.
- Prepare available options.Describe joint delivery, a separate stage or a scope swap when actually feasible. Do not offer an option before checking it can be performed.
“Polish first, German separately” may preserve the original outcome but needs an explicit decision. “Both together” may change sequence and input requirements. Neither is automatically approved.
The guide to task dependencies explains connections between elements. A missing input can prevent an option from starting even when the client prefers it.
Present the change so the client can choose
Before a decision: “We recorded the request for German versions of A, B and C. The current scope covers the Polish versions. The new option also requires translations and checks of form elements. We will assess impact and available delivery approaches. Receiving the request does not yet change the scope the team is implementing.”
With options: “We can preserve the Polish stage as the current result and plan German separately, or revise the joint scope after confirming impact. Both require approved texts. Please select after reviewing the particular option conditions. Until a decision, we are implementing the existing agreement.” Adapt this to genuinely available options rather than presenting hypothetical routes as offers.
Do not confirm with “we will do everything”. The client needs a list of included elements and the remaining boundary. For a scope swap, identify what leaves and enters.
“German added instead of page D” differs from adding a language while retaining every existing page. The decision should make that trade clear to the team as well as the client.
For an urgent request, gather information promptly without skipping the decision. Starting first can imply acceptance of the entire idea.
B2B customer support covers organisational communication; here the conversation should produce a particular scope choice. Speed in responding does not itself establish what the team is authorised to deliver.
Preserve the decision rather than silently replacing the agreement
After confirmation, record the new scope, inputs, start conditions and impact established with the team. “Accepted” alone is insufficient. Another person needs to know the chosen version.
Approval to investigate is not implementation approval, and confirmation of one page does not automatically include every other element. Each statement should match the decision’s actual scope.
If the client declines or postpones the proposal, retain the existing scope. Preserve request context without presenting it as active work. Example: “The additional language was not accepted into this stage; the earlier scope remains in progress. We can return to the request after separate agreement.” Do not imply an unselected future delivery date through a polite closing sentence.
This article does not establish contractual or billing terms. It concerns operational needs and decision records; use the appropriate route for binding matters. The guide from request to task helps translate the confirmed conversation outcome into work while preserving its source and boundary. A task entry should follow the decision rather than manufacture it.
Connect the request and decision with the relevant task
In Meetlead Projects, descriptions, comments and task links preserve scope and subsequent agreements. Owner and status show team work. You need an account, website, permissions, active Projects installation and a plan with access. The responsible person manually records the agreed decision outcome; the application does not decide the new scope on their behalf.
The tool does not automatically obtain client approval, create a quote or establish a binding new date. A comment is a record rather than a signed amendment. When another task is needed, link it to the context through the actual process. Do not suggest an approval portal the team does not have; use the verified description and conversation instead.
- The request was compared with the current agreed outcome.
- New scope identifies elements rather than only a title.
- Required input sources are known.
- Impact was checked before implementation was promised.
- The decision distinguishes investigation, acceptance and postponement.
- Tasks reflect the selected option.
When a request arrives halfway through work
Does every correction change scope? No. Compare it with the agreed outcome. Fixing a mismatch may belong to current work, while a new element may require a separate decision.
The word used in the message does not determine that distinction. Establish what changes for the actual recipient instead of arguing about terminology.
Can an idea be investigated before approval? Yes, if investigation scope is clear. Do not present it as implementation already underway.
The client should understand that they will receive a decision basis rather than a delivery promise. The team also needs to know where that limited investigation ends.
What if no definite choice follows the discussion? Ask for confirmation of the particular option and record the remaining state.
Do not change tasks based on silence or a generic “sounds good”. Further work needs a clear scope, including whether the earlier agreement continues while the new request awaits a decision.
Atlassian describes uncontrolled expansion of project scope. The card and messages here are our proposed practical records: project scope and uncontrolled changes.
