That order is an argument, not a filing system. Slides 2 to 5 decide whether the meeting stays on topic: they set the problem, the finish line, the boundary, and what sits outside it. Get those four wrong and everything after is a discussion about a project nobody agreed to.
What are non-goals, and why does every plan need them?
A non-goal is work you could plausibly have included and are choosing not to. Not a hypothetical — a real, named piece of scope that a reasonable person in the room would assume was in. No Android app this phase. No migration of the historic data. No change to the pricing model.
Leave the slide out and the scope gets set by whoever speaks first. Someone asks whether the migration is included, you say probably not, and by the end of the hour it is in the plan with no time added for it. That is how a twelve-week project becomes a twenty-week one before it starts: not through a decision, but through three or four unchallenged assumptions in a room where nobody wanted to be the one saying no.
Writing them down inverts the burden. Adding the Android app is now a visible change to an agreed plan, and whoever asks for it has to say what comes out to make room. Expect this slide to draw more questions than any other in the deck. That is the slide working.
- Name work, not attitude: "no bulk import in v1" rather than "we are staying focused".
- Each non-goal should be something at least one person in the room expected to be included.
- Say when it comes back, if ever — phase two, not this year, never.
- Keep it readable from the back of the room without the presenter narrating it.
Why does every milestone need one named person?
One name. Not a team, not a function, not two people who will sort it out between them. A milestone owned by Platform is owned by nobody, because when it slips there is no single calendar the question lands in.
Two owners is zero owners. The second name is where accountability goes to be discussed.
The objection is always that the work is shared, and it usually is. Ownership and effort are different things. The owner is the person who knows the state of that milestone without asking anyone, and who is expected to put a hand up early when the date is at risk. Eight people can do the work. One person answers for it.
Put the name on the milestone slide itself rather than on a separate team slide. If a milestone has no name against it, you have either not staffed it or not decided — and both are worth discovering in the planning meeting rather than in the week it is due.
Should the timeline be dated milestones or phases?
Dates. Phases are what a plan looks like when nobody wants to commit yet.
A phase describes the kind of work, which everyone already knew. It carries no information about when anything lands, and it cannot slip, because there is nothing to slip against. Phases are self-justifying too: Discovery is over when the people doing Discovery say it is.
A dated milestone is falsifiable. "Data model signed off, 14 March" is either true on the 15th or it is not, and anyone can tell without a status meeting. Make each one a thing that exists rather than a state of mind — a document merged, an environment live, a contract signed, a first customer onboarded. Six to eight covers most projects. Past ten you are writing a work plan, not a deck.
- Name the artefact, not the activity: "pilot cohort live" beats "pilot phase".
- Land every date on a Friday or a month end; a Wednesday invites an argument about the Wednesday.
- Mark which milestones depend on someone else deciding, because those are the ones that slip.
- If a date is genuinely unknown, say so, and give the date by which it will be known.
How do you show risk without spooking the room?
Presenting risk badly is the fastest way to lose a plan you could have had approved. The two failure modes are opposite and equally common: no risk slide at all, which reads as naive or evasive, and fourteen risks in a traffic-light table, which reads as a project already in trouble.
Three or four risks. Each gets a specific consequence, a mitigation already in motion, and the name of whoever is watching it. A risk with an owner and a first action is a managed risk. A risk on its own is a warning.
Say the likelihood out loud rather than colouring a cell. "The vendor contract is the one thing that could push launch past March; legal has it now and we expect it back by the 20th" tells a room more than an amber square. Keep the risks you cannot mitigate on the slide too. Executives recognise a deck that only lists problems it has already solved, and they stop believing the rest of it.
What belongs in the deck, and what belongs in the document?
The task list, the resourcing model and the assumptions log go in a document linked from the last slide. If a slide needs a paragraph, it is a document page wearing a slide's clothes. The constraint is the point: being unable to fit the scope on one slide is usually how you find out the scope is wrong.
Slideable ships a 12-slide project plan template, one of 94 layout archetypes, and every slot has a character budget the box was drawn for — so the layout tells you when a sentence stopped being a claim. Slides reorder by dragging in the rail, which is also the deck's outline. Numbers get one of eight chart types, edited in place and drawn in the brand palette automatically, with no spreadsheet in the middle.
Common questions
- What should be in a project plan presentation?
- Twelve slides: the decision you are asking for, why now, what success looks like as a measurable outcome, what is in scope, what is explicitly out of scope, the approach, dated milestones, one named owner per milestone, dependencies on other teams, three or four risks, the cost in money and people, and the specific ask. Detail beyond that — task lists, resourcing models, assumptions — belongs in a linked document rather than on a slide. The deck is the argument for the plan, not the plan itself.
- How many slides should a project kickoff deck have?
- Twelve is the working number for a kickoff or plan approval, and it maps to one claim per slide with nothing doubled up. Fewer than ten usually means scope and non-goals have been merged into one vague slide, which is where meetings go wrong. More than fifteen means the work plan has leaked into the deck, and the room stops reading somewhere around slide nine.
- What is a non-goal in a project plan?
- A non-goal is a specific piece of work that someone could reasonably assume is in scope, which you are stating up front that you will not do — for example, no data migration, or no Android app until phase two. It is different from a risk or an assumption: it is a decision. Without a non-goals slide the scope gets set by whoever asks the first question in the meeting, and the plan grows without the timeline growing with it.
- How do you present project risks to executives?
- Show three or four risks, not fourteen, and give each one a concrete consequence, a mitigation that is already underway, and the name of the person watching it. Say the likelihood in a sentence rather than colouring a cell in a red-amber-green table, which reads as a project already in difficulty. Include at least one risk you cannot fully mitigate — a deck that only lists solved problems is one experienced executives stop trusting.
- What is the difference between a project plan deck and a project proposal?
- A proposal argues that the work is worth doing and is aimed at a decision to fund it, so it leans on the problem, the outcome and the cost. A project plan deck assumes the work is agreed and answers how it will be delivered: scope, non-goals, dated milestones, owners, dependencies and risks. The twelve-slide structure covers both, because a kickoff still has to re-earn agreement on what is being built before anyone commits a date.