Day 2: Turn a Project Idea Into a Clear Brief

The Concept

Projects rarely begin with a complete specification. They begin with a sentence in a meeting, a customer request, an executive priority, or a problem someone wants solved quickly. The project manager's first job is not to turn that sentence into a task list. It is to make the intended change clear enough that people can discuss it honestly.

A project brief is useful because it separates what is known from what is assumed. AI can help you create a first structure, but it cannot decide what the organisation actually means. Treat every generated statement as a draft until the right people confirm it.

What a strong brief clarifies

A useful brief answers five questions:

• Why are we doing this? The problem or opportunity.
• What will be different when we finish? The outcome, not just the activity.
• What work belongs in this project? The initial boundary.
• Who needs to be involved or informed? The stakeholder picture.
• What could change the plan? Constraints, assumptions, risks, and unknowns.

Weak briefs describe activity: build a portal, launch a campaign, improve onboarding. Strong briefs describe the change those activities are meant to create. AI is particularly helpful at exposing the difference because it can ask what each activity is supposed to accomplish.

Make uncertainty visible

One of the best uses of AI in project initiation is to separate facts from guesses. Ask it to label information as:

• confirmed,
• assumed,
• unknown,
• or requiring a decision.

This prevents a common project failure: an early assumption quietly becoming a commitment. If the brief says the new process will reduce handling time by 30 percent, the team should know whether that number comes from research, a target, or a hopeful estimate.

Use this today

Run the prompt with a real project and read the output with a red pen. Do not reward the model for sounding complete. Look for:

• invented dates,
• stakeholders it assumed without evidence,
• outcomes that cannot be measured,
• scope that is too broad,
• and decisions hidden inside ordinary sentences.

Then create a short confirmation list for the project owner. Your deliverable today is not a perfect brief. It is a better conversation about what the project is actually asking you to manage.

A practical review sequence

When you review the generated brief, work from the top down. First ask whether the problem is real and current. A project can have a beautifully written purpose and still be solving an issue nobody prioritises. Next check whether the intended outcome is visible to the people affected. If the outcome only describes what the project team will produce, the brief is still inward-looking.

Then check the boundary. Most early briefs are too generous because nobody wants to be the first person to say what the project will not cover. Use the out-of-scope section as an invitation to decide, not as a defensive wall. Some exclusions will be accepted immediately; others will reveal that the project needs a different sponsor, timeline, or budget.

Finally, read the open questions aloud. A question that sounds small on paper may block the entire plan. The project manager's job is not to remove every unknown before work begins. It is to make the important unknowns visible enough that the team can choose how to handle them.

Example: a better starting conversation

Imagine a sponsor says, “We need a better customer onboarding process before the next quarter.” That sentence contains a direction, but not yet a project. Better for whom? Which part of onboarding? What does better mean? What is the next quarter deadline based on? What cannot change?

AI can turn the sentence into useful questions and a first brief. It might suggest looking at completion time, support volume, customer confusion, internal handoffs, and policy constraints. Those are hypotheses, not facts. The project manager's job is to take the questions to the people who can answer them.

The brief becomes valuable when it changes the conversation from “build something better” to “reduce the time for new customers to complete the first step, without changing the compliance review, by the agreed date.” It gives the team something to challenge and improve.

Common brief failures

Watch for four patterns. The first is an outcome written as a deliverable: “launch a portal” instead of describing what the portal should change. The second is a stakeholder list that names departments but not decision-makers or affected users. The third is a deadline presented without explaining what is fixed about it. The fourth is a list of assumptions written as if they were confirmed facts.

Ask AI to review the brief specifically for these patterns. Then ask a human to review whether the language matches reality. A project brief should make disagreement easier to find, not make uncertainty look polished.

Use this today

A brief is a working agreement

The strongest briefs are not static documents. They are working agreements that let people notice when the project has changed. Keep a short change note beside the brief: what changed, why it changed, who agreed, and what consequence it has for scope, timing, or risk.

AI can help compare the current brief with an earlier version and summarise what moved. That is useful only when the source versions are accurate and the comparison is checked. Never let a generated diff become the official record without a human review.

A final check before sharing

Read the brief as if you are joining the project tomorrow. Can you tell why the work matters, what success means, what you own, and what is still undecided? If the answer is no, the brief needs another question or a clearer sentence. Do not solve the gap by adding detail that nobody has confirmed.

Share the brief in draft form and invite corrections to facts, not general approval. Specific questions produce better feedback than “does this look right?”

Use this today

• A brief is a conversation starter, not a promise.
• Name assumptions before they become commitments.
• Define the change you want, not only the work you plan to do.