How to scope a technology project before requesting a quote
A useful project scope describes the business result, the work that must change and the evidence that will show the solution works. It also makes exclusions and unresolved questions visible. You do not need to design the entire system before asking for a quote, but suppliers need a common basis for their assumptions.
Describe the operation before the features
Begin with the people doing the work, its trigger and its end point. Identify where information enters, who makes decisions and what systems must be updated. Include the exceptions that consume attention today. A list of screens rarely explains those responsibilities.
Separate the desired outcome from a proposed technology. 'Make approved invoice status visible to finance and procurement' gives a clearer objective than 'build an AI dashboard.' The technology can be selected after the required behaviour and constraints are understood.
An illustrative invoice project
Imagine a team tracking invoice approvals through email and a spreadsheet. Its initial brief asks for a portal. A more useful scope says who submits an invoice, which system supplies supplier details, how approval authority is determined, what happens when an invoice is disputed and who records the final payment status.
A first release might cover visibility and approval routing while leaving payment execution in the existing finance system. That exclusion matters: a supplier should not price a payment platform when the business needs a reliable approval workflow. This is an illustrative example, not a customer result.
Give suppliers the same decision basis
Write a short brief that distinguishes confirmed requirements from assumptions. Ask suppliers to identify where an estimate depends on information they have not yet inspected.
- Outcome and baseline: what is difficult today, and how will improvement be assessed?
- Scope boundary: which users, locations, workflows and exception types are included or excluded?
- Dependencies: which systems, interfaces, data owners and access approvals are involved?
- Controls: who may view, approve, change or reverse each consequential action?
- Acceptance: which realistic scenarios must pass, and who will accept the result?
- Operation: who will support the solution, handle incidents and own future changes?
Define acceptance before delivery
Agree the scenarios and measures that will decide acceptance before implementation begins. Record the current baseline where it can be measured, the intended improvement and the controls that must remain intact. Include a normal case, a rejected action and recovery after a failure. Identify who will review the evidence and resolve any disagreement; a feature being present is different from the operation working as intended.
Leave room for discovery without leaving scope open-ended
Too little detail makes quotes difficult to compare. Too much premature specification can lock in the wrong solution. Use discovery for genuine unknowns, such as undocumented interfaces or inconsistent data, and agree what that work should produce: a process map, tested integration assumptions or a bounded implementation plan.
Before requesting a quote, walk one normal case and one difficult exception through the proposed scope with the people responsible for them. Record disagreements and assign owners. A smaller agreed boundary is more useful than a comprehensive feature list whose decisions remain unresolved.
Hyperwise's first conversation can begin with this brief rather than a finished technical specification. The aim is to understand the operation well enough to propose appropriate next work.