Skip to main content
Discuss

Free brief builder · fill in the fields, then copy or download the brief

AI Project Brief Builder

For project sponsors and product owners who need a clear brief before an AI project starts. Answer what you can; whatever you leave empty comes back as an open question.

Built by XONIK. The brief is built in your browser and nothing is stored.

Line illustration of a brief as a sheet of decisions, some still to be made, drawn as a ticked sheet, one row unanswered.

In brief

This tool turns your answers into a brief for an AI project that you can send to a team on Monday. You set out the purpose, the problem, how success will be measured, the scope, the data, the risks, who owns it, and how it will be run and retired. Anything you leave empty becomes an open question.

A short name people will recognize in a meeting and in a file name, such as the function and the task. Avoid the product name of any system you have not chosen yet.
Name the decision or the work product the output feeds, and the person who makes that decision or does that work. A purpose that cannot name a person is usually a technology looking for a use.
Describe how the work is done now and where it slows down or goes wrong, in the words of the people who have the problem. Say what it costs them in time, rework or errors, in words and not in a target.
Include the people who will use the output at their desks and the people outside the team who will see it or be affected by it, such as customers, patients or a regulator.
Write measures someone could check: what is counted, from where, compared with what, and by when. Describe the change in the work and not the technology. If you cannot write one yet, leave it empty and the brief will ask for it.
The tasks, teams, sites, document types or customer groups the first release will cover. Start narrower than feels useful, because what you add later is cheaper than what you withdraw.
Name the things a reader might assume are included and are not, such as a second site, a second language, or acting on the output without a person checking it.
Name each source, who owns it, how current it is, and the systems the project must read from or write to. Say whether you have looked at the live source or only a copy.
If the output is used in more than one way, choose the use with the highest risk, because that use sets the controls the whole project needs.
Legal, regulatory, security, contractual, staffing or technical limits that shape the design, such as data that may not leave a region or a system that cannot be changed this year.
Think about who is harmed by a wrong output, how soon anyone would notice, and which assumptions the plan depends on, such as access to the data or the time of a named expert.
A name or a role. This person can change the system, pause it or switch it off, and has agreed to. A committee or a vendor does not count.
The people whose sign-off is needed before it goes live, for example security, privacy, risk, legal or a business owner. Name the role if you do not know the person.
Who checks its output, what is watched, how often, and what triggers a review or a pause. Include who covers when that person is away.
What ends the system, who decides, how the old way of working is kept or restored, and what happens to the data and the records of what it did.
The stages in order, and the points at which someone decides whether to continue, change or stop. Put the decision points in even where the dates are not known.
On this page

What a project brief settles before anyone builds, and what this one cannot

A brief lets a team start work without first holding a meeting to find out what the work is. AI projects that stall often began with an enthusiastic proposal and no brief. Nobody had written down which decision it supports, who owns the system afterward, or what the business does on the day it gives a wrong answer.

The builder asks for those things in a fixed order and turns every gap into a named open question. It does not write the brief for you and it does not judge your answers. It cannot tell you whether the project is a good idea, feasible or safe.

Who writes the brief, and how long does a sitting take?

The sponsor or the product owner writes the first pass, usually alone, in one sitting about as long as a working lunch if they know the project well. Expect the sitting to slow down at the success measures, which is where the real thinking is. Do not invent an answer to move on. Leave it empty.

The second pass should be a meeting. Bring the person named as owner, someone from security or privacy, and the head of the function that will use the output, and work through the open questions together. A brief the owner helped fill in gets used; one written alone for others to approve tends to go unread.

Part of the briefThe question it settles
Purpose, problem and usersWhich decision or work it supports, how it is done now, and who is affected
Success measuresWhat is counted, from where, against what, and by when
Scope in and outWhat the first release covers, and what a reader might wrongly assume it covers
Data, systems and constraintsWhich sources, who owns each, and which legal or security limits shape the design
Where the output is usedHow much harm a wrong output could do, which sets the controls
Ownership and approvalWho can change, pause and switch it off, and who signs off first
Running, retirement and timelineWho watches it, what ends it, and where someone decides to stop

Which open questions does every brief carry?

Every brief ends with a list of open questions. Some come from fields you left empty, which is allowed and often right, since nobody can state the retirement rule on the first day. Some are always there, because they decide whether a project reaches daily use: whether the owner has agreed to own the system, whether the data has been checked against the live source and not an extract, and what the business does on the day the system stops or gives a wrong answer.

Send the brief ahead of the meeting and start with the open questions, not the purpose. Give each one a person and a date. The brief is ready for approval when every open question has an owner, even if some are not yet answered.

What to do with it on Monday

  1. 01

    Copy or download before you leave

    Nothing is stored. Copy the text, print it, or download the PDF, and keep the date in the file name.

  2. 02

    Send it with one request

    Ask each reader to answer the open questions that belong to them, and to skip the rest.

  3. 03

    Book the second pass

    A short meeting with the owner, the risk or security lead and the head of the function. Bring the open questions and nothing else.

  4. 04

    Rebuild it after the meeting

    Paste the new answers back in for a second version, and keep both so the changes of mind are on record.

When the brief builder fits, and when it does not

It fits when

  • A project is proposed and nobody has written down what it is for
  • You are about to brief a vendor, a delivery team or a steering group
  • The sponsor wants the gaps found before money is committed

Look elsewhere when

  • You need a specification or a contract; a brief is not either
  • The system is already built and needs a risk review
  • You are still choosing between ideas; rank them first

A brief of this length gives up detail for speed. It will carry a project to a decision, and the specification that follows will need far more.

What do people ask before using the AI project brief builder?

Does the builder write the brief for me or judge my answers?

It does neither. It places your answers in a fixed order, from purpose through to timeline, and turns every optional field you leave empty into a named open question. It cannot tell you whether the project is a good idea, whether it is feasible or whether it is safe.

What should I do with a field I cannot answer yet?

Leave an optional field empty rather than invent an answer. Its section drops out of the brief and a matching question appears under open questions, so the gap shows as something a person must answer. Nobody can state a retirement rule on the first day, so this is often right.

Is the finished brief enough to send to a vendor or a steering group?

It carries a project to a decision, or briefs a vendor, a delivery team or a steering group. It is not a specification, a contract or a risk assessment. The specification that follows needs far more detail, and the open questions are prompts, not an approval checklist.

What makes a good success measure in the brief?

One that someone could check: what is counted, from where, compared with what and by when. It describes a change in the work, not the technology. A measure such as launching the assistant by the end of the quarter tells a team when to stop, not whether it worked.

Related

Why AI pilots stall before productionThe hand-off between the team that proved a model and the team that must run it.ReportAI ConsultingFrom a short list of use cases to a running system with a named owner.ServiceAI Product Feasibility ChecklistTickable statements and a decision guide for an AI product idea: go, test first or stop.DownloadEnterprise AI Readiness ChecklistTickable statements for the areas that decide whether funded AI work reaches daily use.Download

Want a second reader for your brief?

Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.

Discuss your project with usMore free tools