A change request lands on Tuesday. The customer’s engineer agrees in a call. Nobody writes it down. On Friday the project lead asks whether it is approved, and three people give three answers. Someone sends a reminder. It changes nothing, because nobody knows who the reminder should go to or what exactly is being approved.
This is a common scramble for forward-deployed engineers (FDEs) working inside a customer’s process. The fix is rarely a better reminder. It is a scope approval that works as a defined workflow: a named owner, a clear request, a recorded decision and a visible next step.
Why reminders do not fix scope approval
A reminder assumes the approval is well defined and only late. In practice the delay can come from something earlier. The request is vague, the approver is unclear, the evidence is scattered across email and chat, or the person who can decide is away.
- Reminding the wrong person adds noise and no decision.
- Reminding about a vague request produces a vague answer.
- Reminding without a deadline or fallback means the request waits as long as before.
Treat the approval as a process step with inputs and outputs, and a reminder becomes one small part of it.
What a scope approval needs to be a workflow
Each scope change or sign-off request should carry the same few fields, whatever tool holds them.
- What changes: one sentence on the requested change, and what it replaces or adds.
- Why it matters: the effect on deliverables, effort and acceptance tests.
- Who decides: one named approver on the customer side and one on your side. A team is not an approver.
- Evidence: the document, message or call note where the request came from.
- Decision options: approve, reject, or approve with changes, so the answer is never just “looks fine”.
- Needed by: the date after which the work is blocked, and what happens if no decision arrives.
A request with these fields can be answered in one reply. A request without them starts a conversation.
Route by who can decide
Not every change needs the same approver. A wording fix in an acceptance test is not a budget change. Decide the routing before the first request, and write it into the project plan: which kinds of change go to which owner, and who covers when that person is unavailable.
An unavailable approver can block the workflow. A named backup, agreed in advance, keeps a request moving. If no backup exists, the request should say so and go to the sponsor.
Start from the project scope statement
Every approval decision is measured against something. On many projects that is the scope statement and the project deliverables agreed at kickoff, often broken down in a work breakdown structure, as PMI describes. When that baseline is vague, every request looks like a small change and scope creep goes unnoticed. Before the project manager asks anyone to approve a change, the team should be able to say which deliverable, project goal or part of the project timeline it touches.
Run an impact assessment on every request
A short impact analysis is the step most teams skip. For each change request, note the effect on the project scope, the project schedule, the budget and the open risks, and flag possible budget overruns early. Keep it to a few lines. An impact assessment should give the approver facts, not a long report, and it supports clear stakeholder communication about what moves if the answer is yes.
When you need a change control board
Small projects can run the change control process with one named approver. Larger ones may use a change control board, a small group that reviews each change request on a fixed day. Either way, consider keeping a change register that lists every request, including the rejected ones. A rejected request is still useful: it shows the pattern of change, and it protects the team when the same ask returns later.
Change management is more than approval
Approval is one step of change management. After a change is approved, the project manager still has to update the baseline, tell the people who work from it and check that the acceptance tests match. Agile teams often do this in backlog review rather than in a formal board, but the same questions apply: what changed, who agreed, and what moved as a result. Project success depends on that follow-through more than on the speed of the sign-off.
Scope creep and scope change are different things
A scope change is a decision. Scope creep is what happens when changes arrive without one. PMI’s paper on scope creep makes the same point: the key part is whether changes are authorized, and an approved expansion of scope is not scope creep. A scope change can go through a change control process: it is requested, assessed, approved or rejected, and logged. Scope creep is the pile of small, unrecorded requests that nobody approved. A project manager can help stop the first from turning into the second. Every scope change should be visible to the whole team, and every case of scope creep should be caught the first time it appears and turned into a proper change request.
Risk management and scope change management
Scope change management belongs to project management and to risk management. An unapproved scope change is a risk to the schedule, the budget and the relationship with the customer. A simple risk management habit helps: at each project review, ask which open change requests could move the project timeline, and which approvals are waiting on a single person. Project managers who track scope change management this way spend less time defending past decisions and more time on delivery.
Common mistakes in project management of scope changes
Four mistakes are worth avoiding in project management. The first is approving scope changes in a call and never logging them. The second is letting the project manager be the only person who knows the scope statement. The third is treating every request as urgent, so the change control process gets skipped. The fourth is approving a change without checking its effect on the work breakdown structure, so a task is added and nothing is removed.
For an FDE the same mistakes cost more, because the work sits inside the customer’s systems and the customer’s project management habits. Ask early how the customer’s project manager handles a scope change, who owns the project scope on their side, and how project deliverables are accepted. Matching their change control process is usually faster than introducing your own.
What good looks like for a project manager
A project manager who handles scope change well can answer five questions at any time: what is in the current scope statement, which change requests are open, who must approve each one, what each would do to the project timeline, and which approved changes are not yet reflected in the plan. If those answers live in one place, the project manager can run a weekly review in minutes, and risk management becomes a routine check instead of a surprise.
Stakeholder communication keeps scope changes honest
Most disputes about scope are really disputes about what people were told. Good stakeholder communication means that everyone affected by a scope change hears the same summary: what changed, why, what it does to the project schedule and budget, and who approved it. Send that summary when the decision is made, not at the next status meeting. This keeps the project goals visible and helps avoid budget overruns that surprise the sponsor late in the project.
Fixed scope and agile approaches
The same ideas apply whether the project runs on a fixed scope or on agile approaches. On a Scrum team, the Scrum Guide makes the product owner accountable for effective Product Backlog management, so record a scope decision wherever the team’s agreed process already tracks backlog changes. On a fixed-scope project, a baseline control step can do the same job: the baseline changes only through an approved change request. In both cases, the project management question is the same. Who decides, and where is the decision written down?
Whatever the method, match the approval path to the size of the change. A small wording fix should not wait for a board. A change that adds a deliverable or moves the project timeline should not be approved in a hallway. Writing those two rules down in the project plan removes most of the arguments before they start.
Tie the project scope to the SOW
For an FDE, the statement of work is the written form of the project scope. Treat it as the scope statement for the engagement: it lists the project deliverables, the boundaries and the acceptance criteria. Each approved scope change should produce a small amendment or a dated entry in the change log, so the SOW and the actual project scope never drift apart. When a project manager on the customer side asks what is in scope, the answer should be one document, not a search through emails.
Good project management practice here is plain: one scope statement, one change control process, one change register, and one person who keeps all three current.
Change control without the paperwork
Scope creep usually starts as a small favor. A change request process stops it by asking the same questions every time: what is being asked, who benefits, what it costs in time and effort, and who signs off. Project managers call this change control. It does not need a heavy form. A short change request template with the fields above is enough, as long as every request uses it and every stakeholder knows where requests are logged.
Keep the cost visible. A change that looks free in a call can move the acceptance date or push out another deliverable. Writing the effect on the timeline next to the request gives the approver something concrete to approve, and gives the team a clear way to say “yes, and here is what moves”.
Record the decision where the work happens
An approval in a call or a chat is a signal, not a record. Capture the decision in the same place as the scope document, with the date, the approver and the exact wording. Then update the statement of work (SOW) or the change log, and link the evidence.
This also protects the customer. Six weeks later, nobody has to rely on memory to know what was agreed.
A synthetic example
This example is invented for illustration. A team is building a quoting workflow for a distributor. Mid-project, the customer asks for a second approval step on orders above a set value.
- The request is logged with the fields above. The approver on the customer side is the finance manager. The backup is the operations director.
- The finance manager is travelling, so the request routes to the backup after two working days, as agreed in the plan.
- The backup approves with one change: repeat orders at an unchanged price skip the second step.
- The change log records the decision, the date and the evidence. The workflow specification gains a routing rule, an exception and a test case.
Nobody sent a chase email. The process moved because the route was already defined.
Where tooling helps, and where it does not
A workflow tool can hold the fields, route the request, keep the evidence attached and record the decision. DigiBull AI’s BuLLM is an FDE acceleration platform; it is worth evaluating on whether it keeps the request, the approver and the decision connected in one record. Check any capability on a real workflow before relying on it.
No tool can decide who the right approver is, resolve a disagreement between two managers or make an unavailable person respond. Those are agreements the team has to make with the customer early.
A short checklist
- Every scope request has a one-sentence change, an owner and a needed-by date.
- Routing rules and backups are written down before the first change.
- Evidence is attached to the request, not left in a chat.
- The decision is recorded with date, approver and wording.
- The SOW, change log and acceptance tests are updated after each decision.
- Requests with no decision by the needed-by date follow the agreed fallback.
To test this on your own project, take the last scope change that stalled and map where it waited and why. We can review that with you and show where a defined approval path would have helped. Book a Process Transformation Audit to start with one workflow.
