Why Project Kickoffs Fail the People Who Join Later

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

A Good Kickoff Does Not Guarantee A Good Project

I used to think that project kickoffs were my superhero skill. When I kicked off my projects, people 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.

When Your Team Changes Mid-Project

On one of my projects, several key members of my team were ripped from me and allocated to other projects. These were my lieutenants — the trusted advisors I was relying on. But more importantly, they were the people I was most excited to come in every day and collaborate with. We didn't even have time to do proper knowledge transfer.

The people who stepped in to take their place were talented. But each one of them felt like they started on the back foot.

They didn't feel like they could contribute freely, as if they were living in the shadow of what had already happened in the project. Instead of proposing bold solutions and creative ideas, they would 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."

A few weeks later, the client team changed as well. There was a re-org at their organization, and the executive sponsor we had spent months building trust with was removed and replaced with someone who, while capable, was spread far too thin. The project that was once the top priority became one of the lowest priorities for the new sponsor juggling additional responsibilities.

That led to slower decision-making, lower team morale, less clarity, and less confidence that we’d even be able to deliver the project at all.

For the new sponsor and 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 at the time. 

What Mid-Project Joiners Are Actually Asking For

When those new team members would say "but I wasn't here when the project started," I thought they were expressing a need for more information. So in my ignorance, I kept throwing more documents at them.

But it wasn't about information. It was about belonging — an emotional state that can't be achieved by throwing more documents at people.

To be fair, I don't think me reassuring them that they belonged in the project would have helped either. In fact, I don't think I could have made anything better at all just by talking at them more. Making them feel like they belonged there was not something I could achieve by myself. There needed to be safe and alternative spaces to achieve that sense of belonging. 

What I hadn’t realized back then was that people thrive differently in different contexts and environments. Me, I love dialogue and meetings and real-time collaboration. But not everyone does. Some personalities might want to spend time reviewing the documentation, digest the information quietly on their own, and then talk to other people on the team to get themselves up to speed.

The other thing I hadn’t realized was that a 45-minute agenda-ized meeting with an authority figure (me, the project manager) was pressurized and intimidating for some. 

Okay, fine — but there was project documentation new joiners could read, right?

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:

URL

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

Why 'Just Read the Docs' Doesn't Work

Even if all your project documents are tidy and organized, the process of getting up to speed on a mountain of loosely structured information can feel like doing forensic accounting with a gun to your head.

As a project leader, I’ve definitely been guilty of just dumping documents on people with some loose guidance and expecting them to figure it out. And in the organizations I’ve worked within, it’s almost a given that nothing about the mid-boarding process is designed to help the new person getting themselves up to speed. We just assumed that mid-project joiners would read all the things and just "get it" afterwards.

The reality was that most people's brains don't actually work that way, and the emotional pressure of trying to meet that fallacious expectation didn't help either.

But I didn’t see that at the time, so I'd commonly send newcomers first to the Project Brief and then to look at the Statement of Work (SOW) to understand the scope and vision for the project. I'd have them review the latest status report, recent presentations, and the RACI chart to get a sense of who's who in the zoo.

For website projects, I'd have them review the functional specs and wireframes or mockups. Sometimes there would be a client-facing presentation about our brand strategy for them. Sometimes there would be non-functional requirements or quality attributes to review like accessibility, security, privacy, and reliability.

Deep down, I knew this was like drinking from the proverbial firehose. But it was hard to know exactly what they would want to know, so my default was "review these and then ask me anything that was left unanswered."

Which is tricky because it's hard for someone to know what to ask when they don't know what they don't know.

The Questions People Don't Ask

Sure, new project team members would come back with some questions, but I always got the sense they felt pressured to only ask “the smart questions”. If they felt their question might invite ridicule or the all-too-common gaslighting of “the answer was in the docs, didn’t you see it?” — then they’d likely just ask another teammate in passing or, even worse, just keep it to themselves. 

Some examples of questions people probably needed to ask but didn't because they felt too basic or self-serving:

• "Which of the recurring project meetings should I be in?"
• "How does this team like to work?"
• "Is this client budget-conscious or is there some flexibility?"
• "I'm working on 4 projects right now. Which one is the priority?"

Those questions — about meeting rhythms, team culture, and inter-project priorities — they're not really in a Project Brief or SOW. Not in any great detail, anyway.

Eventually we started building Team Working Agreements that laid out agreed team values, working hours, work preferences, and general workflows. But more detailed workflows really had to be learned by doing it with someone who had been doing it on the project for a while. Like, having a project "buddy."

But it turns out the “buddy system” was broken, too. 

The Buddy System and the Billability Problem

Having a project buddy to learn the detailed workflows sounds like it could work. But it requires someone with time and willingness to do it.

And that's a common problem for fast-moving projects. In an agency context, for example, onboarding new team members wasn't seen as "billable" so we'd try to spend as little time as possible on it to keep our utilization high. And in some cases newcomers were stepping in for the only other person who did what they did on the project, so they'd be a bit on an island of their own.

Having a "buddy" who did a completely different job on the project was still useful. But again, we tried not to spend too much time onboarding new team members.

So more often than not, mid-project joiners would usually have to just get stuck in and learn by sticking their hand in the fire.

This created a cycle where newcomers stayed lost longer and probably made more mistakes. In fact, some studies have revealed that teams experiencing frequent personnel changes show a 28% decline in project completion rates, which directly reflects the cost of inadequate onboarding.

A Different Way To Think About Kickoffs

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 wanted to hear from others. So I posted about this on LinkedIn, asking people about their experiences. One person asked if it would be worth it to have a mid-project kickoff when a lot of things (and people) had changed on a project. Someone else was adamant that project kickoffs are still important for establishing a bond between team members that haven’t worked together before. Both very valid points, in my opinion. 

And then I had this 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.

So Wait, 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.

So 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?