SOFTWARE PROJECT BRIEF WORKSHEET
Wavelength Computer Company
Version 1.0 | 2026-10-04
Download path: /resources/software-project-brief.txt

PURPOSE
Prepare an initial conversation about a specific software idea, even when
details are loose. This is a reusable editorial worksheet, not a client
artifact or a completed engineering specification. It does not establish
an agreed price, delivery date, or implementation plan.

INSTRUCTIONS

For an initial conversation, complete context and outcome, then describe one
task. Mark gaps unknown. Develop the remaining sections with your partner.
1. Fill in context and the business outcome using plain language.
2. Connect each essential user task to an outcome and observable check.
3. Keep facts, assumptions, exclusions, and unknowns in separate records.
4. Write "unknown" in fields you cannot answer; do not invent requirements.
5. Give each unknown an owner and next step. If the owner is unassigned,
   the business decision maker is responsible for assigning one.
6. Use the same tasks and checks to inspect an existing-tool alternative.
7. Review scope, estimate dependencies, acceptance, and ownership with
   your product and engineering partner. They should help develop details.
8. Record changes with a date and reason. Repeat blank records as needed.
9. The fictional section is a model. Remove it from your own brief.

PART A: BLANK BRIEF

1. CONTEXT AND CONSTRAINTS
Project name:
Brief version / date:
Prepared by:
Business decision maker:
Specific thing you want built:
Why you want it now:
Current process, from trigger to completion:
One concrete current-workflow example (avoid private information):
Current workaround and its limitations:
Primary users:
Supporting staff / roles:
Device, accessibility, or working-environment needs:
Fixed deadline, if any, and its reason:
Budget range, if known:
Hard constraints and their sources (system, contract, policy, other):
Preferences that may change:
Who can approve a smaller scope:

2. BUSINESS OUTCOME
Outcome ID (O1):
What should become possible or improve for the business:
Why it matters:
Evidence of the current situation and its source:
How you would observe the benefit after launch:
Evidence available before launch, or unknown:
Who will review that evidence:
Note: passing a software acceptance check does not prove business benefit.

3. USER TASKS
Task ID (T1):
Linked outcome ID:
Person / role:
Trigger:
What the person needs to do:
Why they need to do it:
Current steps:
Desired steps, if known:
Required input / source:
Expected output:
Priority (essential for first release / later / undecided):
Business rule owner:

Task ID (T2):
Linked outcome ID:
Person / role:
Trigger:
What the person needs to do:
Why they need to do it:
Current steps:
Desired steps, if known:
Required input / source:
Expected output:
Priority (essential for first release / later / undecided):
Business rule owner:

4. OBSERVABLE ACCEPTANCE CHECKS
Write checks as situation + action + expected visible behavior.
Include an exception. Use fictional or appropriately redacted records.

Check ID (C1):
Linked task ID:
Situation / starting record:
Person and action:
Expected visible behavior:
Who may access the record / who must not:
Evidence needed to inspect the behavior:
Business acceptance reviewer:
Unresolved decision or dependency:

Check ID (C2):
Linked task ID:
Situation / starting record:
Person and action:
Expected visible behavior:
Who may access the record / who must not:
Evidence needed to inspect the behavior:
Business acceptance reviewer:
Unresolved decision or dependency:

Check ID (C3), exception:
Linked task ID:
Failure, missing information, or unusual situation:
Person and action:
Expected visible behavior:
What should remain unchanged:
Manual fallback and its owner:
Evidence needed to inspect the behavior:
Business acceptance reviewer:
Unresolved decision or dependency:

5. FACTS: CONFIRMED INFORMATION WITH SOURCES
Fact ID (F1):
Statement:
Source / accountable person:
Date confirmed:
Linked task or check:

Fact ID (F2):
Statement:
Source / accountable person:
Date confirmed:
Linked task or check:

6. ASSUMPTIONS: BELIEFS TO VALIDATE
Assumption ID (A1):
Statement:
Why it seems plausible:
Validation step:
Validation owner:
Decision affected if false:
When it needs resolving:

Assumption ID (A2):
Statement:
Why it seems plausible:
Validation step:
Validation owner:
Decision affected if false:
When it needs resolving:

7. EXCLUSIONS: DELIBERATELY OUTSIDE THIS VERSION
Exclusion ID (E1):
Excluded capability or work:
Reason:
Workaround, if needed:
Condition for reconsidering:
Decision owner:

Exclusion ID (E2):
Excluded capability or work:
Reason:
Workaround, if needed:
Condition for reconsidering:
Decision owner:

8. UNKNOWNS: OWNER AND NEXT STEP
Unknown ID (U1):
Question:
Owner (or "unassigned"):
Next step:
Evidence needed:
Task / check / estimate affected:
Needed before which decision:
Resolution / date:

Unknown ID (U2):
Question:
Owner (or "unassigned"):
Next step:
Evidence needed:
Task / check / estimate affected:
Needed before which decision:
Resolution / date:

9. DATA, SYSTEMS, AND ACCESS
Repeat this record for each important system or record type.
System / record name:
Information required:
Which system holds the authoritative record:
Who owns the information:
Who controls system access:
Should the proposed software read it, change it, or both:
How it could be accessed (or unknown):
Sample record or export available:
Sensitive information / restrictions to discuss:
Update frequency / acceptable age (or unknown):
Record quality / cleanup needed (or unknown):
Migration needed (or unknown):
Failure behavior / manual fallback:
Reconciliation or correction owner:
Linked unknown IDs:

10. EXISTING-TOOL / PROCESS ALTERNATIVE CHECK
Alternative to inspect:
Owner of inspection:
Tasks and acceptance checks to run against it:
Evidence inspected:
What works:
What fails:
What remains unknown:
Workflow limits you would have to accept:
Data access and permission questions:
Software / integration ownership if custom-built:
Manual process or fallback and staff work required:
Decision (use / configure / build / investigate):
Reason tied to the business outcome and checks:
Decision owner / date:
Note: do not assume a vendor capability or comparative cost without evidence.

11. FIRST SCOPE AND ESTIMATE DEPENDENCIES
Proposed complete first task / workflow:
Included task IDs:
Included check IDs, including exception handling:
Linked exclusion IDs:
Deferred tasks:
Unresolved decisions that could change scope:
Estimate assumptions about data access:
Estimate assumptions about record quality:
Estimate assumptions about permissions / user groups:
Estimate assumptions about update frequency:
Estimate assumptions about migration:
Estimate assumptions about support after launch:
Inspection or prototype needed before a firmer estimate:
What changes if a dependency is unavailable:
Written estimate: included deliverables / effort and calendar ranges:
Client responsibilities / investigation vs implementation:
Build vs recurring costs / excluded costs / assumptions that trigger revision:
Scope-change approval owner and process:
Who prepares the estimate:
Who approves scope and cost:
Next bounded step and its completion evidence:

12. HANDOFF AND OWNERSHIP
Account access / code and deployment instructions:
Data export and recovery instructions / operating notes / staff training:
Package acceptance owner / support transfer date:
Product and engineering partner:
Business rules approver:
Business acceptance reviewer:
System access owner:
Data / status correction owner:
Support contact and responsibilities after launch:
Code ownership:
Hosting account ownership:
Maintenance responsibilities:
Ongoing costs and who pays them:
Who records scope decisions and changes:
Where the shared current brief lives:
Next review date:

Change record:
Date:
Changed field / record ID:
Previous decision:
New decision:
Reason:
Scope / estimate effect:
Approved by:

PART B: FICTIONAL WORKED EXAMPLE
This entire section is fictional. It illustrates a proposed brief, with
no client identity, measured benefit, completed implementation, or test
result. Facts below are facts within the fiction only.

CONTEXT
A service company whose customers email staff for updates; staff look up
the job in a dispatch tool and reply. The owner wants a customer portal.

OUTCOME AND TASKS
O1: Make routine job status visible without a staff reply.
T1: Check the current approved status of their own job.
    Role: Customer. Linked outcome: O1.
T2: Approve a customer-facing status in the dispatch tool without entering
    it again in the portal.
    Role: Dispatcher. Linked outcome: O1.

FACTS WITHIN THE FICTION
F1: Staff use a dispatch tool and reply to status enquiries by email.
Fictional source: dispatcher workflow walkthrough; linked T1/T2.
F2: The dispatcher owns approval of customer-facing status.
Fictional source: dispatcher confirmation; linked T2/C2.

ASSUMPTION
A1: Customers will use self-service status checks. Validate through
    conversations with intended users. Validation owner: operations manager;
    record findings before committing to the portal scope.

EXCLUSIONS
E1: Payments, appointment changes, and portal messaging are outside the
    proposed first release.

PROPOSED ACCEPTANCE CHECKS; NO RESULTS ARE CLAIMED
C1, linked to T1:
Situation and action: Customer A opens job J1, which belongs to Customer A
and has approved status "Awaiting visit."
Expected behavior: Show "Awaiting visit" and its approval time. Customer B
cannot view J1.

C2, linked to T2:
Situation and action: The dispatcher approves a new customer-facing status
for J1 in the dispatch tool.
Expected behavior: On the next successful refresh, show that status and
approval time without separate portal entry.

C3, linked to T1:
Situation and action: The status refresh fails after a previously
successful refresh.
Expected behavior: Retain the last confirmed status and approval time,
label the update unavailable, and offer a way to contact the dispatcher.

C2 evidence/reviewer: compare source and portal status/time; dispatcher.
C3 evidence/reviewer: simulate failure, inspect values/warning/contact;
operations manager. First-load failure must show no invented status.
If portal is unavailable, contact route must be available outside it.
Offline access decision / exclusion / fallback owner: unknown.

Estimate deliverable: included work, effort/calendar ranges, responsibilities,
excluded and recurring costs, revision assumptions, scope-change approvals.
Handoff package: accounts, code/deployment, export/recovery, operating notes,
staff training. Acceptance owner and support transfer date: to assign.

UNKNOWNS
U1: Can the dispatch tool expose approved status and approval time through
    read-only access?
Owner: System administrator.
Next step: Inspect a sample export and vendor documentation with the
engineering partner before estimating the integration.

U2: How old may a displayed status be before staff must intervene?
Owner: Operations manager.
Next step: Agree a freshness rule and manual fallback before accepting
the refresh behavior.

ALTERNATIVE CHECK
First inspect whether the dispatch tool's customer view can meet T1 and
C1-C3. Record what works, what fails, and what remains unknown. No
capability is assumed here.
A configurable customer view may mean accepting its workflow limits.
A custom portal introduces software and integration ownership.
A staff-managed status email process may remain a useful fallback but
still requires a staff reply. Compare these tradeoffs against O1 and the
actual checks before choosing.

PROPOSED FIRST SCOPE
Customer access to an approved job status, the dispatcher's update path,
and unavailable-update handling. Defer the excluded capabilities in E1.
U1 could change the design or make T2 impractical. U2 determines when C3
requires staff action. Neither unknown is resolved by this example.

BUSINESS BENEFIT AND HANDOFF STILL TO AGREE
Passing C1-C3 would establish specific behavior, not customer adoption or
a fall in enquiry volume. Decide how to observe adoption and status
enquiries, including what evidence exists before launch. Agree who
approves business rules and acceptance, controls system access, and owns
status corrections and support after launch. Specify ownership of code
and hosting accounts, maintenance responsibilities, and ongoing costs.
No launch, estimate, or ownership agreement is implied by this fictional
example.

GUIDANCE BEHIND THE WORKSHEET
This worksheet is Wavelength's editorial adaptation of narrow GOV.UK
guidance written for government services. It is not a mandatory process
for private businesses.
Discovery: question proposed solutions, surface assumptions, and agree
exclusions.
https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
User needs: describe the user's problem and purpose from evidence; link
needs to stories with acceptance criteria and dependencies.
https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs
Technology: explore assumptions and interfaces; identify components to
build, buy, or obtain freely.
https://www.gov.uk/service-manual/technology/choosing-technology-an-introduction