Skip to content
steelabs

Template

Project discovery brief

Turn a vague request into a focused first engagement: problem, constraints, evidence, exclusions and decisions needed.

Download editable Markdown

How to use this

Useful for: Product owners preparing a first conversation about software delivery, quality or an AI workflow.

  1. Describe the observed problem and its consequence before specifying a tool. Slow releases and a new test framework are not interchangeable descriptions of the same need.

  2. State what is already available and where it can be reviewed. Include a safe preview or a redacted sample rather than putting production credentials into an enquiry.

  3. Separate fixed constraints from preferences. A statutory date, a buyer requirement and a hoped-for launch window affect scoping differently and deserve clear ownership.

  4. Agree the decision the first engagement should support. A small assessment or pilot can answer a question without committing the team to a much larger implementation.

Scope and limitations: Submitting a brief starts a scope discussion. It does not commit either party to a price, schedule, legal conclusion or specific outcome.

Document preview

# Project discovery brief

## Problem and consequence
- Product or workflow and its users:
- Observed problem, with a recent example:
- Consequence for users or the delivery team:
- What a useful first improvement would look like:

## Current arrangement
- Existing application / stack / integrations:
- Available requirements, tests and operational evidence:
- Team ownership and decision makers:
- Reviewable preview or redacted artifact:
- Data classification and access constraints:

## Constraints
- Fixed date and why it is fixed:
- Scope that must remain unchanged:
- Budget range or spending limit:
- Supported clients, roles and organisations:
- External approvals or specialist reviews required:

## First engagement
- Decision to support: diagnose / test / build / evaluate / hand over
- Proposed smallest useful scope:
- Expected artifact and acceptance criteria:
- Exclusions:
- Who reviews the result:
- What would make further work unnecessary:

## AI workflow, if relevant
- Inputs, desired output and permitted actions:
- Independent examples of good and unacceptable results:
- Human approval and fallback:
- Provider, data handling and operating costs to investigate:

Example — fictional: a team wants reliable invitation releases. The first scope is a focused review of the invitation journeys, role boundaries and test data. The deliverable is a plan, reproducible findings and a summary for the release owner. Billing, a full security assessment and an application rewrite are excluded. The team decides whether a wider automation engagement is justified after reviewing that evidence.

Keep secrets and personal records out of the brief. Describe the approved access arrangement and provide sensitive evidence later through the agreed channel.

Read alongside this worksheet

Get help applying itAll resources