Team and business context

What you will be able to do

Handle the parts of an AI project that are not technical but decide whether it succeeds. Then write a one-page project brief, the kind of document that teams use to agree on a project before they build it.

Before you startWhat to know and to have readyAbout 40 minutes

What you need to know

• The four questions that frame a problem, from Problem framing: Four questions that frame a problem.
• The steps from baseline to monitoring, from From baseline to deployment: The lifecycle, with its decisions.
• The roles in a project team, from One project, many roles: The team.

What you need

• Your problem frame, under ## Problem frame in notes.md, from Problem framing: Guided practice: frame a second problem. The brief in this lesson asks the same questions.
• This lesson adds the heading ## Project brief.

Stakeholders: who needs what

You met the word stakeholder in One project, many roles: a person or group who is affected by the project or can make decisions about it. Each stakeholder needs different information. For the ticket project:

Stakeholder	Needs to know	How often
Ruth, director	Cost, risk, time saved, and whether to continue	Monthly, one page
Co-ordinator	How to check suggestions, and what to do when the AI is wrong	Before the start, and when it changes
Support teams	Why some tickets arrive wrongly sorted, and how to report it	Before the start
Lena, privacy officer	Which personal data is used, where it goes, and how long it is kept	Before any data is used
Customers	Nothing new, if their tickets are answered faster and correctly	—

A common mistake is to tell everybody everything. A director does not need the model’s details. A co-ordinator does not need the budget. Give each stakeholder what they need to do their part.

Requirements: what it does, and how well

A requirement is something that the system must do or must be. There are two kinds:

• What it does: “Suggest a team and a priority for every new ticket.” “Let the co-ordinator change a suggestion.” “Record every change.”
• How well it does it: “A suggestion appears within 2 seconds.” “At least 95 of 100 urgent tickets are marked urgent.” “It costs under a fixed amount each month.” “Card numbers are removed before tickets are stored for training.”

The second kind is easy to forget, and it causes most surprises after release. A correct suggestion that takes 30 seconds is useless to a co-ordinator with 300 tickets a day.

Documentation: three short documents

Good AI teams write short documents, and keep them current:

1. A project brief (one page): the frame, the success measures, the stakeholders, the requirements and the risks. Everybody agrees on it before the work starts. You write one at the end of this lesson.
2. A decision log: one line for each important decision: the date, the decision, who decided, and why. For example: “Week 8: urgent tickets use keyword rules, not the model. Decided by Omar. Rules caught 97 of 100 urgent tickets, the model 89.” When somebody asks “why did we do this?” a year later, the answer is there.
3. A system fact sheet: what the system does, which data it learned from, its test results, its known limits, and who owns it. Many teams call this a model card. For example: “Known limit: tickets in languages other than English are not supported.”

Privacy: tickets contain people

Support tickets contain personal data: names, email addresses, home addresses, order numbers, and sometimes the full number of a payment card. Before the team uses old tickets to train a model, Lena asks:

• Do we need it? The model needs the words that describe the problem, not the customer’s name. Remove what is not needed. This is called data minimisation.
• Is something dangerous in it? Card numbers must never be stored in training data. They are removed automatically before use.
• Where does it go? If an outside provider processes the tickets, the contract must allow it.
• How long is it kept, and who can see it? The rules must be written down, and followed.

Privacy laws are different in each country. A privacy officer or lawyer decides what the law requires. The technical team builds what they decide, and must ask before using personal data, not after.

Uncertainty: say what you know, and how sure you are

Every result in AI work has uncertainty. A test on 1,000 tickets is not a promise about the next 100,000. Compare two ways to report the same result to Ruth:

Weak: “The model is 91% accurate.”

Strong: “On 1,000 recent tickets, 91 of 100 went to the correct team, compared with 74 for simple keyword rules. For warranty tickets, we tested only 70, so we are less sure about those. Results will fall when we sell new products, and our weekly check will show it.”

The strong version says what was measured, compares it with the baseline, says where the evidence is weak, and says what could change. It does not make the result sound worse. It makes it trustworthy. A director who hears only “91%” may expect 91% forever, and lose trust at the first bad week.

Guided practice: write a project brief

A new organisation needs your help. A university’s IT help desk receives about 3,000 tickets a month from students and staff: passwords, Wi-Fi, software, computers, and exam systems. Three people sort them by hand. In exam weeks, tickets about the exam system wait too long. The head of IT asks: “Can AI help?”

Write a one-page brief for this project. Do not name any tool, model or product. The aim is to agree on the problem first.

1. In notes.md, add a heading: ## Project brief.
2. Copy the template below.
3. Fill in every line. Where you would need information from somebody, write the question and the person.
4. Read your brief, and remove every tool or product name.

Project:
User(s):
Decision that it improves:
Data that exists (and questions about it):
Errors and their cost:
  -
  -
Success measure (as a number):
Could it be solved without AI? How?
Baseline to compare with:
Stakeholders and what each one needs:
Requirements: what it does:
Requirements: how well:
Privacy questions:
Roles needed:
Biggest risk:

Show an example brief

• Project: sort IT help desk tickets.
• User(s): the three help desk staff. Also students and staff, who wait.
• Decision: which group handles each ticket, and whether it is urgent.
• Data: about 3 years of tickets with the group that solved them. Question for the help desk lead: were tickets moved between groups, and is the final group recorded?
• Errors: an exam-system ticket marked as normal during exam week → a student may miss an exam (very high cost). A ticket sent to the wrong group → a few hours of delay (medium).
• Success measure: 99 of 100 exam-system tickets in exam weeks are marked urgent. Sorting time falls by half.
• Without AI: a separate “exam problem” button on the help page in exam weeks, sent directly to one person.
• Baseline: keyword rules, such as “exam”, “password” and “Wi-Fi”.
• Stakeholders: head of IT (cost, risk), help desk staff (how to check), exam office (exam-week rules), data protection officer (student data).
• What it does: suggests a group and urgency, and lets staff change it.
• How well: suggestion in under 2 seconds. Works for tickets in the university’s two teaching languages.
• Privacy: tickets contain student IDs and sometimes health information for exam extensions. Can those be removed before use?
• Roles: help desk lead (SME), a data analyst or data scientist, a developer for the help desk system, the data protection officer.
• Biggest risk: exam-week tickets are rare in normal weeks, so there may be too few examples to learn from.

Check: your brief has a number in the success measure, at least one way without AI, and no tool names.

Common mistake

Hiding uncertainty to win approval

Symptom: to get the project approved, the team reports “95% accuracy” without the details. After release, a bad week brings results of 85%. The director feels misled, and stops the project.

Cause: the first report made the result sound certain. When reality differed, trust was lost, not because the system was bad, but because the promise was wrong.

Fix: report every result with what was measured, the baseline, where the evidence is weak, and what could change it. Agree in advance what happens when results fall, for example “If the weekly check falls below 42 of 50, we return to suggest-only mode.”

Check your understanding

The model sorts tickets correctly, but suggestions take 30 seconds. Which kind of requirement failed, and why does it matter?

Show the answer

A “how well” requirement: speed. The system does the right thing, but the co-ordinator sorts hundreds of tickets a day and cannot wait 30 seconds for each one. They will stop using it. A correct system that people do not use has no value.

Check your understanding

Why should the technical team ask the privacy officer before they train on old tickets, and not after?

Show the answer

Because once personal data is copied into training data, sent to a provider, or learned by a model, it is hard or impossible to remove. If the use was not allowed, the damage is done. Asking first costs a meeting. Asking after can cost a retrained model, a legal problem, and the trust of customers.

Recap

• Give each stakeholder the information that they need, not everything.
• Requirements say what the system does and how well. The “how well” kind causes most surprises.
• Keep three short documents: a project brief, a decision log and a system fact sheet (model card).
• Ask about personal data before you use it. Remove what is not needed.
• Report results with what was measured, the baseline, weak spots and what could change.

Next, in Module 4, you turn your chosen route into a study plan, starting with how to read the curriculum.

Next: Read the curriculum