A practical seven-question brief for turning business assumptions into testable project decisions
Custom software projects rarely become difficult because a business failed to name enough features. They become difficult when the people buying the software and the people building it are making different assumptions about the outcome, users, data, constraints, and definition of success.
A small business does not need a hundred-page technical specification before speaking with a development team. It does need a short decision document. The most useful version can often be produced by answering seven questions clearly.
1. What business result should change?
Start with an operational result, not a screen or technology. The goal might be to shorten an approval cycle, eliminate duplicate data entry, let customers complete a task without calling staff, reduce missed handoffs, or make a service available outside business hours.
Name the current baseline when it is known. How long does the process take? How many systems are involved? Where does work wait? What error or rework happens repeatedly? A baseline helps the team decide whether a proposed feature is essential or merely interesting.
2. Who will use the system, and what can each person do?
List the real user groups. A customer, front-line employee, manager, administrator, accountant, and external partner may all need different views and permissions.
For each group, describe the task they need to complete, the information they may see, the decisions they can make, and the device or environment they normally use. This prevents a common late discovery: the workflow works for the primary user but not for the person who approves, supports, audits, or reports on it.
3. What does the current workflow actually look like?
Document the trigger, major steps, decision points, handoffs, exceptions, and completion point. Include the unofficial workarounds that staff rely on, such as a spreadsheet maintained beside the main system or an email that serves as an approval record.
The exception path matters. What happens when information is missing, a payment fails, a customer changes a request, or an integration is unavailable? Software designed only for the happy path creates manual work precisely when the team is under pressure.
4. Which data and integrations are part of the first release?
Create a simple inventory of systems, records, files, and data owners. Identify what the new application must read, create, update, or export. Note whether an existing vendor offers an application programming interface, a scheduled export, or no supported connection at all.
Data condition is as important as data location. Duplicate customer records, inconsistent categories, missing identifiers, and unclear ownership can add more effort than the visible application. A short data review before estimating helps keep migration and cleanup from arriving as surprises near launch.
5. What must be true at launch?
Separate the first useful release from the long-term wish list. A launch requirement is something without which the business cannot safely or meaningfully use the product. A future enhancement improves the experience but does not prevent the first release from solving its core problem.
Also define acceptance in observable terms. Instead of saying the system should be fast, state the important task and an acceptable response time. Instead of asking for flexible permissions, list the actions each role must and must not perform. Testable requirements produce clearer estimates and fewer arguments about whether work is complete.
6. Which constraints need specialist review?
Flag privacy, security, accessibility, records retention, procurement, hosting, and industry requirements early. The goal is not for a business owner to become a lawyer or security architect. It is to identify where qualified review is required and make that work part of the plan.
Canadian organizations may face federal and provincial privacy obligations depending on their activities and location. Accessibility requirements can also vary. The safest brief names the data involved, the users affected, the operating regions, and the expert decisions still outstanding instead of making broad assumptions.
7. Who decides, and how will change be handled?
Name the person who owns the business outcome, the people who provide subject-matter input, and the person authorized to approve scope and budget. Then agree on how new requests will be evaluated after work begins.
Change is normal. Uncontrolled change is expensive. A useful process records the request, reason, effect on cost and schedule, and decision. This lets the team adapt without quietly turning every new idea into an immediate commitment.
A better first conversation
The best project brief is not the one that predicts every screen. It is the one that lets business and technical teams see the same problem. A concise document covering outcomes, users, workflows, data, launch conditions, constraints, and decisions gives prospective partners enough context to ask sharper questions and propose a responsible first step.
That first step may be discovery, a prototype, integration research, or a phased build. Whatever the answer, the business is in a stronger position when the important assumptions are visible before an estimate becomes a promise.
About Author
Scott Jackson is President and Founder of Essential Designs, a Canadian custom software development company. Since founding the company in 2008, he has worked with organizations planning web, mobile, business-software, and modernization initiatives. His writing focuses on practical software planning, requirements, delivery risk, AI-enabled workflows, and long-term product operations.
