18dev / Field notes
Practical thinking for better digital decisions.
Software projects fail at a well-documented rate. Research consistently puts project failure or significant overrun at somewhere between 50% and 70% of engagements, and most of those failures trace back not to bad code, but to a gap between what the client needed and what the development team built. That gap almost always opens in the briefing stage, before a single line is written. South Africa's custom software market is projected to reach R66 billion by 2030. The businesses that extract the most value from that investment are the ones who brief well.
A good brief is not a technical specification. It is a clear articulation of the problem being solved, the people who will use the solution, the constraints that apply, and the outcomes that define success. Specno, one of South Africa's leading digital product consultancies, advises clients that the single most valuable thing they can bring to an initial development conversation is an honest description of the problem, not a list of features they want built.
Start With the Problem, Not the Solution
The most common briefing error is leading with a solution rather than a problem. 'We need a customer portal' is a solution. 'Our customers are sending us frequent status update requests that take our account managers significant time to handle manually' is a problem, and a portal is one possible solution to it, not necessarily the best one.
When you lead with a solution, you lock the development team into building that solution regardless of whether it is the right approach. When you lead with a problem, you create space for the development team to contribute their expertise to the approach, which often results in a better solution, built with fewer complications and at lower cost.
This matters particularly in the South African context, where the Sage SBBO 2024 research found that moving away from manual processes remains one of the primary digital transformation challenges for local businesses. The companies that navigate this successfully tend to be the ones who describe what the manual process is costing them, in time, errors, and staff frustration, rather than specifying upfront what the software replacement should look like.
The best brief a client can write is one that makes the development team want to solve the problem, not just fulfil the specification.
Define the Users
Software is used by people with specific contexts, skills, and constraints. A system used by a warehouse team working with gloves on a mobile device has different requirements than the same system used by an administrator at a desktop. A customer-facing tool used by people with varying levels of technical confidence needs to be built differently than an internal tool used daily by trained staff.
The brief should describe who the primary users are, how technically comfortable they are, what environment they will be using the software in, and what they currently use instead. The last point is important: understanding what people are replacing tells the development team a great deal about the baseline expectations users will have.
Be Explicit About Constraints
Constraints are not weaknesses in a brief. They are useful information. Rocketsoft, which has built custom solutions across industries including finance, healthcare, insurance, and logistics, notes that integration requirements are consistently the most underestimated constraint in initial project briefs. Software that needs to connect to existing systems introduces complexity that compounds quickly if it is discovered late in the process rather than scoped for at the start.
- Budget range (even an approximate range is more useful than no figure at all)
- Timeline requirements and whether they are hard deadlines or preferences
- Existing systems the software must integrate with
- Data migration requirements
- Any POPIA or sector-specific compliance considerations
Describe Success
The brief should state clearly what success looks like. This is harder than it sounds, because it requires translating a vague positive feeling ('the process runs more smoothly') into something observable and, ideally, measurable. Useful success criteria might include: account managers spend less than X minutes per week on manual update requests; customers can find their status without contacting us; new team members can be trained in one day. These are outcomes, not technical requirements, and they are far more useful for guiding development decisions.
What You Don't Need to Include
You do not need to specify technical architecture. Unless you have a specific technical reason for a particular approach, the development team should be making those decisions based on what is appropriate for the problem. Yobi Code, a South African SME-focused development consultancy, frames this clearly: constraining a development team to a technology stack prematurely can create complications that did not need to exist. The best development partners will ask about your constraints. Let them ask.
You do not need to specify every feature. A brief that lists 47 features before the project has been scoped will produce a cost estimate that shocks you and a project that drags. Start with the core: what does the system absolutely need to do to be useful? Everything else can be prioritised once the scope is understood.
The brief is not the end of the scoping process. It is the beginning of a dialogue. But the quality of that dialogue, and the project that follows, depends almost entirely on the quality of the starting point you bring to it. Get the problem statement right, and the rest of the process is considerably more likely to go well.