Start with the problem you want to remove
A useful brief does not need to be a technical specification. For the first conversation, a clear problem statement is more helpful than a long list of screens. Explain who does the work today, what slows them down, and what the new system should achieve. 'We need an app' opens a conversation; 'we need every service request assigned and its status traceable' describes a concrete goal.
Choose a measurable indicator: handling time, corrections, overdue cases, or time spent producing reports. Record the current situation and the desired outcome. If current figures are unavailable, mark them as information to collect. Do not present an estimate as measured evidence.
- Who will use the system and who owns the rules?
- What work is manual or duplicated today?
- What outcome would demonstrate the investment's value?
- What happens if the problem remains for another year?
Describe one workflow from input to outcome
Choose the primary workflow and walk through it step by step. Record inputs, responsible people, decisions, states, and outputs. Include exceptions such as missing information, rejection, cancellation, duplicates, and cases returned for correction. Exceptions often drive development complexity.
Bring anonymized examples of current forms, spreadsheets, or reports. These help explain data and rules; they are not instructions to copy an old interface. At each step, distinguish a business requirement from a habit caused by limitations of the current tool.
Prioritize requirements
Explain why each requirement is needed. Classify it as essential for the first release, useful for a later phase, or still open. The first release should let users complete the core workflow rather than demonstrate only its opening steps.
State what the first phase will exclude. Clear boundaries make proposals easier to compare and help evaluate new ideas during delivery. Record dependencies: order approval, for example, requires defined roles and approval rules.
- Essential: users cannot complete the core workflow without it.
- Later phase: valuable, but the first release can operate without it.
- Open: needs a decision, data sample, or technical investigation.
- Out of scope: deliberately deferred processes, platforms, and integrations.
List data, integrations, and permissions
List existing systems that must work with the new solution. For each, describe the data exchanged, direction, frequency, and who can provide documentation or test access. Do not assume an API is available; flag unverified integrations for investigation.
For migration, identify the data source, owner, and required history. Record known duplicates and missing values. Describe permissions through actions: who may view, create, edit, approve, or export a record. Passwords and production keys do not belong in the brief; agree a separate method for handing over access.
Agree how completed work will be recognized
Add testable acceptance criteria to key requirements. Instead of asking for a 'clear report', specify its data, authorized users, and how totals must reconcile with source records. Test scenarios should cover the normal workflow and the exceptions already identified.
Clarify who tests the first release, who accepts it, and who helps users after launch. Discuss training, documentation, backups, support, and operating responsibilities. Record requirements for speed, availability, and data volume, then agree specific limits based on actual use.
Bring a clear working document to the consultation
You do not need a finished architecture or a selected technology. Bring the goal, main workflow, priorities, anonymized examples, and open questions. Add a budget range, desired deadline, and its reason. Distinguish a fixed deadline from a preference and identify who can make ongoing decisions for the company.
This gives the development team enough context to ask focused questions and propose a first phase. Missing critical rules or uncertain integrations may call for analysis or a prototype before estimating development. In a DAVOND introductory consultation, we can review the problem, consider suitable solutions, and identify what needs verification first.