Host a human-centered project kickoff for project health and happiness

When a project kickoff starts with a focus on requirements, dates, technical specifications and “deliverables,” I get uneasy. Such a technical jump in may work if a team already knows each other well and has an established process in place—so well they walk each other’s dogs at lunch. So, really knows each other well. For everyone else, and for the projects I’ve worked on with the most success, we use a human-centered approach to project kickoffs. After all, everyone wants a smoothly running project. Everyone wants to participate in a meaningful and efficient fashion. We all want to do great work.

However, anyone who has ever worked has experienced challenges and made mistakes at some point. So, how can we create an environment of trust? How can we make errors, yet feel supported by our team? How can we gracefully recover, course correct, move on, and focus on the overall success of the project vision? This is the primary goal of the project kickoff: to establish a tone of trust for the working team, as well as get out of the way all the initial logistics of today’s collaborative work environment. In my experience, it’s the most critical meeting of them all—because if a project doesn’t start properly, it never really gets back on its feet.

Who’s on the team?

It is critical that everyone meet face to face at a project kickoff. Ideally with coffee and snacks; less ideally, or for distributed teams, the kickoff can be via video chat and screen share. The project kickoff is a rare opportunity for everyone to meet, associate names to faces, and learn something about each other, in our daily contexts at work and in this project.

A round of introductions is never too fun—it feels formal and structured. I haven’t found a way around it yet, at least for the initial round of names and titles. Ideally, after introductions, a more conversational approach is taken up. Discover as much as possible in a short amount of time:

• What is your role in the organization? In this project? How many hats do you wear throughout the day? What is your day generally like?
• Experience sharing: what have you worked on that’s similar to this project? What have you worked on that isn’t similar but interesting, and successful because of your efforts?
• Why are you involved in this project? What work will you do, and how will you participate with the project team? What does the project mean to you?

Who’s doing what?

There are more than a dozen methods of identifying roles and responsibilities for a collaborative team. We use the RACI Framework (R=Responsible, A=Accountable, C=Consulted, I=Informed):

• Responsible members do the work to complete the task. On the client side, responsible members are the interface between the project team and other stakeholders.
• The Accountable role is responsible for making key decisions. Typically the project’s sponsor, the approver signs-off on deliverables, and is responsible if the project fails. There is only one accountable for each task or deliverable or work phase.
• Consulted members offer project input, and are typically subject matter experts. They have critical input, but not decision-making responsibilities on the project.
• Informed members are provided status updates and informed of decision making: they are kept up-to-date on progress, but typically it is only one-way communication. These may be senior executives, board members, users of the system, or other stakeholders.

How shall we go about this?

Here’s the problem to solve from the start: a loss of momentum and productivity (and increase in frustration) because something isn’t ready-at-hand. You can’t find it; you don’t have the time for the hassle of finding it; and yet you’re continually casting around for it—maybe it’s lost in email. The inevitable result: “can you resend X to me…”, which solves the immediate need but only compounds the problems for tomorrow, as it adds more information clutter to the table. Solve this problem by being flexible yet disciplined with project communications:

• Where shall files be stored? Google Drive / Dropbox / Box.com / etc.? How shall they be sorted within these storage systems?
• How shall files be named, so we can tell what they are? (this can sometimes wait for future orientation sessions).
• If we are meeting via conference call or screen hare — how is that information shared? Does the technology work for everyone?
• Who wants calendar invites, and lives by them—and who doesn’t, and can’t stand them? What information gets included in an event invitation?
• What project management tools shall we use? Orient the team to the product: does everyone understand it, and feel comfortable using it?

What is it that we’re trying to achieve?

I’m a fan of establishing the project vision using variations on the Dan Sullivan Question:

• Imagine it’s three years from today, and you’re incredibly happy with how this project turned out. What happened to make you so happy?
• What opportunities can we capture to get us there? What strengths are in our favor?
• Imagine its three years in the future again—but this project was a disaster so bad, they’ll one day teach it in business school. What happened? Why did it fail?
• What obstacles stand in our way that we should be aware of now?

Although not dissimilar to a SWOT analysis, the Sullivan Questions first establish a future state of success. By using prospective hindsight , they help generate explanations for future events, as if they had already happened—see my article on project pre-mortems for more.

That’s a wrap

So, that’s our ideal project kickoff: who’s involved and what are their roles; the mechanics of project management; and the vision for the project’s success (and failure). With these four in hand, a clear foundation is established to move forward.

What project kickoffs have you experienced that were successful, or disastrous? Feel free to share with us below.

Photo by Baylee Gramling on Unsplash