Project definition
Scope custom operational software around one real process
A useful software brief begins with work that is hard to complete or verify, not with a list of screens. One concrete process gives the team a shared way to decide what the first release should change.
Describe the trigger, people and next action
Ask what starts the process, who receives the information, who decides and what happens when the work is late or unclear. Name the tools already involved and the point at which information is copied or reconstructed.
This description can be short. It should still distinguish a symptom, such as repeated status calls, from the underlying handoff that makes the calls necessary.
Turn the desired outcome into a test
Choose a small set of priority scenarios and write what a person must be able to do in each one. Include the relevant data, role, exception and visible result. These scenarios become acceptance criteria rather than a promise that every possible feature belongs in the first version.
For a handover tool, that might mean finding a procedure together with its recording, transcript and source. For a delivery view, it might mean finding the current state and the person responsible for the next step. The exact criteria must come from the customer's process.
Price a defined scope, then preserve the decision
The initial consultation is free and without commitment. Once requirements and constraints are clear, a versioned estimate can state deliverables, assumptions, exclusions and price. Development starts only after the customer approves the applicable estimate.
If the scope changes during discussion, create a new estimate version. Keep the decision and its context beside the request so that a later conversation does not erase what was agreed.
Use a preview to review the agreed cases
A protected preview lets the customer test the priority scenarios against a working increment. Feedback should refer to the case and the expected result, making the next adjustment specific and reviewable.
The review choice is not automatically contractual acceptance or permission to release. Record the decision, complete the agreed checks and make the next action visible before publishing a versioned release.
A brief that is ready to discuss
- What work starts the process, and who owns the next action?
- Which existing systems and constraints shape the first version?
- What three scenarios would prove the result is useful?
- What must be decided before an estimate can be approved?