# Project brief

Use this template to describe your project before the first analysis. Write in your own words; a few sentences under each point are enough, and any point can be left open. The grey hint under each heading says what helps.

**No formal specification is needed. Describe it in your own words, and the analysis and design turn it into a documented plan.**

- **Company:** 
- **Contact person:** 
- **Email or phone:** 
- **Date:** 

## 01 The goal and the problem

> What is going wrong or missing today, in business terms, and why it matters now: lost time, errors, delays, work that depends on one person.



## 02 Who uses it, and in which role

> Every group that will work with the system — sales, operations, finance, management, your customers — and what each of them needs to do or see.



## 03 The current process, step by step

> How the work runs today, from the first request to the finished result, including the steps that happen in email, chats or on paper.



## 04 The tools and data involved

> The systems, spreadsheets and services in use now, what data each one holds, and roughly how much of it there is.



## 05 What must change

> How you will know it works: which steps disappear, what is entered once, and what anyone can see without asking a colleague.



## 06 Must-haves and nice-to-haves

> What the first version cannot go live without, and what can follow later. Separating the two keeps the first version focused.



## 07 Constraints

> Deadlines and the reasons for them, a budget range if you have one, and the systems that must stay in place.



## 08 Access and sensitive data

> Which systems the work would need access to, whether a copy or a test account would be enough, and whether the data is personal, financial or otherwise sensitive — including whether you need an NDA.



## 09 Attachments

> Sample documents, screenshots of the spreadsheets you use, reports. Remove sensitive data first.



## What helps

- Describe what happens today, not only the feature you have in mind.
- Attach real examples: a typical order, a report, a screenshot of the spreadsheet, with sensitive data removed.
- Name who makes the decision and who will use the system every day.
- Say which requirements are fixed and which are open to discussion.

## What to avoid

- Designing screens and buttons before the process is clear.
- Listing every feature at the same priority.
- Leaving out the workarounds, such as the side spreadsheet or the chat where approvals happen. They often show where the problem is.
- Waiting for a complete document. A first version in your own words is enough to start.

---

When it is ready, send it to hello@healed-code.com with any attachments, or paste it into the form at healed-code.com/process-analysis. We reply within 24 to 48 hours.
