The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #141 Kevin Hoffman - Facilitating Project Kickoffs

August 19, 2011  ·  28 minutes

Listen Now

Download the MP3

A good starting point is crucial. It sets the tone for everything that comes after. All too often, projects are unsuccessful or labor through growing pains because the importance of this starting point was overlooked. When done right, the kickoff to a project will leave the team energized, inspired, and engaged. Kevin discusses that kickoff meetings are the time to identify business strategy as well as company culture. It’s also important to assess any risks associated with the project.

Show Notes

A good starting point is crucial. It sets the tone for everything that comes after. All too often, projects are unsuccessful or labor through growing pains because the importance of this starting point was overlooked. When done right, the kickoff to a project will leave the team energized, inspired, and engaged.

Kevin believes that kickoff meetings are the time to identify business strategy as well as company culture. It’s also important to assess any risks associated with the project in the kickoff meeting. Getting as many people involved at the onset of a project will help make the connection between project goals and the brand of the organization. It ensures everyone is on the same page.

Tune into the podcast to hear Kevin address these questions:

Full Transcript

Jared Spool: Hello everyone. Welcome to another episode of the SpoolCast. I'm Jared Spool. I'm your cruise director for the day.

I am very excited to be talking today to Kevin Hoffman who is the Experience Director at Happy Cog and going to be speaking at the User Interface 16 Conference in November of this year, 2011, on creating great kickoff meetings for projects. I'm very happy to be able to talk about that with Kevin today.

Kevin, how are you doing?
Kevin Hoffman: I'm doing well. Thanks for inviting me to hang out this morning.
Jared: Well thank you for joining me and hanging out here.

So, kickoff meetings are this thing that we don't really think about. You know, when we're putting together this massive project and we're thinking about what the design could be and the delivery dates and all this stuff, it's almost the last thing we think about.

But it turns out that if we don't do that right, if we don't get that project started off on the right foot, awful things can happen, right?
Kevin: Yeah, I think so. I think it's been my experience on both internal teams and doing consulting projects that people put about as much thought into the kickoff meeting as it takes to create that little line on a Gantt chart that shows in a project plan where it's going to happen.

They'll decide who needs to be there, but it usually ends up being not dissimilar to an Alcoholics Anonymous meeting where you go around the table and just kind of introduce yourself and your role. If it's an external consultant, usually you're introducing people to yourself for the first time, so there may even be some basic orientation like "who is our company?" and "why are we here?" and "who hired you?"

The kind of problems that that will create for a consultant or a third party is that kind of the classic swoop and poop. Where high level stakeholders will be coming in later on in the project because they didn't know who you were, they didn't happen to know that this was going on.

The kickoff meeting gives you a great opportunity to establish a lot of shared vocabulary, some shared vision and really, more than anything, establish culture and kind of your working culture between two or more organizations, as the case may be. By establishing that culture, people are much less likely to become interrupters and more likely to become information resources.

As I alluded to before for internal teams, I have a long background working on internal teams in higher ed and non-profits. And the risk for internal teams, I think a kickoff meeting can establish kind of an energy baseline.

For internal teams projects tend to run usually a lot longer than they do with consulting projects. So you might be doing a redesign for your main website or for an intranet that could take 18 months or two years, depending on the size and complexity of the organization and the project. And after about six months of anything people get tired.

But if you have a good kickoff meeting where you're establishing your expectation of energy and kind of being really open with a broad set of stakeholders in your organization in a more workshop collaborative format. It just kind of creates a positive energy that people will remember.

So a month later when they think of something that's relevant to the project, they're going to be excited to talk to you about it.
Jared: So I like this idea of establishing an energy baseline, I mean, just getting everything going on this high energy element, getting people excited.

And the people we're talking about here are not just the folks who are going to be up to their elbows in pixels and wireframes, you know, the core design team. We're talking about getting stakeholders and various other folks from the organization involved, right?
Kevin: Yeah, absolutely. I think really ... I've never seen it work exactly this way, but it kind of, sort of follows this pattern. Where, at Happy Cog, if we'll do our kickoffs correctly and we have enough time to plan them, which isn't always the case but it's usually case, the level of engagement in our partner organizations tends to follow a reverse pyramid. In that, the longer the project goes, the fewer people we're directly corresponding with.

We want to correspond with a decent number of people at the beginning of a project especially in a meeting, not just via one-on-one interviews or phone conference interviews. We really want to kickoff the project with that first meeting with as many people as possible.

Because we've found that as open and honest as people are willing to be our direct contacts, there's always a larger picture of an organization. That you can only get from talking to as many different appendages on that elephant, as opposed to just kind of taking the elephant's mouth's word for it. And having that better picture allows us to identify risks for a project early on, address those risks. And, if we need to, occasionally be really frank about what we may not be able to do, as opposed to it coming up three months down the line.
Jared: I think that's really neat.

What you're doing here is this combination of sort of setting out a picture of where you think you want the project to go. While at the same time trying to reveal as many of the constraints that that project's going to be under. And also set some of the boundaries as to, you know, where things start to get into science fiction and unrealistic expectations.
Kevin: Yeah, absolutely. The other thing I feel like it's really important to convey in a kickoff meeting, and the way we do workshops generally is that, if we're taking the time to do a workshop, there are two things that I want to make sure are clear to the participants.

Number one, we've taken the time to prepare ourselves for the work at hand. So we don't like to kick off a project without doing a lot of research. If all we can do is landscape research and just really look at the design problem and how different people are solving it, that's great. But more than often what we prefer to do is do a lot of one-on-one interviews with stakeholders and some light audience research before we go into that meeting.

So we're coming into that workshop with a more sophisticated idea of the design problem at hand. But we're not coming in with the solution. We're inviting all of these people to this kickoff meeting because we think we have a good idea as to what the problems are. But we really want to collaborate with you and work together to develop the framework for starting to build that solution.

And in a best case scenario for us, usually working with smaller organizations, we've seen that actually lead to design decisions during the first meeting. Where, you know, we've decided, for example, page priority for a particular page on the site or a particular e-commerce process, where in that kickoff meeting we've said, "You know what? This is the primary design goal of this page and these are the three or four most important kinds of content that are going to support it." And that's the best case scenario.

But in the worst case scenario, with larger clients if we have a kickoff meeting with, let's say, 80 or 90 participants which has happened from time to time, that sets kind of a project awareness in a larger organization of 500 people or more, sometimes a lot more.

And that really pays off down the line in terms of people looking forward to the next meeting that they're going to have with you. And ending up with a really good meeting structure for complex, longer projects where people expect they're going to have a chance to have their voice heard. And it's not like they're fighting to participate in the project.

In fact if you think about it, a big kickoff meeting is great. In that if you open it up, if you kind of have a philosophy of anybody can attend this meeting if they want to, they just have to let us know who they are and it kind of eliminates that, "You didn't talk to me" vibe.
Jared: I want to talk about for a second something you said at the very beginning which was, this helps the team sort of establish a shared vocabulary and a shared vision. And I'm curious if you could say a little bit more about that shared vocabulary.
Kevin: Sure. We've worked with lots of different companies. Sometimes they're non-profits and smaller, sometimes they're non-profits and larger. Sometimes they're for profits and very large. And sometimes they're startups where they have a decent investment and it's a small group of people.

What I have found more recently, or I've observed more recently, and this is kind of an ongoing observation, is, if I was to generalize. The larger an organization is, seemingly the less time it has to actually remember and pronounce out loud particular phrases and repeated words. And the more things become acronyms.

So, recently we pitched some work to a very well known computer manufacturer and electronics retailer. And in the correspondence alone, I had to sit down with our business development person every couple of minutes and say, "I don't know what this word is. I don't know what these three letters mean."

There was just all kinds of internal jargon that was preventing me from being able to understand what the strategic request was. Because every time I would hit a term that was unique to that culture, I would hit a brick wall and have to say, "I don't understand what this really means." And, therefore, how it might affect the strategy I would recommend for this particular project.

So by getting in a room together and being very open and unafraid to say, "Hold on, does everybody know what XYZ is? We keep talking about XYZ." Nine times out of ten it's something you already know or it's something you knew but just forgot. But I would say 10 percent of the time there are some pretty complex ideas that get almost compacted for consumption so that people in an organization can be more efficient.

And when you're joining that organization, it's a lot better to collaborate on that learning than it is to send an email requesting a glossary. Because I would say 99 percent of the time those glossaries don't exist. Those cultures just continue to develop without documentation.

And to really get up to speed and work at the level that our clients expect us to, we need to know what all those things mean. So when I say shared vocabulary, it's a little bit more on the consulting side, getting up to speed on the vocabulary of the client.

But at the same time, we try to construct activities in a workshop format that allow us to give them kind of a micro taste of what our process is. And what kind of things we're going to show them over the life of the project. And how we expect feedback to come back to us so that we can use it to continue to iterate on whatever we're doing.
Jared: So, is some of the vocabulary that you're also establishing around things like what differentiates a good outcome from a bad outcome? I mean, is there a terminology that sometimes gets created in these workshop meetings that then gets referenced throughout the rest of the project?
Kevin: Yeah, absolutely. We pay close attention to everybody but particularly high level stakeholders. So that, when we deliver strategic recommendations in the form of a brief or in the form of an early prototype, we can reference concepts, specific words, specific ideas that came up in that kickoff meeting.

So there's a fluid feeling to the process, not that we're just throwing things over a cubicle wall or across the Basecamp wires as the case may be. We're actually having a conversation for the duration of the project, and that kickoff meeting is the introductory hello in that conversation. It's the first date.

In any great relationship, a personal relationship you want to have a first date, ideally, where you feel like you made a connection and you want to build on that connection. So to just throw away your first date as a, "Oh well, we've already agreed that we're going to work together. So let's just get lunch", you know, is kind of a waste of everyone's time and energy.
Jared: And you mentioned also this idea of a shared vision. And I guess some of this we sort of have been not really talking about this. You and I have talked about it before, but we haven't talked about it here which is, this is not just, you know, a 45 minute meeting that you get together with, right? This is an event that goes on for a considerable amount of time. How long is your typical kickoff workshop?
Kevin: I would say it varies based on the duration of the project.

So if we're doing a project that exceeds a year, a yearlong or 18 month or two year engagement, our kickoffs generally fall between a full day and two days. If we're doing projects that are six to nine months a minimum of four hours.
Jared: So you've got these things that are four hours to a couple of days and so in this real work is getting done. This isn't, like you said, this isn't like an alcoholics anonymous meeting where everyone goes around the room saying, "Hi, I'm Jared and I've been at this company for 12 years." Everyone goes, "Hi Jared." You guys roll up your sleeves and you do stuff.
Kevin: Yeah. We try to come to come into a kickoff meeting armed with a significant amount of insight into the client's perspective on the problem and a significant amount of insight into the market that the problem is designed to address. And that includes the audiences that something is intended to reach, but also it includes competitors and even things that are going on in design solutions that are analogous to what we see the problem as being and what our clients are telling us the problem is.

Many, many times it's been my experience that if you come to a kickoff meeting with something that has nothing to do with the vertical that the clients in. So ,if they're in widgets and you come in with something going on in cupcake sales that's completely analogous and makes total sense, that people will be very responsive to that. And they'll feel like you've thought about the problem.

So then during the meeting, the work that we do is we actually say, "So how do we make cupcake sales work for widgets? How do we actually do that?" And that usually takes the form of a lot of sketching and prototyping. It takes the form of a lot of frank discussion about prioritization and understanding the dualities of particular things that people are asking for? One thing I've heard a lot of recently is, "We want it to be really easy. We want people to be able to do things in one click and we want it to be obvious."

"But we also want them to do a lot of cross sell and up sell and make sure they can find any product they need." And at their core those two things could be done in ways that they would be at odds with each other. So really working on articulating conceptually how we can make those two things happen at the same time. And lots of other design goals and various user interface challenges that we want to hit, we want to address those as well. One example that I can think of from a kickoff meeting not too long ago probably in the last nine months.

There was a workshop that we did about search user interface. So spending a good hour in small groups thinking about what the current search metrics were telling the client, what their referral search metrics were telling the client, not just internal but the referrals as well. And then what they actually wanted people to do as a result of a search. Not just being able to find the thing that they need. Like, I need product X I want to type it into the box and it shows up, but what do they want people to do with product X after that? And how do we design search and search results to balance those user goals with the real business needs that the client had.
Jared: So, this is really interesting to me. So one of the things that I hear you saying is that there is a lot of work that you do before the kickoff. So the kickoff isn't the very start of the project. It's not the moment that everybody starts the billable hour clock or you know, gets the first say, "That's where we started." You've done a whole bunch of work to get into this kickoff meeting.
Kevin: Yeah. Generally during the sales process we try to establish the expectation with clients that before we meet with you we're going to want to do research and that may take on average about two weeks. Usually we do it in less. But from the time we sign a contract to a kickoff meeting two weeks is reasonable. Now we have I would say a third of the time at Happy Cog and I'm sure this happens on internal teams and with other consultants. You get clients who have a check ready to go and they just want to start tomorrow.

And from time to time we do do that and we try to have enough of a playbook of kickoff activities in our pocket that if we have to jump into a productive meeting quickly with a client where we don't have a lot of in depth understanding of the problem. We spend a day reading as much as we can and we tend to do a lot more listening in those situations. But most of the time we will spend just to throw out a random number, a minimum of a dozen one hour interviews with key stakeholders. And from time to time upwards of 30 and once or twice many more than that.

Just learning about a client's organization, learning about the design problem, learning about people's expectations especially if it's someone who isn't necessarily our point of contact but somebody who has a very different perspective on why this project is happening. We want to hear all those things up front. So we can start to connect some dots and identify some of that science fiction as you said.
Jared: And one of the outcomes of this you mentioned was the shared vision. This is something that I've noticed with teams that we work with that haven't done a good job of this upfront. You start talking to people, "So what is this thing going to be like" and everybody is working on a different project. So it sounds like part of your goal with these kickoff meetings is to get everybody walking out of the room believing that you're all working on the same thing.
Kevin: That would be the best case scenario and I don't think that's impossible. I do think that a more realistic way to put it is I want everybody walking out of that room expecting to see a vision in the very near future. And there shouldn't be anything in the vision that we articulate that doesn't feel like news to them, like, "I've never heard about this before."

So for example, in a kickoff meeting we might spend some time talking about how social networks or you know, things like Facebook might integrate into a particular experience and why it makes sense or it doesn't make sense. We won't articulate a detailed vision for the social component of a project probably until the brief, but they know its coming and they're ready to read it and tell us what they think.
Jared: OK. So a lot of folks who are listening are probably not in a situation where they can just call a meeting that gets all the stakeholders together and make all this work. They probably work for someone else who is probably leading these kickoff meetings. What advice would you give them for getting those meetings to be productive so you can get that shared vocabulary, you can get that shared vision started and start bringing that out.
Kevin: This is something I don't think is only related to kickoff meetings. I think there's a lot of really good techniques and approaches that apply to any kind of meeting situation where things are not going the way you would like them to go. So one of the things that I've said in the past and I will still say is that the more you educate yourself about any type of approach for designing human interaction, and I mean in person human interaction not electronic human interaction, in a meeting.

If you know of good ways to build consensus, if you know of good ways to explore a design problem, if you know of good ways to kind of iterate in a discussion or ways to facilitate large numbers of people getting a chance to get their voices heard. The more you know those techniques the more you can rely on them when things don't go the way you need them to go.

So for example if you're in a meeting where you feel like the point is to generate ideas and the quantity of ideas is very low, you're not trying to evaluate quality. If you have sticky notes and sharpies in the room, in your conference room in advance and you're familiar with KJ technique or other techniques, you can always suggest those as a participant. Like let's just try this for five or 10 minutes and introduce things that maybe get people out of their comfort zone in such a way that it forces them to refocus their attention on the task at hand, and not just, "Ah, I'm stuck in another meeting" or "I'm stuck in this kickoff meeting."

So I think that's the first thing is knowing what some of the things that you're trying to get out of a kickoff meeting are. Whether it's problem exploration or consensus or problem definition, and then knowing what the best ways to design human interaction to get at those things are and suggesting them when you need to. The second thing I would say is if you're a participant and you're not a leader, you have the right to demand agendas and demand clear agendas.

And if it's not clear enough or it doesn't address what you need it to address, you have the right to suggest agendas and say, "I need this item added to this meeting." Now, inevitably what that leads to more meetings and I realize that. But at the same time if you don't suggest it you're really spending just as much time not doing the work that you need to do and not getting the things addressed that you need addressed in order to move forward.

So, you know, I would say sometimes it's OK to have more meetings or an additional followup meeting for a kickoff meeting as long as you're getting stuff addressed the way it needs to be addressed. An example of that would be the way normally in which high detailed technical discussions happen with our kickoff meetings. We like to have our developers and our technical experts at our full kickoff meetings which is an expense.

It's a real expense to have a developer in a room for eight hours focusing on UI and project strategy. But then if we can take someone who's got that level of knowledge or has been a part of that discussion and then immediately afterwards put them in a smaller discussion that focuses on server architecture and CMS choices and other highly technical issues, our projects have a lot more of singular vision.

And in the future when I'm doing IA work or UI work and I say to a developer, "You know, this is how we need press releases to function and this is how date search works." Not only do I know the technical things that they have thought about in advance, what systems and what limitations of those systems are, but also they know why it's important. And that makes that kind of gap that sometimes happens between concept and production much, much smaller.
Jared: Plus they can come back and actually suggest things up that you may have not thought of.
Kevin: Exactly. And that happens a lot with us.
Jared: It feels like that these meetings are very productive and that to some extent there's this kickoff workshop but it's just the start of something that goes on for a while. And they're mini little workshops that happen throughout the project that feed off of that and keep going, right?
Kevin: Yeah. Absolutely. With our larger clients we actually have kickoff by phase. So we have project kickoff, we have IA kickoff, we have visual design kickoff, and we have development kickoff. And we tailor those meeting attendee lists directly towards the amount of cohesion we detect at that point.

So a lot of times our development kickoffs if we know there's an internal development team, we'll just invite them to our offices and really go through every single design page by page and say how would we code this? You know? And collaboratively sketch out how the line by line code is going to fall into place. Now I don't attend all of those meetings. I attend some of them when I can but it's the same workshop methodology applied to coding and we apply it to visual design and Brand and we apply it to IA but it works at all levels of the project.
Jared: So in essence here what we're talking about is developing just a great set of facilitation skills and tricks that let you make a group of people in the room be really productive in terms of moving the project forward and getting everybody's sort of, point of view into the design and the designs direction into the folks.
Kevin: Yeah. Exactly.
Jared: That sounds incredibly useful. Well this has been really, really interesting and I can't wait for your workshop which is going to be at the User Interface 16 Conference in November in Boston. To our audience if you're interested in attending that you can get more information on Kevin's workshop at the UI16 conference site which is cleverly called UI Conf, I highly recommend you check that out. Kevin thank you so much for taking time to talk with me today about this.
Kevin: It was my pleasure.
Jared: Excellent. And I want to thank our audience for listening once again and as always I want to thank them for encouraging our behavior. Take care and we'll talk to you in another Spoolcast.