I’m sitting in a room with an entire team of new people. I haven’t really had a chance to meet them yet. Most of my interactions have been with the person tasked with reserving space, setting up interviews, keeping us fed, and not the team at large. I’m jet lagged and my allergies are kicking in. I know this is a critical part of the process, but I just want to start building something.
The client has their own development team and I can guess what they’re thinking— I remember my first time through this process. Even with my experience, I have to exercise a little restraint to keep myself from jumping to solutions to solve all of the users’ frustrations. This isn’t the time for that. We’ll get there, but not now.
This is the project kickoff. We are here to figure out where we should go as a team.
Project Kickoff
There are two goals of a project kickoff: establish a team working agreement and learn about the problems.
We’re all good at our jobs and work well with others so establishing a working agreement may sound unnecessary. The outcome of the working agreement isn’t to dictate behavior, but to set expectations. That is best done collaboratively. The entire team, not just the few people who signed the contract, needs to participate in goal setting and they need to have their concerns heard. The goals and anti-goals activity is a good forum for that.
The second of the goals, learning about the problems, is perhaps the easier one to understand. In fact, most of the time the project kickoff will revolve around learning about the users and their problems. We’ll do that by conducting one-on-one user interviews, creating process maps with larger groups, and doing our best to witness the users’ frustrations in the wild.
A tricky, subtle point here is that we are not filtering the list of problems to solve yet. We’re asking users about ALL of their problems. At this stage, we don’t know which solutions will generate the most reward. We’ll figure that out by identifying all of the problems we hear about in interviews and mapping them to the goals and anti-goals for the project.
Goals, Anti-Goals, and Risks
We’ll use the same activity to uncover the goals, anti-goals, and risks to the project.
At the start of the activity, everyone is given some sticky notes and a Sharpie marker. We’re all given a few minutes to spend on writing down our thoughts, one each to a note. Then we’ll move to the whiteboard or wall, and say what’s on the sticky note so the entire group can hear it. We repeat that until everyone’s sticky notes are on the whiteboard.
We structure uncovering the goals, anti-goals, and risks this way for a couple of reasons. Hearing everyone in a large group of people requires some intentionality. In this activity everyone has a chance to think, to talk, and to hear what everyone else has to say. It allows people to build on what others are saying since we don’t take the Sharpies and note pads away from people when the talking starts. People can write and add to the wall at any time.
We start out with something positive and have everyone write down all of their goals for the engagement. We first have to establish what we want to accomplish before being able to identify the anti-goals and risks.
Anti-goals often need a little explanation. They’re false friends, things that sound good or features that users want but they distract from the goals of the project. An online store doesn’t need a cash register in the office and an application that only works on the office intranet doesn’t need native iOS or Android applications. Anti-goals are often things that are nice to have but provide value to only a few users.
Having come to an agreement on what the goals for the project are, we’re in a position to identify what will put those goals at risk. An important note for this activity, is that we are not solving for those risks at this time. We’re only identifying them.
Process Mapping
After taking a break, we probably took several breaks in the first activity too, we’ll reconvene to create a process map. We’re going to use sticky notes again, but not everyone needs to write.
We’ll start by writing down the roles people play in a column on a whiteboard. To provide clarity, we’ll write down the name of the person who has that role and is in the room with us. To get the full picture, it’s important that all roles are represented by at least one person in the room. Then we start with the first activity in the process, write it on a sticky note, and place it in the row with that person’s name. We use sticky notes here because often activities have to be moved around as steps are sometimes so ingrained that they can be forgotten.
A process mapping conversation to ship an order might go like this:
Zach (facilitator): So what happens first?
AJ (client): A customer calls in with their order.
Zach: Who gets the call?
AJ: A customer service rep like Sam.
[Zach places the sticky note in the Customer Service row.]
Zach: So the call goes directly to Sam?
Ray (client): No, we only have one incoming line, so it goes to me first and I route it to customer service.
[Zach moves the sticky note to Ray’s column.]
And so on.
This is often boring for the client’s development team. They implemented the call switching software so they know how calls are handled. Here we need their indulgence and their participation.
The users are the experts at what they do. The developers often contribute details that users may consider insignificant— but aren’t— or that the users overlook. We’re just learning the business and having everyone in the room helps us learn it quickly. We’re there to ask questions and take notes. At the end of the exercise, we all leave with a better understanding of how things are done.
User Interviews
This is the only activity that doesn’t involve sticky notes— though I suppose they could be used for taking notes.
User interviews require the smallest number of people: an interviewer, a note taker, and a user. There’s no magic here. The interviewer asks questions which the user answers. Having a note taker allows the interviewer to be fully present in the interview and not have to switch between curiosity and recording. An interview best practice is to keep the group small; it can be intimidating to present to a panel. Having only two others in the room helps put some users at ease.
If possible, the interviewer will watch the user perform their day to day tasks in the current system. This observation provides the most depth out of all of these activities. The interviewer can ask what cues in the system mean, form connections between activities and the process map, and watch where the user struggles.
Watching that struggle is the most frustrating thing we do. It doesn’t matter that I didn’t write the program they’re using, I still want to jump in and help the user do their job. It’s human nature, we don’t like to watch people struggle. If the client has a development team, I can more than sympathize with them wanting to jump in and quickly offer a solution.
We have to resist that temptation. That struggle is critical to uncovering the problems the users are facing. Problems often can’t be articulated in a meeting. They can always be witnessed. If we don’t see the struggles, we’re not getting the full picture of what people are experiencing.
Next Steps
When the goals are identified, the process mapped, and all of the users interviewed we’ll head home and digest what we’ve learned. This will involve transcribing our notes and converting stickies to a digital form.
Once we have all of the data, we can dive in and analyze it. We’ll convert the user interviews into personas that we can keep in mind as we walk through parts of the project. We’ll use the goals and the process map to identify the high value problems to solve.
The main work of the project happens after we know which problems we’re solving. We’ll work with the users again to create and validate user stories that solve the problems we’ve identified. The developers will shine by breaking down those stories into features and then implementing those features for their users. We’ll work with the designers to come up with the most intuitive workflow, again using the personas as a check for our work.
These goals help us shape the end of the engagement. We don’t want our clients to become dependent on us. We come alongside a team and provide a little extra help for a while. We can provide insight from a wide variety of projects and learn a new business domain from every client. Clients benefit from our breadth of knowledge while we benefit from their depth of knowledge.
The process works for everyone.
