How to plan a software project without a technical brief
Prepare a useful project brief with a practical checklist and reusable template for users, workflows, scope, budget and the decisions still to make.
Begin with the job someone needs to finish
A useful software brief helps a team understand the work before choosing screens or technology. You do not need technical vocabulary. Write one sentence naming the person, the task and the current difficulty. For example: “Our coordinator needs to assign approved jobs to field staff, but changes are scattered across messages.” This is an illustrative example, not a client result.
Describe how you would recognize an improvement: fewer repeated entries, a visible approval status or a booking that a customer can complete without calling. Use a measure you can observe today rather than promising a percentage improvement without evidence.
Walk through one normal case and one exception
Follow one example from start to finish. Say what starts the request, what information is needed, who acts next and how completion is confirmed. Then describe a case that goes wrong: a cancelled booking, a missing document, a rejected approval or a failed payment. These cases often reveal requirements that a feature list misses.
- People: customers, staff, managers and anyone who approves or reviews.
- Access: what each person can see, change and approve.
- Information: where records come from and which system is the reference.
- Exceptions: who resolves a problem and what the user sees while waiting.
Separate the first release from later ideas
Mark each requirement as essential for the main journey, useful later or still undecided. An essential feature is one without which the chosen user cannot finish the job. For a booking website, a customer may need to choose an available time and receive confirmation; a loyalty programme could wait. A staff view may still be essential if someone must manage cancellations.
Include a short acceptance example for each essential journey: “When a confirmed booking is cancelled, the customer sees the cancellation and the time becomes available again.” This gives you a practical way to review working software and makes exclusions easier to discuss.
List the dependencies that affect cost and timing
List your existing tools, website content, designs, data and account owners. Name the systems you want to connect without assuming every connection is available. Note languages, accessibility needs, devices, expected use and any special handling of information. If old records must move, explain how much material exists and whether anyone has checked its quality.
State the budget range and why the deadline matters. Keep development separate from hosting, paid services, content and ongoing maintenance. You can share a redacted example of a workflow; arrange appropriate access before sharing credentials or confidential records. An unanswered question is useful information when it is clearly recorded.
Copy this brief into your own project notes
Keep the first version short enough to discuss together. Fill in what you know and write “to confirm” wherever a decision remains open. A reviewed brief can inform a proposal; it does not set contractual terms by itself.
- Goal and current problem: …
- People using it and their responsibilities: …
- Main journey, from start to completion: …
- Exception and who handles it: …
- First-release essentials and acceptance examples: …
- Later ideas and things outside the scope: …
- Existing tools, data, content and account owners: …
- Budget, deadline and reason for that date: …
- Open questions, review contact and next decision: …
Related services
Turn the guide into a project conversation
Write down the decisions you can make now and the questions that need review. Use the estimate to explore a starting budget, or contact us to discuss the scope.