How to Write a Project Kickoff Document in English

A kickoff document that jumps straight into a task list gives a team no shared understanding of why the project exists or what success actually looks like — this guide covers the structure that gets everyone starting from the same understanding.

Key Vocabulary

Problem statement — a clear, specific description of the problem the project is meant to solve, written so someone unfamiliar with the background understands why the project is happening at all before reading a single task. “The kickoff doc jumps straight to ‘we’re building a new onboarding flow’ without a problem statement — readers don’t know yet that it’s because 40% of new users are dropping off at the current signup step.”

Scope — an explicit statement of what is, and just as importantly what is not, included in the project, preventing the project from silently expanding as new ideas come up during execution. “The scope section should say explicitly that this project covers the signup flow only, not the broader account settings redesign — otherwise scope creep is almost guaranteed once people start noticing adjacent problems.”

Stakeholder — a person or team with a direct interest in the project’s outcome, whether because they’re affected by it, need to approve it, or are contributing to it, identified explicitly so nobody relevant is left out of key decisions. “We need to list the support team as a stakeholder here, not just engineering and design — this change will directly affect the tickets they handle, and finding that out after launch instead of before is avoidable.”

Success criteria — the specific, measurable conditions that define whether the project achieved its goal, stated concretely enough that everyone will agree, after the fact, on whether they were met. “Success criteria shouldn’t just say ‘improve onboarding’ — it should say something we can actually check afterward, like ‘reduce signup drop-off from 40% to under 25% within eight weeks of launch.’”

Out of scope — items explicitly excluded from the project, listed alongside the scope section specifically to prevent the same idea from resurfacing repeatedly as an assumed requirement during execution. “Add a mobile app redesign to the out of scope list — I’ve already heard it mentioned twice as if it’s included, and writing it down explicitly as excluded will save us from relitigating that later.”

Common Phrases

• “Does the problem statement actually explain why this project exists, or does it assume that context?”
• “Is this in scope, or should we add it to the out of scope list explicitly?”
• “Have we identified every stakeholder, or just the obvious ones?”
• “Are these success criteria specific enough that we’ll agree afterward on whether we met them?”
• “Should this be flagged as out of scope now, before it resurfaces mid-project?”

Example Sentences

Opening the document with a problem statement: “Problem statement: 40% of new users abandon signup at the payment step, based on the last quarter’s funnel data. We believe this is driven by a confusing multi-step form, and this project is scoped to address that specific step.”

Defining scope and out of scope together: “Scope: redesigning the payment step of signup, including form layout and error messaging. Out of scope: changes to the pricing itself, the broader account settings area, and mobile app parity — those are valid future projects, but not part of this one.”

Writing measurable success criteria: “Success criteria: reduce payment-step drop-off from 40% to under 25% within eight weeks of launch, with no increase in payment error rate. If we hit the drop-off target but error rate rises, we’d consider that a partial success requiring follow-up, not a clean win.”

Professional Tips

• Open with a concrete problem statement, not a description of the solution — a reader who understands the actual problem can evaluate whether the proposed solution makes sense, while a reader who only sees the solution has to take it on faith.
• Write scope as a specific boundary, not a general description of the project’s spirit — vague scope is the single most common source of scope creep during execution.
• List every relevant stakeholder at kickoff, including teams affected indirectly — discovering a missed stakeholder mid-project, after decisions are already made, is a much more expensive way to find out they should have been involved.
• Make success criteria measurable and specific enough to be checked objectively later — criteria that are open to interpretation guarantee a disagreement about whether the project actually succeeded.
• Maintain an explicit out of scope list and refer back to it during execution — it’s the most effective tool for keeping a recurring idea from quietly becoming an assumed requirement.

Practice Exercise

1. Write a problem statement for a hypothetical project in two to three sentences.
2. Draft a scope and out of scope pairing for that same project.
3. Write one measurable success criterion for the project.