A project kickoff presentation should leave the team with a shared scope boundary, named responsibilities, and a first checkpoint. Use the meeting to settle the choices that affect the next work—not to read the entire project plan aloud. A concise agenda and a visible decision record are more useful than a long deck of background slides.
Consider a fictional internal request-portal project. The first release will let employees submit equipment and travel requests, and let approvers accept or return them. The kickoff needs to settle whether access requests also belong in that release.
The agenda and scope table below can become a project kickoff slide draft from text in Presenti. Add your actual project inputs before generating it, then keep the meeting’s decisions in the slides or the team’s decision log.
A 30-minute kickoff agenda you can adapt
Send the agenda with a short project brief beforehand. Attendees should know which decision needs their input and which material is background. If you expect an unresolved debate to take fifteen minutes, give it that space instead of burying it under introductions.
| Time | Discussion | Output |
|---|---|---|
| 00:00–04:00 | Why this project exists and who it serves | One agreed project purpose |
| 04:00–12:00 | First-release boundary and access-request choice | In-scope, out-of-scope, and open item recorded |
| 12:00–18:00 | Responsibilities and decision rights | Owner for delivery, acceptance, and the unresolved dependency |
| 18:00–25:00 | First checkpoint and its dependencies | Output, acceptance condition, and target date |
| 25:00–30:00 | Read back decisions and confirm next actions | Decision log plus next meeting date |
This is an example schedule, not a universal rule. A cross-company kickoff may need separate working sessions for contracts, security, or technical design. Keep those meetings explicit rather than stretching the kickoff into an all-purpose workshop.
Make the scope choice visible
“Build a request portal” leaves too much room for interpretation. Put the release boundary on a slide, then show the unresolved choice in a separate row. The fictional team starts with this input:
| Item | Initial position | What must be decided |
|---|---|---|
| Equipment request | First release | Required fields and approval role |
| Travel request | First release | Approval handoff to finance |
| Access request | Undecided | Include manual approval, or defer until the identity integration is understood? |
| Automatic provisioning | Outside first release | No commitment in this kickoff |
The sponsor chooses to defer access requests because the receiving team and integration work are not yet defined. Record both the choice and its reason: “Access requests excluded from release one; IT will estimate the work before the next scope review.” Do not translate “deferred” into “coming soon” on a later slide.
Replace the org chart with three responsibility questions
Name who runs the work, who accepts the result, and who can change the scope. In this example, the delivery lead coordinates the build; the operations manager accepts the pilot against its criteria; the sponsor decides whether a new request type changes the release boundary. A finance contact supplies travel-approval rules, but does not automatically become the project owner.
If you use RACI, include the action beside the initials. “Accountable: sponsor” is less informative than “Sponsor approves changes to the first-release scope.” For dependencies, include the receiving owner—not just the person who sends a request.
PMI’s launch-meeting guidance includes objectives, scope inclusions and exclusions, strategy, risks, assumptions, and task responsibility. A kickoff deck brings those topics into the conversation; it does not replace project authorization or a detailed plan.
Define what the first checkpoint will prove
The team’s first checkpoint is a test of the equipment-request path, not “prototype complete.” A pilot employee must be able to submit a request, an approver must be able to return it with a reason, and the employee must be able to find the result. The operations manager will observe the test and decide whether the path is ready for a small pilot.
Put the prerequisite beside the date: finance must supply the approval rule, and IT must provide test accounts. If either is late, the team revisits the checkpoint rather than silently compressing the test. For later milestones, give the audience the same output-plus-acceptance pattern. Before committing to that checkpoint, a capacity-planning presentation can make the required work and genuinely available team hours visible together.
Read back this decision record before closing
The presenter can finish the meeting with the following record, completed live:
Decision: Release one includes equipment and travel requests. Excluded: Access requests and automatic provisioning. Reason: The access-request owner and integration effort are unresolved. Next action: IT estimates the access-request path for the next scope review. First checkpoint: Submit, return, and retrieve one equipment request. Acceptance owner: Operations manager. Dependencies: Test accounts and finance approval rules. Next review: [date and meeting owner].
Circulate the record after the meeting, along with the slides. New teammates should be able to distinguish the agreed boundary from ideas raised during discussion. When something changes, update the decision with the reason and owner rather than erasing the history.
Build the kickoff deck in Presenti from the agenda, boundary table, and checkpoint. A useful deck is one the team can refer to when the first scope question arrives—not one that merely looked polished during the meeting.
