Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Kick Ass Kickoff Meetings

by Kevin M. Hoffman
on January 24, 2011

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.

Send Us Your Comments

How do you prepare for kickoff meetings? What techniques do you
employ to be sure team members leave those meetings full of ideas to
explore? Share your thoughts with us in the UIE Brain Sparks blog.