New ideas during a software project are normal. Staff learn by seeing real screens, and an early assumption may turn out to be wrong. The difficulty is not change itself; it is making changes without a shared understanding of their effect. A lightweight decision process helps a small business stay adaptable and keep commitments intelligible.
Describe the underlying need
When someone asks for an extra filter or approval step, record the business situation that prompted it. A hypothetical Newcastle training company might request a new dashboard after discovering that coordinators cannot see classes awaiting a venue decision. The need is visibility of that queue; a dashboard is one possible response. Ask how often the situation occurs, who is affected and what happens today. This keeps the discussion open to smaller or more useful alternatives.
Classify the request before debating it
Determine whether the request corrects behaviour that already contradicts agreed acceptance criteria, clarifies an unresolved requirement or adds a new capability. These categories can lead to different delivery discussions. Use the written scope and examples as the reference point. Avoid declaring every surprise a defect or every clarification an addition. When the original agreement is genuinely ambiguous, acknowledge that gap and agree how to resolve it rather than arguing from memory.
Compare the impact and the options
Ask the supplier to explain effects on implementation, review effort, dependencies and existing work. Then consider adding the request, replacing a lower-priority item, simplifying it or deferring it. A small visible feature can affect several workflows, while a larger-looking change may be isolated. The tradeoff should be explicit. For the training company, a queue filter might solve the immediate problem without committing to a separate reporting area and its ongoing maintenance.
Keep a short decision record
Record the request, reason, chosen option, owner and changed expectations. Update the active scope so the team does not have to reconstruct it from messages. A declined request can remain in a future ideas list with its rationale; it need not disappear. Your next scoping step is to agree who can authorise changes and what impact information they need. Apply that process to one real request before a long queue of informal promises develops.
Planning checklist
- Record the need behind the feature.
- Check the agreed acceptance criteria.
- Approve the impact and update the scope.