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?#section2

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?#section3

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?

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!#section4

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#section5

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#section6

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 #section7

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#section8

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:

1. 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.
2. Give everyone a pencil and a sketchboard with eight pre-printed small grids (provided by Mr. Zaki Warfel).
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. Instruct all the groups they have 10 minutes to sketch a single concept based on the best of all of their ideas.
10. 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.
11. 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?#section9

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

Here’s just a few examples of other activities you can use:

• Got competing business priorities? Assess them collaboratively with your leadership using a priority and feasibility plot or even a card sort.
• 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.
• Are there too many cooks in the kitchen? Try having a conversation in a fishbowl.

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! #section10

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.

Those guiding principles#section11

• Do as much research as you can before your kickoff meeting, and design your meeting agenda to strategically address the ideas and challenges you learn from that research. For more insight into stakeholder interviews and requirements gathering, check out Exploring Requirements: Quality Before Design by Gause and Weinberg, and Putting Context into Context, by Jared Spool.
• 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.

Now kick that ball across the field, sending your project flying into conceptual glory and web design infamy!

Or, just have a much more engaging, relevant, and productive meeting.