# Project Kickoff Canvas

**Framework:** Project Kickoff Canvas  
**Use for:** Aligning a cross-functional team on scope, ownership, risks, and success criteria before substantive work begins. Works for product launches, operational initiatives, internal projects, and cross-team programs.  
**Time required:** 60–90 minutes with the core team (3–8 people). Filling it solo first and reviewing with the team is the most efficient approach.

---

## How to use this template

1. **Fill in Goal and Success Criteria first.** Everything else on this canvas is in service of those two sections. If you can't complete them clearly, you're not ready to kick off.
2. **Be explicit about what's out of scope.** The most valuable line on any project canvas is often the "What this project is NOT" row. It stops scope creep before it starts.
3. **Populate Stakeholders before Timeline.** You can't set realistic milestones until you know who has approval authority and who needs to be in the loop.
4. **Risks before Dependencies.** Risks are things that might go wrong. Dependencies are things outside your control that could block you. They're different and both need owners.
5. **Decision rights last.** The DACI or RACI row surfaces the conversations most teams avoid — who actually decides — and starting there creates conflict. Resolve scope and ownership first, then lock decision rights.

---

## Project context

**Project name:** _______________  
**Project owner:** _______________  
**Date of kickoff:** _______________  
**Target completion / ship date:** _______________  
**Version / iteration:** _______________

**One-sentence project description:**

> _______________

---

## §1 Goal and success criteria

**Problem this project solves:**

_______________

**Goal statement** *(what changes in the world when this project succeeds?)*:

_______________

**What this project is NOT** *(explicit out-of-scope)*:

_______________

**Success criteria** *(how will you know it worked? Be specific and measurable):*

| Criterion | Measurement method | Target | By when |
|---|---|---|---|
| 1. | | | |
| 2. | | | |
| 3. | | | |

**Minimum viable outcome** *(if you had to ship with half the resources, what would you cut?)*:

_______________

---

## §2 Stakeholders

**Who needs to know about this project and at what level?**

| Name / Role | Involvement | Decision authority | Communication cadence |
|---|---|---|---|
| | Accountable (doing the work) | | |
| | Decision-maker | | |
| | Reviewer / approver | | |
| | Informed only | | |
| | | | |

**Executive sponsor** *(who escalation goes to when the team is blocked)*:

_______________

**Key external parties** *(vendors, partners, customers involved in the project)*:

_______________

**Stakeholder risks** *(who is likely to become an obstacle? What is their concern?)*:

_______________

---

## §3 Timeline and milestones

**Project duration:** _______________

| Milestone | Description | Owner | Target date | Dependencies |
|---|---|---|---|---|
| Kickoff complete | Canvas signed off, team aligned | | | — |
| Discovery / scoping | Key decisions locked | | | |
| First deliverable | | | | |
| Review checkpoint | Stakeholder review + adjust | | | |
| Final deliverable | | | | |
| Retrospective | What worked, what to change | | | |

**Critical path** *(which milestones, if delayed, delay everything else?)*:

_______________

**Buffers planned** *(what contingency is built in, and where?)*:

_______________

---

## §4 Risks

*Risks are things that might go wrong that are currently inside your control to mitigate. Rate each: Low / Medium / High.*

| Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|
| 1. | | | | |
| 2. | | | | |
| 3. | | | | |
| 4. | | | | |

**Top risk that could kill this project:**

_______________

**Contingency plan if top risk materializes:**

_______________

---

## §5 Dependencies and blockers

*Dependencies are things outside your direct control that this project relies on. They require coordination, not just mitigation.*

| Dependency | Type | Owner (external) | Required by | Status |
|---|---|---|---|---|
| 1. | Technical / Resource / Decision / Approval | | | Confirmed / Pending / At risk |
| 2. | | | | |
| 3. | | | | |
| 4. | | | | |

**Blocker escalation path** *(if a dependency goes unresolved, who resolves it and how quickly?)*:

_______________

---

## §6 Decision rights

*Who decides what? Use this row to prevent the most common project failure mode: ambiguity about who has final say.*

| Decision | Driver | Approver | Consulted | Informed |
|---|---|---|---|---|
| Scope changes | | | | |
| Budget changes | | | | |
| Timeline changes | | | | |
| Major technical choices | | | | |
| Stakeholder communication | | | | |
| Go / no-go at each milestone | | | | |

**Tie-breaking rule** *(when the team disagrees and can't resolve it internally, how is it resolved?)*:

_______________

**Standing meeting cadence:**

| Meeting | Attendees | Frequency | Duration |
|---|---|---|---|
| Team standup / sync | Core team | | |
| Stakeholder update | Stakeholders + sponsor | | |
| Risk review | Core team | | |

---

## Alignment check

**Before finalizing this canvas, confirm:**

- [ ] Everyone on the core team has read the Goal and Success Criteria sections and agrees with them
- [ ] Out-of-scope items are written down, not assumed
- [ ] Each milestone has a named owner
- [ ] Each risk has a named owner and a mitigation plan
- [ ] The decision rights table has been reviewed (and any disagreements resolved)
- [ ] The executive sponsor is aware of the project and has agreed to the escalation role

**Open questions this canvas didn't resolve:**

1. _______________
2. _______________
3. _______________

---

*For governance structures referenced in §6, see the DACI, RAPID, and RACI templates in the decision-rights folder. Decision Infrastructure Guide on biztechprimer.com covers the decision-layer vocabulary in depth.*