Most technology project problems trace back to one root cause: a brief that was not specific enough for the people executing it to make the right decisions. Vague briefs produce vague quotes. Vague quotes produce scope disputes. Scope disputes produce budget overruns and missed timelines. The problem tends to feel like it started in the development phase; it almost always started in the briefing phase.
Writing a clear, specific project brief before approaching any developer, agency, or technology partner is one of the highest-value things a business owner can do for a technology project. It produces better quotes, reduces the gap between expectation and delivery, and significantly improves your ability to evaluate and compare the proposals you receive.
This guide explains what a good technology project brief contains, with specific guidance for the South African business context.
Start with the business problem, not the solution
The most common brief mistake is describing the solution in detail without adequately explaining the problem it is supposed to solve. "We need a mobile app" is not a brief. "Our field technicians are currently using paper job cards, which creates a two-day delay in invoicing because the cards need to return to the office before invoices can be generated, and approximately 15 percent of job cards arrive incomplete or illegible" is the beginning of a useful brief.
Starting with the problem rather than the solution allows the development partner to propose approaches you may not have considered. It also provides a clear success metric: the solution should eliminate the two-day invoicing delay and the 15 percent error rate. That is a specific, measurable outcome that the brief is now oriented around, rather than a feature list to be implemented.
Describe who will use the system and how
Every digital system serves specific types of users, and those user types have specific needs. A brief that does not describe users clearly forces the development partner to guess at requirements. A brief that does describe users clearly allows for accurate scoping.
For each type of user, describe: who they are (a field technician, a client, an accounts administrator), what they need to do in the system (record a job completion, approve a quote, reconcile payments), how often they will use it (daily, weekly, occasionally), and what environment they will be in when they use it (on a site with intermittent connectivity, in an office on a desktop browser, on the road on a mobile phone).
This user context makes a significant difference to the technical decisions involved. A system used daily by field staff in areas with poor connectivity is technically different from a system used weekly by office staff on reliable broadband, even if the feature list sounds similar on paper.
List what it must connect to
Integration requirements are one of the most frequently underspecified elements of a technology brief, and one of the most significant cost drivers when they emerge late. List every existing system your new system will need to exchange data with: your accounting software (Xero, Sage, Pastel), your payment gateway (Payfast, Peach Payments, Paystack), your CRM, your HR system, your stock management platform, or any other tool that holds data the new system will need to read from or write to.
For each integration, note whether the existing system has an API (most modern cloud tools do), and whether you have access to that API's documentation. Integrations with systems that lack a clean API are significantly more expensive and take longer than integrations with well-documented, modern APIs. Knowing this upfront prevents unpleasant surprises during scoping.
Define what success looks like
A brief that defines success criteria makes the project evaluable in a way that a feature list cannot. What should be measurably different about your business six months after the system goes live? How many hours per week of manual work should be eliminated? What error rate should drop? What revenue opportunity should be unlocked? What customer experience should improve and how would you know it had?
These criteria do not need to be precisely quantified at the brief stage, but they should be directionally clear. A system that is delivered on time and on budget but does not reduce the invoicing delay and the error rate has not met the brief, regardless of whether all the specified features are present. Success criteria keep the project oriented around business outcomes rather than feature delivery.
Be specific about what is out of scope
Explicitly listing what is out of scope for the initial build is as important as listing what is in scope. Technology projects suffer from scope creep, where features that seemed like obvious additions during development get added to the build, expanding cost and extending timelines. A brief that explicitly excludes certain features (phase two features, nice-to-haves, and future considerations) gives the development partner a clear boundary and gives you a basis for evaluating scope change requests during the project.
The most useful approach is to think of the project in phases: what must be in the first version for it to deliver its core value, and what can wait until a second phase once the foundation is proven? That distinction, made before the project starts, is much easier to maintain than one made in the middle of a build.
Include your constraints honestly
Budget range, timeline, and technical constraints are all legitimate inputs to a brief that help a development partner give you an accurate and realistic response. A brief that withholds the budget invites proposals at every price point, many of which will not be relevant. A brief that states a realistic budget range (our pricing page has indicative ranges that can anchor your estimate) invites proposals designed around delivering the best outcome within that range, which is a more useful response to evaluate.
If there is an existing technology infrastructure that the new system must work within, or a hosting environment that is required for security or regulatory reasons, these constraints belong in the brief. If there is a specific timeline driven by a business need (a product launch, a regulatory deadline, or a staff transition), include it and explain why it is fixed versus flexible.
What you will get back
A clear, specific brief typically produces better proposals in two ways: the proposals are more accurate (because the development partner has made fewer assumptions) and they are more comparable to each other (because different providers have responded to the same specification rather than to different interpretations of a vague request). Evaluating proposals from a specific brief is also significantly easier, because you can assess each one against the same set of requirements rather than trying to compare incompatible scope interpretations.
The hour or two invested in writing a proper brief before approaching the market is usually recovered many times over in the quality of proposals received and the reduction in scope disputes during the project itself.
If you have a project in mind and want help thinking through the brief, get in touch with CodeLab One for a no-obligation scoping conversation. Our Assessment tool is designed to help you think through your technology needs in a structured way before committing to any build.
