Kick Ass Kickoff Meetings

Reprinted with the permission of A List Apart and the author. Originally published August, 2010.

During project-based work, every freelancer, agency, or internal department has “the kickoff meeting.” In theory, this meeting should have all the energy, excitement, and potential of the opening salvo of the Superbowl. Project team members should be inspired coming out of that meeting, full of ideas, and a desire to begin exploring solutions. Agencies and freelancers should begin to see their clients as friends and collaborators with unique insights that can only come from frank, open discussion of the design challenge at hand. But this rarely happens.

Every meeting is an opportunity. Why waste your first one?

In reality, kickoff meetings range from somewhat boring to straight-up awkward, and can be an expensive reiteration of project details we already know, assembling the most expensive, busiest people and generating little measurable project benefit. We have to start the project somewhere, but something is often missing in the kickoff meeting; something that is an obvious part of the football analogy—analysis and strategy. Before that kicker sends the ball across the field, coaches spend a lot of time reviewing tapes, applicable statistics, and more—what we in the web business call “research.”

What When is a kickoff meeting?

You’ve been hired or the budget’s been approved and there’s a loose idea of the project’s duration and key milestones. Now you’ve got to formally launch the project. To put names to faces and begin to understand the problem at hand, the traditional kickoff meeting assembles the core team around the table for introductions and light discussion. So what’s the problem?

How many times have you heard this?

“Oh, if only I had been involved, I would have explained that to you sooner/told you that idea would never work/made everything right in the universe.”

By dubbing the first core team meeting the “project kickoff,” you are creating a project history that gives the impression that decisions are being made before everyone in the larger group has a chance to make their voice heard. So don’t do that. Call that meeting the “pre-kickoff meeting,” or the “kickoff planning meeting.” Sure, start by meeting with trusted colleagues on the client side, but save the name “kickoff” for a much more robust experience. Have a process that allows everyone to have their say before the project starts, and take a little time to research and explore the problem at hand from your client’s/partner’s perspective during that gap.

Before the meeting: arm yourself!

To make sure you actually have an understanding of that problem beforehand, do stakeholder interviews and gather requirements immediately following this initial core team meeting, but before the larger, official kickoff meeting. It sounds obvious, but it rarely happens. Eagerness on the part of the client or the project team leads to a meeting characterized by an uninformed round table of introductions, boring icebreakers, and purposeless conversation that, at best, provides only slight clarification to project direction and goals.

There are two aspects to the requirements gathering process that are critical for planning a successful kickoff.

SKIP TO THE HARD QUESTIONS

Use stakeholder interviews to break the ice in a more natural, one-on-one or small group conversation. Then ask some questions that will reveal your interview subjects’ specific, personal hopes and fears for the project—the more brutally honest they are, the better. Assure your interview subjects that certain questions are “off the record,” and then get them to really explore the relationship between the organizational culture and their project expectations. Who is the one person that will make this project a success, and who is the greatest challenge? If this is a redesign, what worked the last time they tried to do this, and what didn’t? If this is a startup, why haven’t they started up sooner? Questions like these reveal pain points which kickoff activities can confront directly.

Here are a few specific examples of questions we ask and why we ask them.

What is the one thing we must get right to make this website/application worth undertaking?

Unless you are working with an organization that has already developed a detailed project plan, this question should generate a lot of different answers. Especially if you talk to different departments with different vested interests. Knowing where the specific tensions exist will inform specific activities you can do to define priorities and explore feasibility during the kickoff meeting.

How does your organization define success? What is the role of the website/application in achieving that success?

Nothing happens without a larger context. In tough economic times it can be an uphill battle just to secure the budget for a project, and it can be easy to lose sight of why the project was needed in the first place. Knowing the difference between project goals and organizational goals will help you define priorities and scope. If a specific functionality isn’t critical to organizational success, it’s a “nice-to-have” and a good candidate to leave out of your kickoff meeting discussion, and possibly the project altogether.

What aspects of the internal culture or external environment could put this redesign/application at risk to fail?

There’s something that everyone thinks is going to derail this project: They just haven’t told you what it is yet. The sooner you know, the better. Have they tried this before, only to fail? If so, why? During the kickoff meeting, you must establish how this project is going to be different than other previous, possibly unsuccessful, attempts. Knowing insider history and the team’s unique understanding of the market in which this website will thrive are the building blocks of differentiation.

(Follow up question) Assuming we mitigate that risk, what would exceed your wildest dreams?

The flip side of the previous question is that everyone has a fantasy version of the project in their heads. You never know what great ideas might be lurking in those fantasies; ideas that haven’t been shared yet because they were considered too unrealistic or outrageous might be the most exciting ideas.

EVERYONE’S A STAKEHOLDER

Be sure to expand the list of qualified stakeholders as much as possible. By doing this, it increases the likelihood that you are going into a kickoff meeting with a more accurate range of all the miracles this project will achieve. More traditional approaches to defining a list of stakeholders focus on the departments directly responsible for what you are building, or that special group of people who have the ability to fire you. This ends up with information gleaned from director-level folks, vice presidents, and if you’re lucky, a little face time with el jefe. But you should talk to editors, junior designers, accountants, and even building maintenance personnel if relevant. Anyone with a relationship to your project, no matter how tangential, will have insight into organizational culture. And by expanding the guest list, you are building a better understanding of the problem at hand, and engendering project awareness and trust throughout the organization.

Projects have their own cultures, just like organizations. The sooner you take an active role in building that culture to complement the organizational one, the happier everyone will be.

During the Meeting: Explore Ideas and Build Relationships

My team reached a turning point after signing a contract for a fantastic project. We kicked off the project in the worst way imaginable: With a phone conference between two large groups of people. Body language? Nope, no bodies. Awareness of who was speaking when? Nigh impossible. Visual communication? Don’t even go there. Even if we’d had screen sharing, our experiences have shown that one of the worst things we could do is simply throw what we’ve learned into Keynote and reflect it back in a one-way conversation. And despite the amazing technological breakthroughs of Avatar, web cam technology isn’t to a point where it can even remotely communicate the subtext required to understand the full range of human expression via video chat.

Had we done our stakeholder interviews before the meeting, we would have accumulated a decent list of a high level (and possibly more specific) functional requirements. We decided to revise our kickoff approach, assuming that we would have this early knowledge, and sought out workshop-style activities adapted to suit the appropriate conceptual depth (high) and level of functional detail (low) for the beginning of a project. We plumbed our favorite research techniques, user experience books, classroom approaches, and even gaming to help develop a playbook of shorter duration, high-touch meeting formats to build a collaborative culture with our client.

Read part 2 of this article.