October 21, 2026 · Faith Forge Labs Editorial Team
When a Small Change Becomes a Bigger Project
New ideas are normal during development. Give each change a clear decision about value, effort and timing before it becomes an unspoken promise.
“Could we also add this?” is a reasonable question during a software project. Seeing a working version helps people notice things a written brief could not show. The difficulty starts when a useful suggestion becomes an assumed commitment before anyone checks what it affects.
A change process should make decisions easier, not make people afraid to suggest improvements. Keep it proportionate: a short record and a clear owner may be enough for a small project.
Find the need behind the request
Suppose, in a hypothetical project, staff ask for a second export button. Before treating it as another screen control, ask what they need the export for. The answer might be a weekly management review, a requirement from another system or a workaround for information missing from the first export.
Those explanations could lead to different solutions. Write down the task, who needs it and what happens without it. A request to meet an agreed requirement is also different from a new capability discovered along the way.
Ask for options and impact together
Give the delivery team enough context to investigate. Ask which parts of the product, tests, connected systems and documentation would change. A short visible request can require work beyond the screen where it appears.
Discuss a few realistic options: include it now, exchange it for lower-priority work, provide a simpler version or defer it. The GOV.UK guidance on priorities offers useful background on choosing work according to its value and importance. Your own decision also needs to account for the project's actual constraints.
Ask what information would improve the estimate if the impact is uncertain. A bounded investigation is more useful than treating an early guess as an agreed delivery date.
Keep a short decision record
- Request: the problem or opportunity, with a safe example.
- Options: what could be done now or later.
- Impact: expected effort, dependencies and effects on agreed work.
- Decision: include, swap, defer or decline, with the reason.
- Owner: who approved the decision and who updates the plan.
Put the decision somewhere both sides can find it. If work moves out of the release, name it explicitly. If an extra cost or revised date needs agreement, resolve that before implementation. Do not let a chat reaction stand in for a decision nobody has written down.
Update what the team will accept
After approving a change, update its expected outcomes and any affected acceptance checks. Tell the people preparing content, training or operational support if their work changes too. When the next demonstration happens, compare it with the current agreed plan rather than the first version of the brief.
Some requests will remain good ideas for a later release. Keep them visible without suggesting they have already been commissioned. If the project repeatedly needs major changes, revisit the underlying workflow before adding more features.
Our guide to choosing a software development partner includes the wider questions about communication and delivery. For a project already struggling with an expanding scope, start a conversation with the agreed plan and the unresolved decisions, rather than a list of promises reconstructed from memory.