How to prepare a brief for an internal application or integration
A good brief does not have to be a technical specification. It is enough to describe how the work is done today, what goes into it, what should come out of it and how you will know that the first version has done its job.
Rather talk it through?
Describe the situation and I will suggest a first step and an estimate of the scope.
Let’s talkStart with how you work today, not a list of screens
The most useful input is one concrete work scenario, from the first input to the result. Describe it as it actually happens today, including the manual steps, spreadsheets and emails. From a description like that, the first usable version can be separated from features that can come later.
You do not need to know which technology to choose or what the database should look like. That is the job of scoping. What is needed from you is knowledge of the process and decisions about what matters to the business.
Nine points a brief should cover
- The current process.Who does what, in what order, where work gets held up and where errors occur.
- Inputs and outputs.What comes into the process (a form, an email, a file from a supplier) and what should be produced at the end (a record, a document, an export, an order).
- Users and roles.Who works with the solution, who only reads and who approves. Roles are enough; you do not need to give names.
- Connected systems.Which tools data should be exchanged with, who manages them and whether they have a documented interface or export.
- Exceptions.What happens when data is missing, incorrect or arrives twice. Exceptions tend to cost more than the normal flow, so it is good to know about them in advance.
- The expected outcome.What should change compared with today: less manual retyping, an overview of the status, faster handling.
- Acceptance criteria.How you will know that the first version works. For example: an order from an email gets into the records without manual retyping, and an incorrect record is flagged.
- Constraints.Deadline, budget, sensitive data, the change history you need, where the data may be stored and who will look after the solution after handover.
- What can wait.Features that are useful but that the first version can do without.
Send an anonymised spreadsheet, a sample email or an export. Remove personal and sensitive data from the sample or replace it with made-up values.
A sample brief
The following brief is fictional. It is not a real client or a completed project; it only shows how briefly the points above can be covered.
Fictional example
- Today’s process
- Orders from regular customers arrive by email. A colleague retypes them by hand into a shared spreadsheet and copies them into the warehouse system in the evening.
- Inputs and outputs
- The input is an email with the product name and quantity. The output is an order record with a status and an export for the warehouse system.
- Roles
- Sales enters and checks the orders; the warehouse only reads them and confirms dispatch.
- Integration
- The warehouse system can import a CSV file; it has no API.
- Exceptions
- An unknown product code, a duplicate order, a change to an order after confirmation.
- Acceptance criteria
- An order gets into the records in a single step, an incorrect code is flagged and the export passes the warehouse import without changes.
- Constraints
- Launch within three months; the data must stay on the company’s server.
- Can wait
- Management reports, an accounting integration, a mobile app.
What to leave for the next version
The first version should cover one continuous flow well enough for real users to work with it. Reports, additional roles, connections to further systems and more convenient controls are added only after it has been proven in practice, when it is clear what people actually need.
- reports and overviews that nobody asks for today
- connections to systems that data is exchanged with only occasionally
- automating steps that happen once a month
- visual refinements beyond readability and usability
A similar approach, where the data source is connected to the target system first, is shown in the online shop with product imports from suppliers. What software development involves and how it is priced is described on the custom software development page. You will find more practical topics in the IT guides.
We’ll go through it and define the first version.
Send a description in any form, even an incomplete one. Initial assessment: free of charge. I will tell you what is missing from the brief and what the next step would be.