I have spent more than 20 years leading operations and delivery teams in technology, and I have delivered hundreds of projects. If I had to name the one meeting that best predicts whether a project goes well, it’s the kickoff.
Not because the kickoff is exciting. Usually it isn’t. It matters because most projects that go sideways were set up to fail in the first hour. Nobody agreed on what “done” meant, the wrong people were in the room, or a key decision was quietly left for later. Here is what I want settled before anyone starts the work.
1. Everyone can say what the project is for. Not the list of tasks, the reason. “We’re replacing the phone system so customers stop getting dropped when they call the main line” is a purpose. “Install new phones” is a task. When people know the reason, they make better decisions on all the small things nobody planned for.
2. “Done” is written down. What exactly will be delivered, and how will we all know it’s finished? For a website, which pages? For a phone system, which numbers, which extensions, which call routing? Write it in plain language. Then write down what is not included. Most scope arguments later come from something nobody said out loud at the start.
3. There is one decision maker on each side. A project with three people who can approve things and none who can say “final” will stall. Name one person on each team with the authority to make the call, and agree on how quickly decisions are expected.
4. Every piece of work has a name next to it. List the main pieces of work and put one name beside each. Not a department, a person. Shared ownership usually means no ownership.
5. The dates are honest. The kickoff is where you find out whether the deadline is real. Is an event, a contract end date or a move-in day driving it? Then plan backward from that date. Be honest about what the client needs to provide and by when, because projects run late from waiting on content, approvals or access far more often than from the work itself.
6. Dependencies are on the table. What has to happen before something else can start? Does the internet need to be installed before the phones? Does the logo need to be final before the website design? Who has to give us access to the domain, the old system or the building? Surface these on day one, because they are what quietly push dates back.
7. Risks get named early. Ask everyone in the room what could go wrong. Somebody always knows. The old system nobody has the password to. The busy season that starts next month. A risk you hear about at kickoff is a planning item. A risk you discover in week six is a crisis.
8. Communication has a rhythm. Agree on how updates will happen and how often: a short weekly email, a standing check-in or a shared tracker. Agree on how to raise a problem between updates. People stay much calmer when they know when they’ll hear something next.
9. Next steps leave the room with names attached. Every kickoff should end with a short list: who is doing what, by when, and the date of the next check-in. Send it in writing the same day. If it isn’t written down, it didn’t happen.
None of this takes long. A kickoff for a small project can be done in under an hour. What it does is turn a set of assumptions into a shared plan, and give everyone something to point back to when memories differ later. I wrote more about the habits that keep work moving after the kickoff in Forty Projects at Once.
If you’re a business owner about to start a project with a vendor and they don’t run a kickoff like this, ask for one. These questions are fair to ask of anyone you are paying to deliver something, and a good team will be glad you asked.
Danielle Lemons is Vice President of Operations at DirecTech Connect, a Nashville provider of business phone systems, managed IT services, websites and digital marketing. More about Danielle.
Read more of Danielle’s writing, or see her profile at DirecTech Connect.
