How to present a project kickoff

To present a project kickoff, run a thirty minute meeting that settles six things in order: why the project exists now, what is in and out of scope, who owns each workstream, the plan to the first milestone, how success will be measured and how the team will work. Send the background beforehand so the room is not being briefed, and end on a slide of decisions the people present must make before they leave. A kickoff that ends with “any questions?” has presented a project; one that ends with five approved decisions has started one.

Send the background first

Atlassian’s project kickoff guidance is blunt about the most common failure: a kickoff should not be an “information broadcast”. Background belongs in a shared document sent ahead of the meeting, along with the questions you want the team to think about.

That changes what the deck is for. It no longer has to explain the whole project; it has to put the handful of decisions and commitments on screen clearly enough for the room to agree them. The project kickoff deck does this in nine slides for a fictional warehouse rollout called Orchard, which replaces four site systems with one platform by March 2027.

The 30 minute agenda

The table under this article sets out the agenda, with the minutes each item gets, what it must settle and the slide that carries it in the example.

It follows the outline Atlassian recommends for a kickoff: the background, why the project is being done, the scope, the action plan, who is doing what, how the team will work together and what success looks like. The example opens on why now rather than on the team introductions, because the reason not to wait is what makes everything after it urgent: the oldest system loses vendor support in June 2027, stock accuracy sits at 91 percent and every transfer needs a manual reconciliation.

Keep introductions short or do them in the pre-read. A room of thirty people each saying their name and role uses a third of the meeting.

Draw the scope line

The scope slide is the most important slide in a kickoff, and it needs an out list as well as an in list.

The example’s third slide lists four sites and six core flows as in scope, then transport and store systems as out, with the date the steering group agreed it and a line saying anything not listed is a change request. That last sentence does more to protect the plan than any number of status meetings. Atlassian’s guide to project scope makes the same point, recommending clear exclusions and constraints so the team stays focused on the agreed objectives, and cites Project Management Institute research that 52 percent of projects experience scope creep. What scope creep is explains how it happens through small additions rather than one large one.

The same slide carries the assumptions and constraints, and they are worth copying. Each site names one person to own its data cleanup, there are no promotions in the fortnight around a cutover, nothing goes live between mid November and early January, and the 3.1 million dollar budget holds a ten percent contingency with finance. Every one of those is a future argument settled in advance.

Name the scope date on the slide. When someone disputes scope six weeks later, “agreed with the steering group on 11 August” ends the conversation faster than a debate.

Put a name on every workstream

Every piece of work in the plan needs one person’s name beside it before the meeting ends.

The example gives platform, operations and change a lead each, with a weekly checkpoint and a risk log per workstream. Atlassian’s roles and responsibilities play explains why this matters at the start: defining roles at the outset sets clear expectations, avoids task overlap and reduces conflict. Its exercise is also a useful addition to a longer kickoff, because each person writes down what they think their responsibilities are and the team compares that with what others think.

A shared responsibility with no single owner is where projects stall. The lessons learned deck is the closing review of the same fictional Orchard rollout, and it traces a six week slip to causes that include no named data owner and no clause keeping the vendor’s named staff on the job. Both would have been visible on a kickoff slide that asked, workstream by workstream, whose name goes here.

Measure success before work starts

Write success as objectives with key results, each with a baseline. The OKR framework popularised by John Doerr defines an objective as what is to be achieved and key results as specific, time bound and measurable, so that you either meet them or you do not.

The example’s sixth slide carries five: stock accuracy from 91 to 98 percent at the first site, lines picked per hour up 15 percent within eight weeks, all four sites off their legacy systems by March 2027, item master duplicates under half a percent before each data load, and no more than four hours of dispatch downtime per site at cutover. Each has a progress column that says where it stands today, from “baseline set” to “3.1% today”, and a status. The data objective is already marked at risk on day one, which is exactly the honesty a kickoff needs. When the first project status report goes out, it reports against those rows instead of inventing new measures.

End with decisions, then write them down

The last content slide should be a list of decisions, each answerable yes or no, that the plan on the previous slides depends on.

The example’s eighth slide lists five, including confirming the first site and its cutover weekend, naming a data owner at each site by Friday, and signing off the budget. The slide says outright that without those five, the plan does not hold. That is the sentence that turns a presentation into a meeting.

Record the decisions as they are made, with a date and an owner, in the same form the team will use for the rest of the project. The approach in how to write meeting minutes works well for this: decisions and actions first, discussion only where it explains a decision.

Common mistakes

• No out list. An in scope list alone invites every adjacent request.
• Workstreams owned by a team rather than a person. A team cannot be chased.
• The full plan on one slide. Show the path to the first milestone; link the rest.
• Success measures without baselines. Improvement cannot be shown against a number nobody recorded.
• Ending on thanks. A kickoff with no decisions leaves the real start date to the first steering meeting.

Build it

The ownership slide is often clearest as an org chart. An org chart slide draws three levels: a root, a row of up to six, and up to four under each, so a sponsor, three workstreams and their leads fit comfortably. The org chart slide page shows the layouts. For the plan, the Gantt layouts hold 6, 8, 10 or 12 tasks depending on the layout, and they have no dependency arrows, so show the milestone dates as tasks rather than as links.

The guide to adding charts, maps and diagrams to slides covers both. A table can grow to 20 rows and 8 columns, which is enough for the success measures with a baseline, a target and a status.