Running A Project Kickoff That Prevents Six Months Of Confusion

Six months into a project, two people are arguing about whether something is done. A third is quietly blocked because they do not know who can approve a change. None of this is a work problem. It is a kickoff problem.

A good project kickoff answers five questions out loud, in front of everyone, and writes the answers down: what problem this solves, what counts as finished, who can say no, who is doing what, and what would make us stop. An hour spent on those five saves months of the slow confusion that comes from assuming everyone already agreed. It is an hour worth finding even on a calendar with a strict weekly meeting budget.

Question one: what problem are we solving

Not what we are building. What is wrong right now that will be less wrong when this ships.

Ask each person in the room to say it in their own words. If the team is spread out and already runs written standups, collect those sentences in writing beforehand rather than skipping the exercise. You will hear three different answers, and that is the useful part. The gap between "we are fixing the reporting delay" and "we are replacing the reporting system" is the gap that shows up in month four as scope disagreement.

Write down the version the group settles on. One or two sentences. Put it somewhere the team sees weekly.

Question two: what counts as finished

This is the question most kickoffs skip because everyone assumes it is obvious.

Finished can mean the code is written, or it is in production, or the first real user has used it, or the old system has been switched off. Those are months apart. Pick one and say it plainly.

Then write the opposite: what is explicitly not in this project. A short "not doing" list is the cheapest scope protection there is, and it lets you say no later without it feeling like a rejection of someone's idea.

Question three: who can say no

Every project has decisions that need one person to settle them. Name that person on day one.

Be specific about the categories. Who signs off on design. Who signs off on spending. Who decides that a date moves. Who can say a feature is out of scope. It can be the same person for all of them or four different people, but it cannot be nobody, and it cannot be "we will decide as a group", which in practice means the loudest person decides.

Also name the escalation. When the person who can say no is unavailable for a week, what happens. That single line prevents a lot of stalled work, and it gives standup somewhere to send an item the moment someone says what they are waiting on.

Question four: who is doing what

Not a full plan. A list of the main pieces of work with a name against each.

Two rules make this stick. One name per piece, because two owners means no owner. And the name is the person accountable, not everyone contributing. Contributors are obvious once the work starts. Accountability is not.

If a piece of work has no name yet, say so out loud and write "unowned" against it. An unowned item that everyone can see gets picked up. An unowned item that nobody named gets discovered in month three.

Question five: what would make us stop

The uncomfortable one, and the most valuable.

Ask what you would need to learn for this project to be worth cancelling. Maybe it is a technical result, a cost, a customer response, or a regulatory answer. Then ask when you will know that. If the answer is "at the end", you have just found the biggest risk in the project, and you can usually restructure the early work to find out sooner.

Teams that never discuss stopping conditions tend not to stop. They slow down instead, which is much more expensive.

Getting the answers to survive the kickoff

Answers written on a whiteboard photo do not survive. Answers written into the thing the team looks at every day do.

Put the five answers at the top of whatever holds the work. The problem statement, the definition of finished, the names against decisions, the owners, and the stopping conditions. Review them once a month and change them on purpose when they need to change, with a note saying why.

It also helps when the record of who decides sits next to the record of who is available. If the person who signs off on design is away next week, that is worth knowing when you plan the sign off, not when you chase it. Teams that keep those two facts in separate systems tend to find out the hard way.

The tooling is secondary. Answering the five questions out loud, with everybody listening, is the part that does the work.