# Project brief template

A brief does not need to be long or finished. It needs to be specific. Fill in
what you know, leave the rest blank, and send it. The blanks are usually the
most useful part of the first conversation.

---

## 1. The problem

What is happening today that should not be, or not happening that should?

> 

Who has this problem, and how often?

> 

What do they do about it today, step by step?

> 

What happens if nothing changes?

> 

---

## 2. A real example

Attach or describe one actual case: the request that arrived, the spreadsheet
someone updates, the task that takes too long. Not the category. One instance.

> 

What are the exceptions to it? The cases that do not follow the normal path.

> 

---

## 3. What better looks like

If this went well, what would be different in three months?

> 

How would you know it had worked? A number, a time saved, a complaint that stops.

> 

---

## 4. What already exists

Systems, tools and data involved:

> 

Anything that must keep working, or must not be touched:

> 

Who owns access to those systems?

> 

---

## 5. Constraints

A date that matters, and why:

> 

Budget range, if you have one:

> 

Anything decided already, such as a platform, a vendor or a standard you must meet:

> 

---

## 6. People

Who decides?

> 

Who will use it day to day?

> 

Who on your side can answer questions while it is being built?

> 

---

## What happens when you send it

A person reads it, looks at what you already have, and comes back with the
questions that would change the scope. You get a written suggestion for the
first useful piece of work, with the assumptions it rests on.

Send it to hello@averolt.com, or paste it into the brief form at
https://averolt.com/contact