Before an organisation goes hunting for a problem for AI to solve, what has to be true — and whose name is on the outcome when the machine's work turns out to be wrong?
Deloitte was paid about $440,000 to review an automated welfare-compliance system. When an expert read the report closely, the references fell apart: books that were never written, academics cited for papers they never published, and a quote attributed to a Federal Court judge from a judgment she never delivered. Deloitte later confirmed the report had been produced with the help of a generative AI system and refunded part of the fee. A review of an automated system — itself undone by unchecked automation.
The report was not about nothing. It reviewed an automated system government had used to police welfare compliance — a system that had already, unlawfully, cut off payments to real people. The AI-assisted review meant to hold that system to account fabricated its own evidence. Two failures, the same victims: the machine that caused the harm, and the machine brought in to check it.
Notice what did not fail. The technology worked in the narrow sense — it produced fluent, confident, professional prose. It simply was not true. AI projects do not succeed or fail on how clever the technology is. They succeed or fail on how they are managed.
Your course's answer to this failure is a single page: the project charter. It clarifies the problem being solved, the reason for adopting AI, and what success looks like. Each element stops a specific disaster.
| Charter element | What it forces you to answer |
|---|---|
| Problem statement | The business problem/need — must be about the business, not the technology |
| AI technology & objective | The solution (short description) and the main objective |
| Scope | What is in, and explicitly what is out |
| Business case & benefits | Why do this? Why now? What if we don't? How does it fit business targets? |
| Strategic goals | At least 3 OKRs with 2 KPIs each |
| Timeline | Initiating/Planning · Executing · Monitoring/Controlling · Closing |
| Partners, stakeholders & team | Who is involved, their function, and dedicated time per phase |
| Responsible AI & ethics | At least three ethical considerations, with detail |
| Budget per phase | Cost description and cost/price for each phase |
The most common way an AI project dies is that nobody stopped to ask whether it should exist at all. Your course frames initiation as three groups of questions (Comptia, 2023). Notice how few are about the technology.
The problem-framing toolkit the course names sits alongside these: Design Thinking (creative problem solving), Brainstorming, PESTLE or SWOT analysis, Market Research, the Project Charter, 5W2H, and Change Management frameworks. And underneath all of it, the oldest idea in the discipline: the PDCA / PDSA cycle — created by Walter Shewhart in the 1920s, made famous by W. Edwards Deming in 1950s Japan — which prioritises measurement above all: measure results with real data, then repeat what works and drop what doesn't.
The charter is not bureaucracy — it is the cheapest insurance an AI project can buy, and the most commonly cancelled. Start with the problem and a named owner, not the technology. A project that ships fluent, confident output nobody checked has not succeeded. It has failed efficiently.
List the core elements of an AI project charter, and state the single rule that governs the problem statement.
Name the three lenses of AI-project initiation questions, with an example from each.
Where did the PDCA/PDSA cycle come from, and what does it prioritise?