A requirements brief for an AI project

I once asked a carpenter I know to make me a cabinet. All I said was: "Could you make me something neat, a little modern?" Two weeks later it arrived, solid wood, a lovely finish, but too tall for the corner I had in mind, and the shelves did not quite fit the things I needed to store. The carpenter did nothing wrong. I was the one who never stated the brief clearly.

I tell the cabinet story because most of the trouble I have observed in AI projects begins in exactly that place, only dressed in technical clothing.

What a requirements brief for an AI project is

Before an engineering team writes its first line of code, it needs something called a requirements document. Product people usually call it by two names: the BRD (Business Requirements Document) states what the business wants to achieve, while the PRD (Product Requirements Document) describes what the system must be able to do to achieve it.

You can picture it as the construction drawings of a house. The drawings do not just say "build me a beautiful house". They state how many rooms, what load it must bear, which way the door faces, and when the work counts as accepted. A good requirements document for an AI project does the same: it ties the business goal to the real workflow, to constraints such as speed, security and compliance, and to a measurable acceptance criterion, rather than stopping at a general wish.

The distance between a clear brief and a vague one is not as small as we think. The Pulse of the Profession 2014 survey from the Project Management Institute (PMI) found that nearly half, 47%, of unsuccessful projects were due to inaccurate requirements management. A great many projects collapse not because the team is weak or the tools are poor, but because at the start nobody wrote down clearly enough what was actually needed.

How this applies to running a business

Suppose you want to use AI to handle customer care email. If the brief is only "let AI answer the emails quickly", we are repeating the cabinet story. A clear requirements document forces us to answer four questions before starting: what is the goal (bring average response time from eight hours down to under two), how does the work flow (AI drafts, a staff member approves every order above a certain value), which constraints must not be broken (no customer data exposed, a reply within a few seconds), and when does it count as done (95% correct on an approved set of questions).

The value of a requirements document lies not in how thick or thin it is, but in the way it presses both the person in charge and the engineering team to agree on the same destination before the first money is spent. Once those four answers are on paper, most of the costly misunderstandings have been cleared at the meeting table, instead of being discovered after the cabinet is already built.

For your most recent technology project, if you had to write the brief on one page, with the goal, the workflow, the constraints and a measurable threshold for done, could you write it straight away, or is it still a general wish?