How to start a project: what to do before the kick-off

How to start a project is, most of the time, a question about what happens before the first meeting rather than about the meeting itself. When a kick-off disappoints, the problem is rarely how it was run: it is walking into the room without a closed scope, without defined stages, without knowing who approves what, and with goals nobody had seen before.

The kick-off meeting is a validation. It works when people show up having read the material, disagree about what deserves disagreement, and leave with decisions on the record. For that to happen, someone has to do the quiet work of the day before, which is exactly the subject of this article.

A note on scope before we go on. This text covers preparation only. Running the meeting itself, the minute-by-minute agenda and the minutes template are developed in two neighboring articles, linked along the way whenever the subject touches them.

How to start a project before calling the kick-off meeting?

You start by gathering information and making provisional decisions on paper. At this stage, starting a project is a writing job: putting down what you understand the scope to be, what you commit to deliver, in what order and by when, and then taking that draft to the table so the right people can correct it.

Reversing that order is the most common mistake. The invitation goes out first, the meeting happens, and the material gets built during the call while ten people watch someone think out loud. The result is a long meeting with fragile decisions that needs a second meeting to hold.

Caption: How to start a project in practice: the briefing, the responsibility matrix, the schedule milestones and the agreed record of each decision.

Atlassian's project playbook describes this preparation as a short, objective task: around thirty minutes before the meeting, split between naming who takes part, with a defined role, and writing the project's direction in a shared document for a silent pre-read. The kick-off preparation documented there happens after the statement of work is already settled, not during it.

In agency work and in education institutions, that preparation usually takes more than half an hour, because it involves gathering history from the client, understanding previous campaigns and checking what data already exists. Even so, the logic holds: the material arrives finished and the meeting decides.

The four artifacts of preparation

All of the preparation boils down to producing four pieces. They are the subject of the next sections and, together, fit into three or four pages:

1. Scope and stages: what is in, what is out, and the phases the work moves through, with dated milestones.
2. Pre-read briefing: the document everyone receives beforehand, with context, objective and what the meeting is expected to produce.
3. Responsibility matrix: the grid that says who executes, who approves, who is consulted and who simply needs to know.
4. Proposed goals: the numbers that will measure the project, already written, ready to be validated or corrected in the meeting.

Note that none of those four items is the meeting agenda. The agenda comes afterward and is derived from them. If your preparation started with the agenda, it will probably revolve around introducing people instead of deciding anything.

If you are new to the subject and still want to understand the meeting itself, the article on the benefits of a kick-off meeting covers the agenda and the role of the meeting within the project. The part about running it, with best practices for whoever leads the room, lives in the text on how to conduct and record a kick-off in minutes. This one stays on the eve of it.

How do you define the stages of a project before it starts?

Defining the stages of a project means breaking the objective into blocks that end in something verifiable. A stage is only well defined when you can answer, without hesitating, which deliverable closes that block and who looks at it and says it is done.

The practical path is to start from the end. Write the final deliverable first, then what has to exist immediately before it, and so on backward until you reach what already exists today. Working in reverse exposes dependencies that a chronological list hides, such as the data that will only exist after the form goes live.

Once the stages are written, they need dates. One distinction saves a lot of frustration later: a milestone is not a task deadline, it is the date on which a decision or a deliverable exists in the world. Three to five milestones are enough for a quarter-long project. More than that becomes a control schedule, and a control schedule does not belong in an opening meeting.

An example of phasing

A student enrollment project, for example, usually fits into four phases. The table below shows a format that works well for the kick-off, with the deliverable that closes each phase and the sign that it genuinely ended:

Table: Example of stages in an enrollment project, with the deliverable and the closing criterion for each phase

What holds this phasing together is the negative scope, meaning the list of what the project will not do. It is shorter to write than the positive list and prevents almost every uncomfortable conversation in month two. If the project does not include video production, write that in the briefing before the meeting, not after the first request.

Projects born out of a larger initiative help calibrate that cut. When the objective is to bring more opportunities into the funnel, for instance, it pays to look first at which marketing strategies capture the most leads and pick one for the first cycle, instead of opening five fronts at once and being unable to measure any of them.

Organic channel projects deserve extra care when dating milestones, because results take time to show by nature. The phase logic of strategic SEO planning helps set honest expectations here, keeping implementation milestones separate from result milestones.

What goes into the briefing for a kick-off meeting?

The meeting briefing is the pre-read document every participant receives before the session. It has a single job: to make sure people arrive knowing what the project is about, so that meeting time is spent on decisions rather than on context.

A good briefing is short. Two pages, three at most, with recognizable blocks and no surprises buried in the middle of a paragraph. Past that length nobody reads it, and the meeting restarts from zero with the facilitator explaining what was already written.

The blocks a briefing needs

• Context: where the demand comes from, what has already been tried and what changed to make this project exist now.
• Objective: the single sentence describing what the project delivers, written without adjectives.
• Scope and non-scope: what is included and, above all, what is explicitly out.
• Stages and milestones: the phases with the dates of the deliverables that matter.
• Participants and roles: who is in the meeting and why, with each role already named.
• Proposed goals: the suggested numbers, labeled as a proposal, so they can be discussed.
• Decisions the meeting must make: the explicit list of what cannot leave the room unresolved.

That last block is what separates a briefing from a company presentation. Writing the open decisions as questions changes the behavior of whoever reads it: people arrive with a position formed, and the meeting becomes a sequence of answers instead of a sequence of slides.

On client projects, add a block with commercial history. Understanding how the account was sold, what was promised and what created expectation prevents the classic mismatch between what the team thinks it will deliver and what the client thinks it bought. The stages of the sales process that preceded the contract usually explain much of that expectation.

Circulate the briefing at least forty-eight hours in advance and ask for comments inside the document itself. A comment received beforehand becomes an agenda item; a comment received during the meeting becomes an interruption. It is a small process difference that changes the quality of the following hour quite a lot.

How do you distribute responsibility with a RACI matrix?

The RACI matrix is a grid that crosses deliverables with people and marks, at each intersection, how that person is involved in that deliverable. The acronym is worth spelling out at first mention: Responsible (the person who executes), Accountable (the person who answers for the result and approves it), Consulted (the people asked before the decision) and Informed (the people who only need to be told).

Atlassian's reference description helps pin down the difference between the first two letters, which is where almost everyone slips. In their definition of a RACI chart, the responsible individual is the one who receives the delegated task and carries it out within a deadline, while the accountable individual ensures that the responsible members complete the task and acts as the single decision maker for it.

From that comes the most useful practical rule of the tool: one A per row. If a deliverable has two approvers, it effectively has none, because the first disagreement between them stalls the work with nobody holding the authority to unblock it. Several Rs on a row is normal and healthy; several As is not.

What the grid looks like in practice

The matrix looks like this, with deliverables in the rows and roles in the columns. This example uses the phases from the previous section:

Table: Simplified example of a RACI matrix for the deliverables of an enrollment project

Build that grid before the meeting, in pencil. Bringing a filled-in matrix as a proposal has a curious and very productive effect: people energetically correct whatever they disagree with, and their correction is precisely the information you needed. Bringing a blank grid and asking the room to fill it in live produces silence.

Three precautions keep the matrix from becoming slide decoration. First, name people, not job titles: a job title does not answer a message. Second, limit the grid to the deliverables that close a phase, so it fits on one screen. Third, agree on what happens when the accountable person is away, because absence without an agreed substitute is the quietest way for a project to stop.

On projects that involve marketing and sales at the same time, the matrix usually reveals the classic gray zone, which is the handoff of a lead from one team to the other. It pays to look closely at that row and, if the project carries a commercial goal, to agree upfront on which inbound sales performance indicators each team will track, because that is where the responsibility discussion comes back in month three.

How do you set SMART goals before calling the kick-off?

Arrive with written numbers, labeled as a proposal. SMART goals are objectives formulated to be verifiable, and the acronym describes five attributes: specific, measurable, achievable, relevant and time-bound. In project management, that is the most widely used reading of the letter R.

It is worth noting that the acronym has documented variations. A public glossary maintained by a United States government health technology program defines SMART objectives as specific, measurable, achievable, realistic and time-bound, swapping relevant for realistic. The difference is small in practice, but it shows that the point is not the word: it is the discipline of only accepting a goal somebody can verify.

The most common preparation mistake here is not writing the wrong goal: it is mixing two kinds of goal in the same place. An output goal measures what the team does, such as publishing twelve pieces of content in a quarter. An outcome goal measures what happens in the world, such as doubling the volume of enrollments coming from organic search. Both are legitimate, but anyone who takes on the second without control over the whole channel is signing a blank check.

How to write the goal before the meeting

1. Start from today's number: with no baseline there is no goal, only a wish. If the data does not exist, the project's first goal is to start measuring.
2. Write the change, not the absolute: going from forty to sixty enrollments a month says more than announcing sixty.
3. Tie it to a milestone date: the goal comes due with the phase, not at the end of the year.
4. Name who reads the number: every goal needs someone in charge of looking at it on a regular basis.
5. Label it as a proposal: the kick-off exists in good part to correct those numbers with the people who know the operation.

When choosing which numbers make the cut, the criterion is responsiveness. An indicator that only moves in six months cannot steer a quarter-long project; it can only evaluate it at the end. The metric selection logic used in revenue operations KPIs helps a lot with that triage, separating what guides a weekly decision from what guides a cycle decision.

If you want to go deeper into the method itself, with writing examples and formulation traps, the article dedicated to SMART goals and how to apply them works through each of the five letters carefully. Here the focus is only on what has to be ready before the meeting.

To close this section, it is worth listening to an audio explanation of SMART goals applied to content planning. It takes only a few minutes and helps show how the same formulation discipline serves any project, not just a campaign.

Video: Metas SMART: um guia para criar um planejamento de conteúdo | AudioBook - 4Revops (audio in Portuguese)

How do you agree on recording decisions before the meeting?

Agree on three things in advance: where the decision will live, who writes it down and how long until the record circulates. It sounds like an operational detail, but it determines whether the kick-off produces a document people can consult or a shared memory that everyone stores differently.

The place matters more than the format. Minutes in a collaborative document, a card in a project tool or a record in the CRM all work equally well, as long as there is a single place that people already open for other reasons. A record that lives in a parallel channel is a record nobody consults the following month.

The person writing should not be the person facilitating. The facilitator is busy holding the thread of the discussion and will miss decisions. Name the note taker in the briefing, by name, and tell them that is their role in the meeting. It is the cheapest agreement of all and the one most often forgotten.

What the record needs to contain

• Decision: what was decided, in one sentence, with no narrative context.
• Owner: the name of the person who answers for it from now on.
• Deadline: the date, not the week.
• Open item: what was left unresolved and when it comes back to the table.

The full minutes template, with the recording structure and best practices for whoever runs the meeting, is developed in the article on how to run a successful kick-off meeting. What matters here is that this agreement happens beforehand, not in the minute when someone asks who is taking notes.

When the project involves a CRM (Customer Relationship Management system), decide during preparation whether process decisions will become configuration in the tool and who does that work. The discipline described in CRM management in the first 90 days applies just as well to the start of a project: a decision that never becomes configuration comes back as a question.

What does the day-before kick-off checklist look like?

On the eve of the meeting, you verify readiness, not content. The content should already be settled. What you check now is whether the material reached people, whether the right people confirmed attendance and whether the meeting has enough time for what it needs to decide.

Here is the short list, in the order worth running through:

1. Briefing sent and opened: confirm the document was opened, not just delivered. An unopened document means a meeting that starts from zero.
2. Accountable confirmed: if the approver is not coming, reschedule. An opening meeting without the decision maker produces provisional decisions, which amount to none.
3. Matrix and goals as drafts: bring both filled in and labeled as proposals, ready to be corrected at the table.
4. Note taker named: with the name written in the briefing and the person aware of the role.
5. Time matched to the agenda: add up the estimated time of each decision block. If it exceeds the slot, cut a block, not the discussion.
6. Next meeting already proposed: bring a suggested date for the first follow-up and settle it right there.

It also pays to prepare the opening minutes of the meeting, the only stretch where preparation is visibly on display. Two minutes stating what will be decided in that hour, before any presentation, change the tone of the entire session. It is the difference between an audience and a working group.

If the project is operational and spans several departments, the implementation logic described in revenue operations in practice offers a good parallel for the ramp-up sequence, where each phase only begins once the previous one has produced a verifiable artifact.

Which preparation mistakes most delay the start of a project?

The mistakes that cost the most are not execution mistakes, they are omissions from the day before. All of them surface later, usually between week two and week four, when the project is already moving and fixing things costs the whole team's time.

The five most frequent oversights

• Scope with no negative list: anything not written down as out of scope will be requested as if it were in, and saying no becomes a conflict instead of an agreement.
• Goals with no baseline: without a starting number, any result can be read as success or failure depending on who tells the story.
• Two accountable people on one deliverable: the first disagreement between them stops the work, and nobody has the authority to unblock it.
• Briefing sent at meeting time: material that arrives with the invitation is not a pre-read, it is an attachment. The effect is the same as not sending it.
• No agreement on recording: the meeting decides well, nobody writes it down, and within two weeks the decision exists in four different versions.

There is also a subtler mistake, which is over-preparing. A project does not start with every answer, and trying to close every detail before the kick-off delays the start without reducing risk. The calibrating question is simple: does this information change a decision we are about to make in the meeting? If it does not, it can be raised later, with the project already running.

Finally, remember that preparation is one person's work but not one person's decision. A draft circulated beforehand is an invitation to correct; a draft presented as finished is an invitation to stay quiet. The difference lies in the verb used to send it, and it shapes the quality of everything that follows. When that preparation needs outside support, it is worth seeing what mkt4edu does in content and project planning.

Frequently asked questions about how to start a project

So how much is preparation before the kick-off really worth?

It is worth it whenever the project involves more than one department or more than a month of work. Preparation does not add to the total time: it moves the hard conversation to a moment when scope, deadline or goal can still change at no visible cost to anyone.

On a small project, one person and two weeks, half a page of briefing and a list of milestones will do. Building a full matrix there is bureaucracy with no return, and the time pays off better by fixing the definition of the number that will measure the result.

The final test is short: ask three people on the team what the first deliverable is and who approves it. If you get three different answers, the kick-off should not have been called yet.

And when the project is an enrollment campaign, there is a step before agreeing on goals: measuring the starting point honestly. See when to request a diagnostic evaluation in student enrollment and what that assessment reveals about the real scenario before the project begins.