Project Kickoff

Purpose: Align the team on goals, scope, roles, and communication before work begins

How to run this meeting

The single most important thing a kickoff accomplishes is not information transfer — it's shared commitment. Everyone in the room needs to leave with the same understanding of what success looks like, who is responsible for what, and how decisions will be made when things get hard. If you can't define those three things in the kickoff, the project will define them for you, usually at the worst possible moment.

Define success criteria before you talk about scope. Scope is a means to an end — the end is what you're optimizing for. Is this project a success if it ships on time, or if it achieves a specific business metric, or if users actually adopt it? These are different answers, and they will drive different tradeoffs. Identify the single decision-maker — the person who breaks ties when the team disagrees. This does not mean they make all decisions, but everyone should know who has final authority on scope, priority, and launch calls.

Establish the communication cadence explicitly during the kickoff, not as an afterthought. Decide how often status is shared, in what format, and who needs to receive it. Create a RACI (Responsible, Accountable, Consulted, Informed) for the major workstreams — it takes 15 minutes and saves hours of confusion later. End the kickoff by having each person state in their own words what they're leaving with. Misalignments surface here, not six weeks in.

Before the meeting

• Write a one-page project brief and share it 48 hours before the meeting
• Confirm all key stakeholders are invited and will attend (or send a delegate)
• Draft a preliminary RACI and share for review before the meeting
• Identify any dependencies or constraints that need to be visible from day one
• Prepare a draft timeline with major milestones — it will change, but starting with something is better than starting from blank
• Define what decisions need to be made in this meeting vs. what can be decided later

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 60–90 minutes

---

Project Overview

What is this project and why are we doing it now? Include the business context — what problem are we solving, and what changes if we do this well?

Project: Vendor Portal Rebuild Team: Crestline Platforms — Platform Engineering + Design

The current vendor portal was built in 2021 and was not designed for the self-serve onboarding flow we now need to support. Onboarding a new vendor takes an average of 11 days and requires 3 internal handoffs. This project rebuilds the portal as a self-serve experience, targeting a 5-day average onboarding time and zero internal handoffs for standard vendor types.

---

Goals

What does success look like? State measurable outcomes, not outputs. Every goal should have a way to know if you hit it.

• Primary: Reduce average vendor onboarding time from 11 days to 5 days or fewer
• Primary: Eliminate internal handoffs for the 4 standard vendor categories (covering ~80% of volume)
• Secondary: Reduce vendor support tickets related to onboarding by 40%
• Out of scope: Enterprise/custom vendor onboarding flows (handled separately in Q4)
• Not a success criterion: Number of features shipped; speed of execution

---

Stakeholders

Who is involved, and in what capacity? A RACI prevents the "I thought you were handling that" conversation.

---

Timeline

Major milestones and dates. These are commitments to communicate around, not exact predictions. Flag uncertainty explicitly.

---

Risks

What could go wrong? Name it now so you can monitor it — ignoring risk in a kickoff doesn't make it go away.

• Legal review timeline (High): Compliance sign-off on the self-serve data handling model is on the critical path. Dana has flagged 2-week turnaround as a best case. Mitigation: start review at discovery complete, not at dev complete.
• Vendor data migration (Medium): Existing vendor records need to be migrated into the new portal. Scope of migration work is not yet known. Mitigation: spike this in week 1.
• Design-engineering handoff (Low): Previous projects have lost time at the handoff. Mitigation: Suki and Elena to sync weekly during design phase.

---

Communication Plan

How does the team stay aligned? Define this explicitly so it doesn't become a free-for-all of Slack pings.

• Status update: Every Friday by 5pm, Marcus posts a 3-bullet update to #vendor-portal-project
• Weekly sync: Tuesdays 10am — Elena, Suki, Marcus; 30 minutes; recurring
• Stakeholder update: Every other Friday — brief email to Raj and VP of Ops with milestone status
• Escalation path: If a decision needs to be made that affects timeline or scope, Marcus is the decision-maker; if it affects budget, Raj is in the loop within 24 hours
• Project artifacts: All docs in Notion under "Vendor Portal 2025"; Jira for tickets; Figma for design

---

Action Items

Follow-up

Send a written summary of this kickoff — goals, RACI, timeline, and communication plan — to all attendees and informed stakeholders within 24 hours. This document becomes the project's source of truth for scope and commitments. If anything was unclear or disputed during the meeting, resolve it before sending the summary, not after.