Kick Ass Kickoff Meetings

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?

Article Continues Below

Illustration:

Translations:

Share This:

Job Board

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.”

WhatWhen 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. Here’s one that works exceptionally well for building culture.

Find ideas, culture, and trust with a design studio

The design studio is a traditional approach to ideation in industrial design and architecture. It involves iterating repeatedly through four phases towards a design goal: Sketching, evaluation, modeling, and testing. In his book Prototyping, Todd Zaki Warfel adapts this methodology to website and application design by modifying a few phases in the process, ending up with sketching, critique, prototyping, and testing. For a kickoff meeting, the prototyping and testing phases may be entirely too ambitious; time is limited and it’s probably too early for any usability testing. For those reasons, my team has modified this approach by eliminating the second two phases, and creating an exercise that cycles bewtween ideation/sketching and critique. Depending on the size of the group, it can be done in as little as a few hours. It can be executed with groups sized 10 to 60, and it always gets great discussion going, surfacing key challenges from every perspective. All it takes is a few pencils, some pre-printed grids, a good facilitator, and a basic meeting interaction pattern.

A design studio kickoff activity works like this:

Find a space that can accommodate half the number of attendees having a one-on-one conversation simultaneously. For groups of 10, a traditional meeting room is fine, but for larger groups you may need more space. Plan on at least 90 minutes—more for larger groups.

Instruct everyone that, to begin with, they will be sketching ideas on their own. Some will complain about their drawing ability. Suggest that they describe their ideas in text. If that doesn’t work, tell them to suck it up. No one ever died from sketching.

Frame a specific design problem. You can take a general approach, such as “design the home page,” but in practice I’ve found this works better with some constraints. It helps start the neurons firing if you set boundaries: For example, you might say “design a sub page that focuses on the key product line we offer, but also provides three examples of how our audiences already use it.” Or even as specific as “build a category listing page that encourages people to apply their own tags, but still provides more traditional navigation paths to information, and somehow gets them to create a user account.” Remember, this is early in the work, so even if the contraints aren’t 100% accurate to the real world, you are only exploring and learning.

Provide a time limit, and a minimum number of concepts to create: Six to eight concepts in 10 minutes is what we do. The time limit forces participants to focus on quantity and iterate quickly, rather than sketching out the Mona Lisa.

Play some music to kill that awkward silence! I recommend the theme from a classic game show, or the battle music from the original series Star Trek episode Amok Time.

Form groups of two, and (this next part is important) have them pair up with someone who they’ve never worked with before. If you are an agency working with a client, pair up agency employee to client representative. If you are working on an internal team, then go cross department.

Instruct all the two person teams to take turns presenting and critiquing their ideas. Again, keep a strict time limit. Have the first person present for three minutes, then other person critique for two, and vice versa. While they are presenting/critiquing, give each person a single grid sketchboard.

Instruct all the groups they have 10 minutes to sketch a single concept based on the best of all of their ideas.

Repeat steps six through 11, increasing the size of each group by a factor of two each time. Two people become four people, four become eight, etc. You may need to increase the amount of time people have to sketch based on the size of the groups.

When you’ve got it down to two or three large groups, have the groups present to each other. At larger kickoffs, provide them with larger sheets of paper, sharpies, or even sticky notes to help them be more creative during that final concepting phase. Make sure you have the ability to project the final sketches for discussion and critique, such as a document projector (if you’re fancy, Nancy) or a digital camera and the right cable to get its contents onto a laptop/projector (if you’re like the rest of us).

There are many benefits to incorporating a design studio activity into a kickoff meeting. You are kicking off the project by beginning to tackle many of the problems at hand. You are getting to know your client or coworkers better, building your understanding of their communication styles, personal priorities, and work dynamic. You might even come across a usable idea, and you’ve done it in a collaborative context rather than an adversarial one.

This may seem like design by committee, but your expertise has been part of the process, and whether or not the ideas you generate are finished-product quality or completely useless, you’ve engendered shared ownership of the intended end result. This collaborative experience lays the foundation for a professional bond that will sustain the group through the many challenges that lay ahead.

What else can you do at kickoff?

There’s no reason to limit your kickoff meeting to a single activity. In fact, you can combine multiple activities at a kickoff, with each activity appropriately tailored to a specific problem, and with the appropriate attendees (which prevents a vice president from having to learn about complex server architecture goals in gory detail).

Too many people focused on “the shade of blue” and using comic sans? Develop your client’s understanding of good art direction by scoring a series of gut reactions to other websites (or even other visuals).

Are your vice presidents asking “why aren’t we on the Twitter and the Facebook?” Educate stakeholders about holistic social media strategy with the Social Mania card game.

I’ve assembled a repository of some the activities we’ve tried at goodkickoffmeetings.com, and I want to keep adding to that list. Let me know what variations and new activities you come up with, and how they create value for your project down the line!

But what about me? I’m virtual!

Perhaps you only work remotely with clients, because you either can’t afford the travel or don’t feel the need to meet with them face-to-face. Keep in mind that the spirit of these approaches is about building relationships early in a process, and in-person human interaction is a tried and true method for doing that. That said, as long as you are following the guiding principles I’ve outlined below, you should find some ideas and approaches using other means (Skype, Campfire, or sharing ideas via a magical application) that will inspire your process for getting a project off on the right foot.

Open up your kickoff process to as many people as possible. It’s better to include too many people up front than find out you overlooked a valuable player late in the game.

If you are going to have multiple activities at a kickoff meeting, or even multiple meetings, it’s important to have a good facilitator that remains a constant, and understands how it all fits together.

Build activities around collaboration and “no risk” exploration. This is the time to explore the full potential for what is possible. Even if you venture out of the previously discussed scope, you are still fermenting ideas that could build a road map for additional work in the future.

Introduce fun, creativity, and energy into to your process! Don’t be afraid to force people outside of their comfort zone. Attendees will be thrilled to break from a more traditional meeting agenda, anyway.

About the Author

Kevin M. Hoffman is an information designer/architect, design strategist, speaker, and teacher who has been building stuff with bits and pixels since 1995. He was Happy Cog’s first User Experience Director and the Director of Digital Communications for the Maryland Institute College of Art (MICA). Kevin appreciates your valuable time. He’ll thank you personally for that time if you contact him on twitter.

More from this Author

18 Reader Comments

More from ALA

Columns

How sustainable is a model where social networks take a central role in our daily routine? Antoine Lefeuvre believes there’s growing awareness that social networking tools don’t necessarily bring out the best in us. While we do want and appreciate tools that let us engage with others and do things together, we’re getting tired of the high price in attention and stress.

We take it for granted that career progress means moving into a management role. Even people who thrive in the individual contributor role feel the pressure to join management. Shouldn’t both capacities be valued, so we can find where we genuinely fit in and do our best work? Rian van der Merwe has gone scouting up the career path and realized it’s okay to turn back and be the other, oft-overlooked but equally important half of the management/making dynamic.

February 19, 2015

From the Blog

This week, the ALA staff is thinking about color accessibility, the process of building a vocabulary, the current state of web typography, and the lessons we can learn from skater culture. In other words: it's all about inclusion.

A decade ago here in A List Apart, we published a radical article by Peter-Paul Koch arguing for custom attributes in markup. Today, Mat Marquis takes a look back at how times have changed, and shows how PPK’s idea has worked its way into the web.

New content projects present a classic chicken-and-egg problem: should we start with the words, or focus on the structure they’ll take? There are benefits and challenges either way, but Eileen Webb has recently become a believer that starting with structure creates a better workflow for developers, designers and content creators alike.

It’s a new kind of blog post: straight from our brains to your hearts, we’re sharing what we think is neat on the web. This week: thoughts on Flipboard, diversity in tech, and advice for organizing conferences.

Ready for something new? We're excited to announce ALA: On Air, community-focused events where our readers can get to know our authors, staff, and others who are shaking up our industry. Mat Marquis shares all the details, and has specifics on our first event, Designing for Performance, coming up on February 26.