How to prepare a brief for a business application

Are you about to approach a supplier with an enquiry about an internal application, for example for orders, stock, approvals or record keeping? You do not need to write a technical specification. What the supplier needs from you is what only you know: how work in your company really runs, where it gets held up and what should be different once the application is in use.

The points below will help you prepare material that makes the first meeting focused and the proposal more precise. Plain language and a few paragraphs on each point are enough.

Describe how the process runs today

Start with one specific procedure and go through it step by step. Who starts it? What follows? Where does it wait for a decision or for information from someone else? How does it end?

Take purchase approval as an example: an employee sends a request by e-mail, the manager approves it, the buyer orders the goods and the accountant matches the invoice to the order. A description like this, a few lines long, tells the supplier more than a list of desired features.

Do not forget the exceptions. In practice, the approver may be on leave, an order may change after it has been approved or a delivery may arrive in parts. These are the situations that show whether the application matches the way you work. If they are known in advance, they can be taken into account in the design and will not surface only during testing.

It helps if the description is written, or at least checked, by someone who carries out the procedure every day. Management knows the rules, employees know the everyday practice.

People and access

Write down who will work with the application and in what role:

• who enters and edits data,
• who approves or decides,
• who only needs to see the status, for example management or sales staff,
• what nobody should see except designated people, for example payroll data or purchasing terms.

You do not need exact user numbers. A rough idea is enough: how many people are in each role and whether they will work at a computer or also from a phone in the warehouse or on the road. The design of the screens and of the access rights depends on it.

Data: what you record and where

State where the data involved in the process is kept today: in spreadsheets, in e-mails, in an accounting or ERP system, on paper. If you can, attach a sample of a spreadsheet or form that you use. Feel free to replace any sensitive data in it with made-up values.

Then answer two questions for yourself:

• Which data needs to be transferred to the new application? For example a customer list, stock items or open orders.
• Which systems should the application be connected to, so that data is not retyped by hand?

If you do not know whether your accounting or ERP system allows a connection, at least write down its name and version. The supplier will check the connection options.

What should be different once the application is in use

Name the specific problem the application is meant to solve. A sentence such as “we want our orders under control” is too general. A description of the situation serves better: nobody knows the status of an order until they have phoned round their colleagues. Or: the same order is retyped from an e-mail into a spreadsheet and from the spreadsheet into the accounting system.

Next to the problem, add how you will recognise that it has been solved. In your own words, without complicated indicators. For example: the manager sees the status of every order without making phone calls, an approval request does not sit in someone’s inbox, each piece of data is entered only once.

A goal described in this way helps with every later decision. When a new requirement comes up during development, it can be judged with a simple question: does it contribute to what we set out to solve?

Scope of the first stage

Divide the requirements into two groups: what the application cannot be used without from day one, and what can wait. The first group covers what people need for their everyday work. The second often includes reports, rare exceptions or integrations that can be replaced by an export for the time being.

Starting with one process is safer than describing, all at once, everything that could be improved in the company. A smaller scope is easier to estimate and to check, and the experience from the first stage makes the following ones more precise. Write the other ideas down in a list for later so that they do not get lost.

Who decides and who tests

Appoint one person who will make decisions on behalf of your company. They should have the authority to say what the priority is and the time to answer questions during development. If several people decide and nobody clearly has the final say, the brief changes depending on who attended the last meeting.

The people who will use the application every day are just as important. Choose a few of them for testing. They should try the application on their own examples, not on sample data. Allow for the fact that they will need time for this alongside their regular work.

What the brief does not need to contain

There are things the supplier does not need from you, and preparing them would delay you unnecessarily:

• Choice of technology. Whether an application in Power Platform or a standalone web application is the better fit will follow from the process, the users, the integrations and the way the application will be run. We describe both options on the App development page.
• Screen designs. A sketch on paper can help when you are explaining something, a finished design is not needed.
• Database design. It is enough to know what data you record. Its structure is the supplier’s job.

These parts take shape during a joint analysis. In it, the supplier goes through your workflow, data and access rights with you and only then proposes a solution and the scope of the first stage.

If you already have a proposal from a supplier and are not sure about its scope or the chosen technology, it can also be assessed in an independent consultation.

Checklist before the first meeting

If you do not have an answer to one of the questions, that is fine. Make a note of it and come back to it at the meeting.

• Do you have one process described step by step, including the exceptions that occur in practice?
• Do you know who enters data, who approves and who only needs to see the status?
• Is it clear which data nobody should see except designated people?
• Do you have a list of the places where the data is kept today, and a sample spreadsheet or form?
• Do you know which data needs to be transferred and which systems need to be connected?
• Can you say in a few sentences what problem the application should solve and how you will recognise that it has been solved?
• Have you divided the requirements into those needed from day one and those that can wait?
• Has the person who decides been appointed, along with the people who will test the application?