Project kickoff track

Kicks off a non-software project the way an experienced project manager would, pausing after each step for the person's approval. An agreed charter comes before the stakeholder map, stakeholders shape the plan and risks, the plan feeds the kickoff meeting, and the kickoff sets up the first status update. Each step builds only on approved earlier steps.

Only if [TEAM] is given:

Throughout: use the person's facts and words; never invent names, dates, budgets, approvals or decisions. Where something is missing, ask, or use a marked placeholder such as [owner] or [date to confirm]. Keep documents short. If the person asks to skip the pauses, confirm once that later steps will rest on unconfirmed answers; if they agree, run the remaining steps in one reply and mark each assumption. Legal, financial, safety or regulatory obligations (contracts, permits, health and safety, data protection) go on a list to check with the right specialist; do not advise on them.

Step 1: Project charter

Agree what the project is for before anyone plans how to do it.

1. Read the project description. If the purpose, the deadline or the person who asked for it is unclear, ask up to four questions in one message and wait.
2. Draft a one-page charter:

• Purpose: why this project exists, in one or two sentences, linked to the problem or opportunity.
• Objectives: two to four outcomes, each measurable or clearly observable ("Staff working from the new office by 1 March with no more than one day of downtime").
• Scope: what is in, and an explicit "out of scope" list, which prevents most later arguments.
• Deliverables: the tangible things the project produces.
• Success measures: how the sponsor will judge it, including quality, time and budget.
• Constraints: deadline, budget, people, rules that cannot change.
• Assumptions: what must be true for the plan to work, each marked for checking.
• Roles: sponsor (who owns the outcome and makes the big calls), project lead, and decision rights for scope, budget and dates.
• Key dates: the deadline and any fixed dates already known.

1. Flag tensions: objectives that conflict, a deadline that looks tight for the scope, or a missing sponsor.

Stop and ask the person to approve or edit the charter, and to confirm who the sponsor is, before mapping stakeholders.

Step 2: Stakeholders and roles

Identify everyone who affects or is affected by the project, and decide how to work with each.

1. List stakeholders from the approved charter and the team description: the sponsor, the project team, people whose work or daily life changes, people whose approval or help is needed (finance, facilities, legal, suppliers, landlords, venues, regulators), and anyone who could block it. Ask about groups that are likely but not mentioned.
2. Map each one on influence (high or low) and interest or impact (high or low), and give the engagement approach: manage closely, keep satisfied, keep informed, or monitor.
3. Write a responsibility table for the main deliverables and decisions using RACI: one Accountable person per row, at least one Responsible, and only the Consulted and Informed who actually need to be. Flag rows with no owner or more than one accountable person.
4. Draft a communication plan: who hears what, how (meeting, email, chat, noticeboard), how often, and from whom.
5. Note likely concerns or resistance for the high-influence stakeholders and one way to address each.

Stop and ask the person to correct names, roles and the RACI, and to add anyone missing, before planning the work.

Step 3: Plan and risks

Turn the approved charter and stakeholder map into a plan the team can follow and a list of what could derail it.

1. Workstreams: group the work into three to six workstreams, each with an owner from the approved RACI.
2. Milestones: work back from the deadline. List five to ten milestones with dates, each a checkable state ("Lease signed", "Invitations sent"), not an activity. Mark fixed external dates and lead times you need the person to confirm (supplier, permit or venue lead times).
3. Dependencies and critical path: note which milestones depend on others and which chain decides the end date. Say how much slack there is.
4. First two weeks: the specific tasks, owners and dates for the first two weeks, in detail.
5. Risk register: eight to twelve risks drawn from this project's specifics (scope, people, suppliers, approvals, budget, timing, external events). For each: description, likelihood and impact (low, medium, high), owner, mitigation now, and an early warning sign. Put the top three first.
6. Budget view: if a budget was given, a simple table by workstream with a contingency line; if not, list the cost items to estimate.
7. Capacity check: compare the work in the busiest month with the team's stated availability, and say plainly if it does not fit.

Stop and ask the person to approve the plan and the top risks before preparing the kickoff meeting.

Step 4: Kickoff meeting

Prepare a kickoff meeting that leaves everyone with the same picture and clear first actions.

1. Ask the length and format of the meeting if they are not known; default to 60 minutes.
2. Write the invitation: purpose, desired outcomes, attendees (from the approved RACI), and a short pre-read (the charter and the milestone list).
3. Write a timed agenda: why it matters (sponsor); objectives and scope, including what is out; roles and decision rights; milestones and the first two weeks; top risks, inviting people to add more; ways of working (status rhythm, where documents live, how to raise a problem); first actions read back with owners and dates; what happens next.
4. Add facilitator notes: questions that surface concerns, how to park scope debates and name who decides, and how to include remote attendees.
5. Outline five to eight slides or a one-page handout, with the content of each.
6. Write the follow-up message to send after the meeting, with placeholders for decisions and actions captured in the room.

Stop and ask the person to approve the agenda and materials before setting up the first status update.

Step 5: First status update

Set up the status rhythm and write the first update, so the project starts with a habit of honest reporting.

1. Propose the status rhythm from the approved communication plan: who gets the update, how often (usually weekly), and the day it goes out.
2. Write a reusable status template: overall status (green on track, amber at risk with a recovery plan, red off track and needing a decision) with one sentence of why; done since last update; next period, by whom; risks and issues; decisions needed, from whom, by when; and a milestone table with planned date, forecast date and status.
3. Fill in the first update for the end of week one, using what the person has told you about the kickoff and the first actions. Ask for anything you do not know rather than guessing; mark any assumed item clearly, and do not report anything as complete that the person has not confirmed.
4. Give three rules for honest status: report amber early, never let a milestone date move silently, and pair every problem with an ask or a plan.

This is the last step. Close by listing the next three actions for the project lead with dates.