Decide New Requests After Your First Build Scope Is Agreed

1. Start with an agreed boundary, not a new wish list

Suggested workflow practice: use this guide after the business owner and implementation partner have already agreed the first build. Its task is not to choose software, collect initial requirements or write the first scope. It is to decide what happens when a new request arrives while that agreed work is being built or tested.

Bring the dated agreement and the acceptance checks that already exist. Do not reconstruct them from memory or quietly replace them with today's preference. If a boundary was never agreed, record that uncertainty and ask the responsible people to resolve it before classifying a request as included or excluded.

A request can be useful without being part of the current agreement. Separate those questions. First ask which existing acceptance check is affected; then ask whether the request changes the agreed work. Keep the current build unchanged while a decision is pending unless the accountable people explicitly decide otherwise.

The decision log below is a suggested operating aid, not a contract, legal interpretation or promise about delivery. Use the actual agreement to settle commercial obligations; seek suitable professional advice for disputed terms. This article does not determine pricing or impose a universal approval process.

2. Make each incoming request traceable

Suggested workflow practice: assign one reference to each incoming request. Record who asked, when it arrived, the operational problem, the exact agreed item affected and the requested difference. Link to the relevant agreement version rather than copying a scope summary that may become inconsistent.

Use a before-and-after sentence: the agreement currently allows this action; the request would add or change that action. Avoid a feature name without a behavioural difference. If the requester cannot identify the difference, mark the record awaiting clarification rather than accepting it by default.

Keep proposed and decided fields separate. The requester can explain the need, but the recorded decision must identify the accountable decision maker, the decision date and any explicitly agreed update. A message saying an idea sounds useful is not the same as approval to change the build.

• Request reference, requester and received date.
• Problem observed and existing agreement reference.
• Current behaviour and requested difference.
• Proposed category and pending questions.
• Decision maker, outcome and decision date.
• Affected acceptance check and future review trigger.

3. Classify a request before deciding it

Suggested workflow practice: A new request usually fits one of four groups. An in-scope clarification explains an agreed item without changing its purpose, such as defining whether “pending” means waiting for a customer or a staff member. An in-scope correction fixes a build that does not meet an agreed acceptance check. A future enhancement adds useful capability that the first workflow does not need. A scope change alters the workflow boundary, users, records, permissions, dependencies, or acceptance checks.

Do not decide from a request title alone. Ask what task cannot be completed or understood without it, who will use it, which record it changes, and whether the agreed workflow can still be completed clearly without it. Compare the answer with the written scope and exclusions. An extra column can be a clarification when it makes an agreed view understandable; it can be an enhancement when it introduces a separate management practice.

Record every decision in a shared change log, including “not now.” Include the request, operational reason, category, decision maker, date, effect on the first workflow, decision, and next review trigger. This avoids restarting the same conversation and preserves observed needs without treating them as included work.

• What exact task is blocked or unclear?
• Which agreed role, record, status, or acceptance check is affected?
• Can the first workflow operate without the request?
• Is it a clarification, correction, enhancement, or scope change?
• Who makes the final decision?
• If deferred, what specific condition will trigger review?

4. Handle exceptions as suggested governance decisions

Suggested workflow practice: treat an exception as a visible decision when an agreed workflow is blocked, or when a request changes access, data handling, external connections, automated actions, or operating responsibility. This is a practical governance routine, not a universal legal or compliance rule. Its purpose is to prevent important decisions from being lost in informal messages.

Record the issue, the affected work, the temporary operating decision, the accountable owner, and the review date. If required information is missing, a small workaround may keep the first build testable. For example, staff may enter a reference from an existing record while a later connection remains outside the scope. Give that workaround an owner and describe it as temporary, not as a completed permanent feature.

Pause ordinary feature discussion if a request introduces new user groups, external access, sensitive information, automated actions, or another system connection. Reassess what must be tested, approved, and operated. The outcome may be a formally revised scope, a deferred request, or continuation of the original build while the separate need is defined.

• Describe the exception and affected work.
• Record any temporary operating decision.
• Assign one accountable owner and review date.
• Check whether permissions, data, automation, or another system are affected.
• Choose to revise scope, defer, or proceed as an agreed clarification.
• Change acceptance checks only when the boundary formally changes.

5. Run a small change-control routine

Suggested workflow practice: review requests during a predictable implementation check-in rather than deciding them through scattered chats. Bring the current scope record, change log, and one concrete workflow example. The requester explains the operational problem. The business owner confirms priority. The implementation lead identifies the agreed item affected. One named person records the decision.

Use three outcomes. “Include now” means the request is necessary to meet the original agreement or the parties have explicitly revised that agreement. “Defer” means the request is recorded for a later review after the first workflow is used. “Decline” means it does not support the intended workflow or duplicates an agreed method. Deferred and declined ideas can still be sensible; the decision concerns timing and boundary, not their worth.

Avoid “we will see later.” State the review trigger instead: after a defined pilot, after a dependency is confirmed, or when the business supplies a missing process rule. This leaves a usable path forward without suggesting that future work is already included.

• Review requests from one shared log.
• Bring a real workflow example, not only a feature label.
• Confirm the request owner and final decision maker.
• Choose include now, defer, or decline.
• Record the reason, operating effect, and review trigger.
• Share the decision with affected users.

6. Fictional example: a new approval step

Fictional example: Northgate Service Desk is an invented business. Its agreed first build records confirmed jobs, assigns one technician, tracks job status, and gives an owner a daily open-job view. The scope excludes customer portals, payment collection, automation, and integrations.

During testing, a manager asks for every job above an internally chosen condition to require a second manager’s approval before assignment. The team does not treat the request as a correction. The agreed workflow can already create, assign, update, and review jobs. The request would add a decision point, another user responsibility, a new status or record, and rules for jobs awaiting approval.

The change log records it as a scope change. The business owner decides to defer it until the team can define the condition, approval owner, fallback when that person is unavailable, and what happens to urgent jobs. The original build continues unchanged. At handover, the request remains visible as a later review item, rather than becoming an informal expectation or a partially built rule.

7. Finish with a scope-review handover

Suggested workflow practice: Before calling the first build complete, test agreed acceptance checks using representative fictional records and one common exception. Ask real users to perform their own steps: create or find a record, update status, hand work to the next person, and identify what needs action. Record defects that stop an agreed check from passing separately from enhancement ideas discovered during testing.

Hold a short handover decision. Confirm what was delivered, what remains outside the first build, which temporary workarounds remain, who owns everyday record quality, and which deferred items have a clear future trigger. This is not a commitment to later additions. It is a clean operating boundary for the workflow now in use.

Use this guide when the question is whether a request changes an already agreed implementation scope. Use separate workflow, system-selection, CRM, comparison, quotation-control, or job-handoff materials when the question concerns choosing a system, designing a specialised operational process, or comparing tools.

• Run every agreed acceptance check with representative records.
• Test one normal path and one common exception.
• Separate defects from future enhancements.
• Confirm delivered work, exclusions, dependencies, and temporary workarounds.
• Assign day-to-day operational ownership.
• Record deferred items only with a clear review trigger.