Practical worksheet
A software project brief you can actually use
A project brief should help a team make decisions. It does not need to predict every feature. It needs to explain whose work will change, which part matters first, and how the team will know the release is useful.
Use the worksheet below for an internal tool, a customer application, or an AI pilot. The example running through this guide is a fictional service-request queue. Replace its assumptions with evidence from your own workflow.
Describe the current work, not just the proposed app
Start with one person and one repeated task. In the example, a service coordinator receives requests through email and has to ask colleagues who is handling each one. The problem is uncertain ownership. A request queue is one possible response, but the brief should preserve the problem so the team can evaluate other approaches.
Record how you know the problem exists. That might be observed duplicate assignments, interviews, or a sample of recent requests. Label estimates and assumptions. If no one has watched the work happen, make observation a next step rather than inventing a baseline.
Describe the smallest complete workflow
For the fictional queue, the first release lets a coordinator create a request, assign an owner, change its status, and find unresolved work. A release with only a polished intake form leaves the ownership problem unsolved. A small release still has to carry the user through the part of the job it promises to support.
List exclusions with equal care. In this example, forecasting demand, a public customer portal, and automatic AI assignment are deferred. Exclusions keep a useful suggestion from silently becoming a launch requirement. Revisit them when evidence changes, not each time someone sees a new demo.
Put data and permission owners in the room
Identify the system of record, the fields needed, and who can authorize access. The queue might need a customer reference without needing every customer document. An integration that has no confirmed owner is a dependency to resolve, not a detail to assume away.
Separate access by action and record scope. Who can submit, assign, close, reopen, export, or delete a request? Can contractors see the same records as employees? Write down the unanswered questions. The team can build a prototype with synthetic data while those questions are being resolved.
Specify what happens when the work goes wrong
An ordinary request is only one case. Decide what happens when the assigned person is absent, the customer is duplicated, the source system is unavailable, or two people edit at once. Each exception needs either supported behavior or an explicit manual path.
For AI-assisted steps, say what the system may suggest and what requires a person. In our example an assistant could draft a summary for review. It would not silently close a request or promise a resolution time. If AI adds no useful benefit to the first workflow, leave it out of that release.
| Situation | Observable result |
|---|---|
| Two coordinators assign the same request | The second update detects the change rather than silently replacing it. |
| An employee opens an out-of-scope record | The application refuses access. |
| The source system is unavailable | Existing work stays visible and the failed action is clearly identified. |
| A request is closed | The record shows who closed it and when. |
Agree how to evaluate the release
Choose a few measures connected to the original problem. For the queue, those could include unassigned requests, duplicate assignments, and time spent finding an owner. Define the observation period and collect a baseline before claiming improvement. A target is a planning choice; it is not a result.
Finally, name the release owner and the person responsible for support. Record the next unresolved decision, an owner, and a date to revisit it. The brief is ready for a useful conversation when the team can distinguish confirmed facts, decisions, and open questions without reconstructing the original meeting.
Your working brief
Put the plan on one page.
Your entries stay in this page. They are not submitted to Blutek or saved in browser storage. Download your notes before leaving or refreshing.
Sources and further reading
- AI project readiness checklist
Use this companion when the first release depends on AI interpretation or generated output.
- Low-code architecture guide
Turn the workflow and access decisions into application boundaries.