Project Kickoff Checklist: What to Do Before Work Begins
Most projects don’t fail on day ninety. They start going wrong in week one, when nobody is sure who approves what, the budget is a number somebody mentioned in a meeting, and half the team is still waiting for access to the shared drive. By the time the problem is visible, it is expensive to fix.
The kickoff is the cheapest point to prevent that. It doesn’t need to be long or formal, but it does need some groundwork before the meeting and a few decisions made on purpose instead of by default. This checklist covers what to sort out before work begins, in roughly the order that tends to work.
Define the goal, scope and budget
Start with one or two sentences on why the project exists and what finished looks like. Skip the mission statement. You want something a new team member can read in ten seconds and repeat back. “Replace the old booking form so customers can reschedule without calling us” works. “Improve the customer experience” doesn’t.
Then write down what is not included. It feels awkward this early, but an exclusions list settles more arguments later than almost anything else in the plan. If the new booking form won’t touch the invoicing system, say so now.
Break the work into deliverables you can point at, put a date next to each one, and check those dates against reality. If a task depends on someone outside the team, such as a client sending content or legal reviewing a page, write down that dependency and its date too. Late input is one of the most common reasons schedules slip, and it rarely makes it onto the plan.
For the budget, keep it simple: the total, what is already committed, and who can approve extra spend. Setting aside a small contingency is much easier to defend before the project starts than after the first overrun.
Name roles and decision-makers
Name one owner for the project and one approver for each deliverable. On a small project they are often the same person, but write it down anyway. A short table of who is responsible, who signs off and who just needs to be kept in the loop is plenty. You don’t need a formal RACI chart unless your organization expects one.
Also decide how disagreements get settled. Who has the final say on scope changes? On design choices? On spending? Having that answer before the first disagreement saves a surprising amount of friction. It also helps to ask for feedback to be gathered by one person before it reaches the people doing the work, so they aren’t trying to reconcile five different opinions.
Get the paperwork done first
If anyone outside your company is involved, such as a freelancer, an agency or a supplier, get the agreement signed before they start. It is tempting to let the work begin on the strength of an email thread, especially when the deadline is tight. That is usually when having it in writing matters most.
At a minimum, the agreement should cover what is being delivered, the fees and payment dates, who owns the finished work, confidentiality, how many rounds of revisions are included and how either side can end the arrangement. You rarely need to write all of that from scratch. Starting from a set of contract templates is quicker than a blank page and makes it less likely that a clause gets forgotten. Contract rules differ by country and by type of work, so have a lawyer look over whichever version you settle on once, then reuse it.
Attach your scope summary to the agreement. If the work changes later, the change goes into a short written amendment instead of a debate about what was promised.
Set up tools and access
This is the step that gets skipped, and it is usually the first thing that annoys people. Make a list of every tool the project needs: the task board, shared folders, design files, the code repository, the chat channel. For each one, decide who needs access and at what level. Most people only need to view or comment. Fewer need to edit, and almost nobody needs admin rights.
Give everyone their own account where the tool allows it. Shared logins make it impossible to tell who changed what, and they are a pain to clean up later. When a shared login can’t be avoided, for example a hosting panel or a company social media account, resist the urge to paste the password into a chat thread. A team password manager lets you keep those credentials in one place, share them with only the people who need them, and see who has them. Turn on two-step verification wherever it is offered, and make a note to change any shared password when someone leaves the project.
Keep a simple access list with the person, the tool, the level and the date added. It takes a few minutes to maintain and makes wrapping up the project much easier.
Plan communication and think about risks
Pick one place for day-to-day questions and one place for decisions. They can be the same tool, but they shouldn’t be the same thread. Decisions buried in a chat history get lost, and someone ends up asking the same question three weeks later. Agree on a rhythm too: a short weekly check-in, a written status update, and a clear idea of what counts as a blocker that should be raised straight away. If anyone works in a different time zone, set the overlap hours now.
You don’t need a formal risk workshop. Ten minutes at the end of the kickoff is enough. Ask the team what is most likely to slow things down, and what would hurt the most if it happened. Write the top five in a risk log with an owner next to each one. Typical entries are a key person being unavailable, a dependency arriving late, unclear requirements in one area, or a tool that hasn’t been approved yet.
Go back to the list every couple of weeks. A risk log nobody looks at is just another document.
Run the kickoff and use the checklist
By this point most of the content is already written, so the meeting itself can stay short, around 30 to 45 minutes for a small project. Walk through the goal, scope and exclusions, the timeline, roles, the communication plan and the top risks. Leave time at the end for questions, because the most useful ones tend to come up when people hear the plan said out loud.
Afterwards, send a short summary with the decisions made and the open questions, each with a name and a date. That message becomes the reference point when someone later asks what was agreed.
Before the meeting
● Project goal and exclusions written down
● Deliverables, dates and dependencies listed
● Budget and approval limits agreed
● Owner and approvers named
● Agreements signed where outside parties are involved
● Tools chosen, accounts created and access recorded
● Communication channels and check-in schedule set
● Top risks drafted
After the meeting
● Summary sent with decisions, open questions and owners
● Recurring check-ins in everyone’s calendar
● Access list and risk log saved where the whole team can find them
Not every project needs all of this at full size. A two-week internal task might get half a page and a quick chat, while a six-month client project deserves the full treatment. The aim is the same either way: make the decisions early, write them down briefly, and spend the rest of the project doing the work instead of arguing about it.
