Things often go wrong in software projects long before any coding begins. A brief can be unclear and if it is, different people on the project will assume different things about what is being built, leading to surprises and disappointed expectations. A clear, well written brief doesn’t need to be long or overly technical. It should include what is required, the reason for the requirement and a way of validating it has been met.
Describe who will use it
Different users want different things and different people want the same thing to be done in different ways. You should write down the people who will use the system the most and the environments in which it will be used. A busy warehouse worker using a tablet has different requirements to a busy office manager using a desktop computer. One of the most important things you can give your supplier, when considering bespoke programming and app development, is who will use it, where and how, because it influences every decision made in the design process.
Separate what you need from what would be nice
You probably have a long wish list for each project. Break that list up into three segments: things the system must do on day one, things the system should do in the near future, and things that would be nice to have but are not necessary. Comparing quotes this way makes it easier to find the best price and allows for flexibility if the project budget is cut. This also prevents the first release of the project from being so big that it will never be completed.
Say how you will measure success
Ask yourself how you will know six months from now if the project was worth doing. Was there fewer errors? Was quoting time reduced? Was there fewer phone calls? Was there more repeat business? Think of numbers. A measurable goal usually keeps a project on track, and something to evaluate once the project is complete and the software is being used.
Talk about budget and timing openly
Some clients are wary to share budgets because they’re afraid that price will rise to meet their budget. A budget is a realistic limit on a price, and it helps a developer prioritise and manage expectations. The same principle applies to deadlines. Often, there are hard deadlines, i.e. trade shows, peak seasons, etc. Make sure you mention that, and ask what can be delivered by then.
Plan for what happens after launch
Software needs care and feeding. Hosting, maintenance, support and updates are all part of the cost of using a software. Ask who is responsible for maintenance and support, how much will it cost, and will support and maintenance be included in the contract term. Get the source code and documentation to reduce your vendor lock-in.
Keep the conversation going
Requirements are a starting point, a baseline. Do you know the data points behind those requirements? Do you know the assumptions behind the requirements? Does your vendor? A good project has a lot of short meetings to go over requirements. Watching something be built gives a better idea of how the project is progressing than listening to it. Fixing a requirement incorrectly stated can cost a lot more to fix if it’s caught later in the project. Having one contact person speeds things up.
Writing a brief takes time, but the right brief can actually save you time and money. Once you have your brief, share it with your suppliers, and watch as the best of them ask you the most insightful questions. The supplier that asks the most insightful questions will probably end up being the best supplier to work with.