Why Project Kickoffs Fail the People Who Join Later

The version where we gather all known stakeholders, agree on a North Star, carve our approach into stone, and then push off together with the assumption that the kinetic energy we created that day will single-handedly carry the project from start to finish.

The reality is that change is inevitable, and most teams’ approach to project kickoffs is actually broken. 

And that’s going to start to matter a lot in the AI-powered, fractional worker economy we’re entering.

Why A Good Kickoff Doesn't Guarantee A Good Project

I used to think that my ability to lead great project kickoffs was my unfair advantage as a PM. When I kicked off my projects, teams would burst out of the gates with clarity and momentum instead of confusion and more unanswered questions.

In fact, people would come up to me after a kickoff meeting and ask to borrow my agenda or deck so they could use it for their projects. It was a point of pride for me.

But then something happened that changed how I think about kickoffs entirely.

On one of my projects, key members of my team were ripped away and allocated to other projects — all without time for proper knowledge transfer. The talented people who stepped in were also very capable, but they felt like they were starting on the back foot, living in the shadow of what had already happened. They'd caveat every conversation with "but I wasn't here when the project started" or "I'm just catching up here, don't let my ideas derail your plans."

For the new team members, it wasn't that they didn't have the information or the authority or even the ideas. It was that they didn't feel they had ownership.

And without that ownership, the wind was out of the sails. The mission was not their own. They felt like substitute teachers stuck holding the bag — a victim of their circumstances with little say or control.

Unfortunately, I hadn’t realized that yet. 

The Knowledge Transfer Problem

At the time, the solution seemed simple: just bring the new people up to speed. Transfer the knowledge into their brains. Right?

After all, there’s briefs and scope statements and requirements documents aplenty — not to mention the kickoff deck and outputs from visioning exercises. 

But even when you’ve got all your project documents tidy and organized, the new team member experience of getting up to speed on a mountain of loosely structured information can feel like doing forensic accounting with a gun to your head.

Sure, new team members can ask questions, but they don’t know what they don’t know. And most of the time they don’t yet feel comfortable asking the “dumb” questions for fear getting the dreaded response: “that was in the docs, didn’t you see it?”

This created a cycle where newcomers remained lost longer — which only made the project harder to steer.

Lead Smarter in the Age of AI

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

Sign up with LinkedIn

Or sign up with email:

LinkedIn

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

The Hygiene Problem

And on top of that, every time I was onboarding a new team member to my project, I would realize that within my wonderful documents, tiny details — heck, sometimes major details — were out of step with the current state of the project.

Since the kickoff, hundreds of thousands of micro-decisions had been made. Not the big ones that you put in a decision log — the tiny ones that slip through the cracks of documentation updates.

I found myself explaining discrepancies, elaborating on tiny nuances, and relaying informal conversations between team members that we never thought to keep a record of. 

The Speed Problem

Could I have mitigated all this by using a “buddy system” where a new joiner would be paired up with a peer on the project? Believe me, I tried. But that fell flat, too, because the project couldn’t afford to have a team member doing part-time support.

We were already running at a flat-out pace, and we couldn’t afford to slow down. Deadlines were looming, pressure was mounting, visibility was increasing, and the expectation was that the team would be working faster as more people were added, not less.

So instead of slowing the pace, I continued with the status quo: the version where mid-project joiners get stuck in my jumping into a moving car and sticking their hand in the fire.

The Belonging Problem

But as I continued to frantically hurl documents and meeting invites at people getting added to the project — and as the team mindlessly rifled through tasks  from the backlog — something became very clear: it wasn't about information. It was about belonging. And that’s an emotional state that can’t be achieved through documentation alone. 

I couldn't make new team members feel like they belonged just by reassuring them or talking at them more. No buddy system was going to fix this. No agenda-ized “ask me anything” meetings were going to smooth things over. There needed to be safe and alternative spaces.

People find belonging differently in different contexts: some want quiet time with documentation before talking to the team; some want a buddy; some want a safe space to ask the “dumb” questions; and some just want to understand the “why” behind the mission and their role within it. 

That’s what I should have been investing my time and energy into building: a framework that lets team members find belonging on their own terms. 

Ultimately, I was over-investing in the kickoff ceremony but then leaving mid-project joiners to fend for themselves.

This cycle of inadequate onboarding doesn't just frustrate individuals — it undermines entire projects. When newcomers can't get up to speed quickly, decisions slow down, mistakes multiply, and team morale suffers.

And when change is inevitable — when team members rotate in and out throughout a project's lifecycle — this approach becomes unsustainable.

For the new team members, it wasn’t that they didn’t have the information or the authority or even the ideas. It was that they didn’t feel they had ownership.

A Different Way To Think About Kickoffs: Continuous Onboarding

So what’s the answer, then? If we’re overinvesting in kickoffs and underinvesting in change handling and mid-project onboarding, how can we correct it?

I had my hypotheses, but I also had an a-ha moment from someone I respect greatly who said:

"I'm always restating the focus point just about every meeting because the 'north star' always shifts. It reminds me of how we practice in Kung Fu…There is the center point we focus on controlling, and outside of that everything is context to get back to that truth. It is a conversation, with both sides 'asking questions' and receiving answers in real time with all senses."

In other words, instead of relying on the big huzzah of a kickoff, we can use every interaction to reinforce the essence of what's important in the project. It's baked into the act of collaborating instead of being a big party that’s easy to feel like you’ve missed out on if you weren't there.

So here’s what I’ve been trying to do for every project since: 

1. A Policy Of Lightweight, Easy-To-Update Documentation

I've been scrapping my pretty kickoff decks and highly-polished project artefacts (briefs, status reports, meeting agendas, RAID logs), and instead I'm prioritizing having things in a format that are easy to update and easy for human or AI teammates to read.

Then I am working with project teams to assign owners for document updates — just like we would for risk owners. That spreads the load and empowers team members to champion accurate documentation.

As an example, we have simple, succinct documents in Notion or Slite for team roles and responsibilities, our project brief, and our project communications plans. Nothing is locked in spreadsheets or PDFs.

2. Continuous Onboarding As An Accepted Truth

Along with the documentation, I’ve been managing expectations with the team right from the get-go that the teams and goals and other fabric around the project may change at a moment’s notice, and we’ll need to rally.

In other words, instead of hoping and praying that teams and targets won’t change, assume that they will change.

That means having as little as possible locked in people’s brains or relegated to a specific moment in time. Meetings have transcripts, speakers’ notes are accessible in written form, most project conversations are in public channels, and decisions are logged vigourously. 

This helps ensure that people who missed out on Day One of the project still have access to information if they need it. And it also helps us pivot like a flock of skylarks if any of the goals or circumstances of the project change.  

3. AI As A Source Of Truth For All Neurotypes

Along with that, my teams and I are configuring AI chatbots or queryable project knowledge bases as early in the project as possible. 

In a lot of cases, it’s not as sophisticated as one might dream about when it comes to AI, but it does something really important for us: it creates a relatively private, safe, and  less politicized way for team members to interface with project information — on their terms, the way they like to learn. 

These chatbots are fed with structured and unstructured project data right from the outset — briefs, SOWs, status reports, meeting minutes, and some team conversations. And because the documentation is lightweight enough for human team members to keep it updated, it is relatively easy for an AI to keep tabs on what has changed throughout the project — decisions that have been made, budget that has been added, issues that have come up, risks that have been realized, escalations that have transpired, etc. 

Then that chatbot would be queryable at any time by any team member in a context where they don't need to worry about looking dumb and without needing to set a meeting with an authority figure who is already time-poor.

For example, a team member can ask things like:

• “How does my task support the overall project goal?”
• “Who is depending on me to complete my deliverable on time?”
• “Where should I save my final deliverables, and what is our file naming convention?”

These might be questions that they do know the answer to, but may want reassurances about when they’re bouncing between projects and other tasks. 

Ultimately, AI chatbots streamline the process of accessing information, increasing efficiency by eliminating the need for extensive training or consultation with multiple sources, and enhance accessibility through a user-friendly interface that can be accessed from any device with an internet connection 24/7.

But here's the catch: AI has been known to be wrong.

And if it is wrong, that can send a project sideways really fast. The overall consequence would be an added step: try asking the chatbot, scrutinize the response because it might be wrong, then use your gut instinct to decide whether to go with the answer you received and not ask anyone, or find a buddy to ask—in other words, when we don't trust AI, we go back to square one.

So the data does have to be clean enough to not be contradictory. And then the humans on the team need to actually trust that it is accurate (assuming we haven't fed it misinformation).

To help ensure that, our priority is ensuring as much accuracy as possible, with key team members acting as champions and arbiters of quality using a few test cases and spot checks we run regularly. 

4. Ritualistic Reinforcement Of Goals

And then to tie it all together, I’ve been trying to take some of my favourite elements of the tragically “moment-in-time” project kickoff and weaving them into the day-to-day. Things like reiterating and constantly challenging the product vision or BHAG so that the mission is understood well enough to be scrutinized to make sure we’re still building the right thing. 

For example, I try to remind people of the desired outcomes for the project at the start of every team meeting. Something like "as a reminder, this project is going to help transit riders with different abilities to get to where they're going more safely and with less frustration."

And if that North Star has shifted, I try to restate that at every meeting or status update too: "As a reminder, this started as an initiative for disabled transit riders, but now it's an opportunity to uplift the experience for all customers across multiple transit networks."

The other thing I do is use my role as a generalist to ask questions that direct decisions toward our goal. Like, if the team was trying to decide between two approaches, I'd ask something like "which one will help us remove the most friction from the customer experience?"

For things like team values and ways of working, I opt to cap off meetings with that as a reminder: "Don't forget to keep important communications in the shared channel if they might help others do their job."

Not only does this make mid-project joiners feel less like they missed out on something at the beginning, it also helps continuously reinforce the mission with all your stakeholders.

5. A Culture Of Belonging

But most importantly, I'm trying to change my mindset from "knowledge transfer" to "ownership transfer" by prioritizing ways to help make new team members or stakeholders feel like they "belong" in the project and can bring their full self into it.

In my opinion there's no single, bulletproof way to do this, but I firmly believe that the answer is not throwing more information at people. Us humans need to use our humanness to address the things that are squarely human things—emotions, ego, community, and purpose.

When people don’t have ownership, they’re less likely to speak up when something feels off or challenge a decision that might send the project sideways.

Why This Matters More Now

Today, I’m seeing the mid-project onboarding problem become bigger and bigger. Members of my community are running projects that are a revolving door of fractional specialists, freelancers, and even just FTEs being moved fluidly between projects to stay utilized.

At the same time, AI tools are creating liquid expectations among project stakeholders: projects are expected to move faster, handle change better, and deliver more value by capitalizing on data insights, automation, and agentic decision-making. 

In other words, the teams are more volatile and the pace is accelerating. Which means the belonging gap widens when everything is moving faster and changing more frequently.

And here's the real risk: we don't want to just build the wrong thing faster.

When people don't have ownership, they're less likely to speak up when something feels off or challenge a decision that might send the project sideways.

That's why continuous onboarding isn't optional anymore. It's not a nice-to-have or a soft skill. It's a business imperative. If we want teams that can adapt and deliver real value in this faster, more fractured project landscape—we need people who feel invested in the vision, not just informed about the tasks.

So, Are Kickoffs Dead?

Project kickoffs are definitely not dead. Not for me, not for many project teams.

Personally, I love them. I think project kickoffs are gatherings that can create bonds between people and offer forums for dialogue at a crucial moment in a project’s lifecycle. I think they are very human. So, yes, I still do kickoffs, and you’ll have to pry that habit out of my cold dead hands.

What I am doing differently, though, is not cramming all my hopes and dreams into my kickoffs. I am not investing so much energy into making kickoffs flawless, shiny, and performative. I am not aspiring to make them the be-all-end-all ceremony that makes folks who weren’t there at the beginning feel like second-class citizens. And I’m definitely not trying to make them something that locks us into the expectation of a single, unwavering path. 

Because projects aren’t a straight line. They’re a kite in the wind, getting bumped about and having to be steered actively, no matter what happens. Change is inevitable. So that’s what we should invest the energy preparing for.

What Do You Think?

But I’d like to hear from you, too: are kickoffs as problematic as I’ve made them out to be? How are you thinking about onboarding on your projects—especially when team members join mid-flight?