Project Charter: One Page That Saves an AI Project

Three months into the project, two directors disagree about what it was supposed to deliver. Each is sure. There is a kickoff deck, a long email thread and a budget line. There is no single page that says what was agreed, so the argument is settled by seniority.

What a charter is for

A project charter is a short document, one or two pages, that says why a project exists, what it will deliver, who is responsible and what it may spend. It is agreed before the work starts and it is the thing people go back to when the project drifts.

It is short on purpose. A charter that runs to twenty pages has turned into a plan, and nobody will reread it at the moment it matters, which is the argument three months in about what was promised.

The usual failure is that it gets written as a formality. The goal says improve efficiency, the owner is a department, and the budget is to be confirmed. That document has the headings of a charter and settles nothing.

What it has to settle

The sponsor line carries the most weight. A project owned by a team has nobody who can approve a change, release more budget or call a halt. One person with that authority, who knows they have it, is worth more than a detailed plan.

What an AI project adds

An ordinary charter is not quite enough for a project built on AI, because some of the questions that sink these projects have no heading in the standard template.

The baseline. Write down how the process performs today, measured, before anything changes. Without it nobody can say whether the project worked, as set out in the gap analysis.

The data. Name the systems the project will read from, who owns each one, and whether personal information is involved. If it is, the charter should say what the legal basis is and whether an assessment is needed, which is the ground covered in a privacy impact assessment for an AI project.

The review points. Say where a person checks the output before it goes to a customer or into a system of record, and what happens to the cases the tool is unsure about.

The stopping rule. Decide now what result, cost or error would end the project. It is far easier to agree a stopping point before there is a team invested in continuing, and the reasoning is in deciding what would make you stop.

Where AI helps write it

Drafting from the conversation. The material for a charter usually exists already, scattered across meeting notes and an email thread. Turning that into the six sections is a quick first draft.

Pushing back on vagueness. Ask it to list every goal that has no number, every scope item that could be read two ways, and every assumption nobody wrote down. That list is more useful than the draft, because each item is a disagreement that would otherwise surface in month three.

Comparing with your last few projects. If earlier charters exist, checking the new one against them for missing sections takes seconds.

What stays with people

The sponsor, the budget and the target. Those are commitments, and a model will fill them in with plausible placeholders if you let it. A charter with an invented target is worse than one with a blank, because the blank at least gets noticed.

The sign-off. The sponsor should read the page and agree to it in a meeting, out loud. A charter approved by email reply is one nobody has read.

A charter also leads somewhere. Once it is agreed, the test of the idea is a proof of concept, and if an outside supplier is doing the work, the detail belongs in a statement of work. The risks you listed go on the risk register with an owner.

Frequently Asked Questions