What to clarify before commissioning software
A useful brief explains the change you need, the people affected and how you will recognise progress. You do not need to invent a complete specification.
Describe the problem before the solution
Write down what happens today. Follow one real case from start to finish and record where people wait, repeat work or correct mistakes. Describe the cost in time or friction using evidence you actually have. If you have not measured it, say so.
Separate a requested feature from its purpose. “We need a dashboard” is a possible solution. “The operations team cannot see which orders need attention” is a problem that can be explored.
Illustrative situation: two people copy orders between systems each afternoon. Before asking for a new platform, check which information moves, where it comes from and why the existing systems cannot share it.
A checklist to reuse
- Who does the work and who feels the consequences?
- What starts and finishes one case?
- Which workaround is in use today?
- What evidence would help size the problem?
Define what a useful first version changes
Choose an outcome that a user can observe. “A faster system” needs a concrete task and a way to measure it. A first release should be small enough to test in real work while still completing something useful.
Success criteria can be qualitative when numbers are not yet available. Agree who will try the first version, which examples they will use and what would make them reject it. Mark target numbers as provisional until you have a baseline.
A checklist to reuse
- One primary user and task for the first release
- A baseline or a plan to collect one
- A visible acceptance check
- Features deliberately deferred
Make constraints and ownership visible
List existing systems, data owners, access restrictions and deadlines with their reasons. A deadline tied to a contractual event is different from a preferred date. A budget range helps shape options; an unknown budget is an open decision.
Ask who will operate the software after launch. Hosting, access, monitoring, dependency updates and user support need owners. Request documentation and a practical handover, including access to source code and the terms governing its use.
A checklist to reuse
- Systems and data involved, with named owners
- Must-have integrations and real access constraints
- Budget and deadline, or who will decide them
- Acceptance, operation and maintenance responsibilities
Use the brief to start a better conversation
Share a short brief with your internal team or any provider. Ask them to restate the problem, identify missing information and propose the smallest useful test. Compare their reasoning as well as the estimate.
A good next step might be a workflow observation, a technical feasibility check or a small prototype. Avoid commissioning the whole answer while the central uncertainty is still unresolved. The brief builder helps you capture what you know and keep the rest as explicit questions.
A checklist to reuse
- Problem and affected users
- Desired outcome and acceptance criteria
- Known constraints and open questions
- A practical next step with an owner
Sources and upkeep
These sources inform the guidance above. The examples and checklists are modeleven’s editorial recommendations, not promises of results. Sources reviewed 8 September 2026.