A small software project, such as an internal tool for orders, a booking form or a reporting dashboard, rarely fails because of difficult technology. It fails because two people understood the same sentence differently and nobody noticed for three weeks. A kickoff meeting is the cheapest place to catch that. It is not a ceremony. It is a short conversation where the people involved say out loud what is being built, for whom and who decides what.
This article describes a kickoff for a project of roughly two to twelve weeks, with one supplier team and one client team. If your project is larger, the same structure works, but you will want more than one meeting.
When to hold it
Hold the kickoff after you have agreed the scope and price, and before work starts. If you hold it earlier, you are still negotiating and the meeting turns into a sales call. If you hold it later, the first decisions have already been made by default, usually by whoever was most active.
Book it for 45 minutes. A shorter meeting skips the uncomfortable questions; a longer one drifts into design details that belong in later sessions.
Who attends
Fewer people than you think, but the right ones:
- The person who pays or sponsors. They can say what matters most when two things conflict.
- The person who will use the tool every day. This is the most commonly missing person. A manager describes the process as it should work; the user describes how it works.
- One person who knows the data and systems. Someone who can answer where the current information lives and who can grant access to it.
- The delivery lead from the supplier side, and the developer if the team is small.
If the sponsor and the daily user are the same person, good. If nobody on the client side can make decisions, fix that before the meeting, not during it.
A 45-minute agenda
1. The goal in one sentence (5 minutes). Ask each person on the client side to finish this sentence: "When this is done, we will be able to…". Compare the answers. Differences here are the most valuable output of the whole meeting. Write down the agreed version.
2. What is in and what is out (10 minutes). Read the scope from the agreement and then ask: "What would you expect this to do that is not on this list?" Write the answers under a heading called "Not in this version". This is not a refusal. It is a parking place that prevents later surprise. For how to handle these items once the tool is live, see handling change requests after launch: a one-page intake rule for internal tools.
3. People and roles (10 minutes). Name one person for each of these jobs:
- Approver: accepts or rejects what is delivered.
- Data and access: provides sample data, accounts and permissions, and by what date.
- Tester: the person who will try the tool with real work. A two-hour session with real cases is more useful than a long review of screenshots; see testing a new internal tool with real work: a two-hour acceptance session.
- Stop button: the person who can pause or end the project, and under what circumstances.
One name per job. "The team" is not a name.
4. Dates and rhythm (10 minutes). Agree the first date when the client will see something working, even if it is rough. Then agree how often you will talk: a 15-minute check-in once a week is usually enough. Agree what each side needs to deliver before that first date, for example sample data, a list of users or a decision on a single open question.
5. How change is handled (5 minutes). Say plainly: new ideas will come, and they are welcome. Each one is written down, gets a rough estimate and goes to the approver, who decides whether it replaces something, waits for the next version or is dropped. Agree that nothing is added by conversation alone.
6. Close (5 minutes). Read back the decisions and the open questions with a name and a date next to each.
Decisions to leave with
At the end of the meeting, you should be able to fill in this short list:
- The goal sentence, agreed by everyone on the client side
- The "Not in this version" list
- The approver, the data and access contact, the tester and the stop button, by name
- The date of the first working demo and the weekly check-in time
- The first three things the client owes the project, with dates
- The way changes are requested and decided
If any of these is empty, the meeting has not finished its job. It is better to book a 20-minute follow-up than to start work with a hole in the list.
The note afterwards
Within one working day, send a note of one page at most. It contains the decision list above and nothing else: no minutes of the discussion, no attached slides. Ask everyone to reply with "confirmed" or a correction. A reply of silence is not a confirmation; if someone has not answered in two days, ask them directly.
Keep the note where both sides can find it, and refer to it when questions come up later. Most disputes in small projects are settled in one minute by reading a sentence that both sides already confirmed.
Common mistakes
- Holding the kickoff with managers only and meeting the daily user for the first time at the demo.
- Reading the whole specification aloud instead of asking what is missing from it.
- Leaving "who approves" vague, so that approval comes from whoever replies first.
- Treating the first date as a final delivery date rather than the first chance to react.
- Not writing anything down, because everyone in the room seemed to agree.
- Letting the meeting turn into design work on screens and fields.
Checklist
- Scope and price agreed before the meeting
- Sponsor, daily user, data contact and delivery lead invited
- 45 minutes, five agenda items and a closing read-back
- Goal sentence written and agreed
- "Not in this version" list started
- Approver, data contact, tester and stop button named
- First demo date and weekly check-in fixed
- One-page note sent within a day and confirmed by everyone
Sources
- Common project practice for starting a small software engagement, offered as a practical guide. The durations and the number of agenda items are starting points to adapt to your own project. No client results or market figures are claimed in this article.
