Begin the Project

Starting a research project can feel manic. There’s lots to organise: briefs to write, objectives to agree, and stakeholders to bring on board. It’s easy to feel like you’re being swept away on a sea of madness. But with a bit of organisation, it doesn’t have to be overwhelming. If you get the setup right, the rest of the process will be less stressful and more productive.

In this chapter, we’ll show you:

• How to start off a project effectively.
• What to expect at each stage of the project.
• How to ensure your project generates action at the end.

Get Started

To make sure you’re making a good start, it’s helpful to refer to the checklist below, and tick off the things you need. It’s also a good way to structure your activities.

1. Define Your Research

You will probably already know there’s a need for research, but at this stage it might be quite vague. It’s your job to get clarity about the research objectives, otherwise your work will be unfocused, and less likely to achieve anything useful.

With your colleagues, you need to define your objectives. These fall into two categories:

• Business objectives are the end goal of the project. An example business objective: increase conversion rate by 5%.
• Research objectives are the learning goals of the project. An example research objective: understand how customers buy shoes for their children.

You should also expect some objectives to be more obvious than others: ‘overt objectives’ are the ones talked about openly, while ‘covert objectives’ are kept quiet (but are no less important). For your project to be considered a success, you’ll need to take into account both the overt and covert objectives.

Your objectives are the single most important element in your project. As you proceed, you’ll continually return to them: to help choose the right methodology, to shape your questions, to check you’re on track, and to inform your analysis.

2. Define Hypotheses

When you define objectives, you’re laying out the questions you want to answer. When you define hypotheses, you’re making your best initial guess at what those answers will be. The rest of the project – asking users and conducting analysis – is the process of checking, challenging and refining your initial answers until you’ve reached solid conclusions.

We use two kinds of hypothesis in our research projects:

• Formal hypotheses are statements which can be tested against the data to determine if they’re supported or not. For example: “Regular shoe-store customers own more pairs of shoes than occasional shoe-store customers.” This kind of hypothesis is used in quantitative research, and if you’ve conducted experiments at university, you’ll probably be familiar with it.
• Rolling hypotheses are early-stage theories or explanations that evolve throughout the project. Think of them as hunches or assumptions, which you can evolve, add to or reject by observing and talking to users. Rolling hypotheses start off vague, and become more solid as you proceed. This kind of hypothesis is used in qualitative research, but is very similar to the process of learning more about any subject you previously knew little about.

When you start a project, it’s helpful to get all of the team’s assumptions (hypotheses) out in the open, so you can incorporate them into your questioning.

3. Timeline & Resources

In most research projects, time is of the essence. Generally, you’ll be working towards a deadline, or in a fixed cycle of sprints, and you’ll need to shape your approach accordingly. Also, you’ll have finite resources to work with.

Defining the right approach in terms of timelines and resources – and ensuring you’re able to stick to it – is one of the main skills of running research projects. You may be lucky enough to have a dedicated project manager, but if not, you’ll be in charge of putting together the plan, and reviewing progress each day to check you’re on track.

4. Engage Stakeholders

If you want your research to have an impact, you’ll need to make sure your colleagues are engaged in the process. To do that, you need to be communicating and collaborating throughout the project, not just at the end. The earlier you get started, the more stakeholders will care about your results, and want to own and act on them. Therefore, you need to plan.

The trick to successful communication is to think of it as an ongoing sequence, rather than one-off messages. Think strategically and plan it as a campaign, running from the beginning of the project and on past the final documentation. We’ll show you how to do this later in the chapter.

5. Identify Risks

All projects have risks: things that might go wrong. It’s important to face up to these possibilities and plan for them, rather than just hope for the best. Otherwise, you may find you get caught out, and the project runs over time or budget, or threatens to under-deliver.

Risks emerge throughout the project, but nonetheless you should have a pretty clear idea at the beginning what might happen, based on the team’s collective past experience. If you deal with these possibilities openly, you can agree on an appropriate response (which might be to take no action at all!). Either way, tackling risks is a decision for the whole team, not one you should have to take on your own.

Tools You Can Use

Now that we’ve described the building blocks you need to get started, it’s time to look at the tools you can use to create them.

Use Desk Research to Generate Hypotheses

Desk research sounds dull, but it’s actually a great way to get your head into a subject right at the beginning. If you approach it creatively, you can use many different approaches – see below.

Spend some time looking at the site and service that you are working on. Take a look at the top competitors as well. This can often give you insight into problems, directions you may want to head in or even things to avoid. Look on forums, review any analytics you can get hold of and chat to your colleagues for any insights they may have. This can all help set the direction of your research.

Don’t feel like you need to take ages over desk research: you can achieve a lot by choosing two or three of the methods above and spending a couple of hours in total exploring them. As you go along, write your hypotheses on Post-It notes. There’s no right or wrong choice of method: just go for the ones that are easiest and quickest for you to use.

Hold a Kickoff Workshop

Whatever else happens, you should always hold a kickoff workshop for your research project. This can vary in length. For a sprint, it may only be half an hour; for a large-scale project with a new team, it could be a whole day.

Kickoff workshops follow a standard agenda:

• Introductions: If the team don’t know each other, it’s a good idea to go round the room so everyone can say their name, their role, and their relationship to the project.
• Provide background: The main sponsor (ie, normally the most senior person in the room) should provide an introduction covering the reasons why the project needs to happen, the business, and the context. Note that the main sponsor is the starting point for understanding the project, but it’s not the only point of view that matters: there will be other stakeholders and other perspectives that need to be taken into account.
• Agree objectives: Ask all of the participants in the workshop to write their objectives for the research on Post-It notes. These can then be de-duped and sorted in order of importance. It’s likely that your project won’t be able to cover all the objectives proposed, so this is a good opportunity for the group to agree on any that are specifically out of scope at this stage. If the same objective is suggested by several people, it’s likely to be an important one.
• Generate hypotheses: Once again, ask the participants to propose their hypotheses, written on Post-It notes. A good way to do this is to read out each of the research objectives and ask people to provide their hypotheses, then stick the Post-It notes around the relevant objective. Sometimes it can be hard for participants to think in terms of hypotheses. If that’s the case, ask them to finish a sentence that starts with ‘I reckon…’ or ‘I believe…’. You can also ask them to say which of their hypotheses are supported by data, by sticking different coloured dots onto the Post-It notes – eg, a black dot for hypotheses that are strongly supported by existing data, an orange dot for those that are somewhat supported by existing data, and a blue dot for those that are pure guesswork at this stage.
• Define resources: To complete the project, you’ll need to marshal your resources with the help of the rest of the team. Ask specifically about:
  • Any sources of potential participants, such as mailing lists.
  • Who will be available to help with the research, as observer or note-taker. You may want to create a RASCI to define roles (see next section).
  • Any existing data sources or reports. Tip: you can refer back to the black and orange dots in the previous exercise to help nudge people to provide this.
  • Something to test: a prototype, concept boards or existing product.
  • Time and budget.
• Define roles: You’ll need to be clear about who’s doing what on the project, to avoid overlap or mistakes. There are two stages to do this:
  • First, create a RASCI. This is a document which captures the people’s different relationships to the project.
    • R stands for Responsible. This is the person charged with leading the project (probably you).
    • A stands for Accountable. This is the stakeholder who will ultimately be judged on the project, and has signed off the budget. This is likely to be the head of your department.
    • S stands for Supporters. These are the other people who’ll support you in getting the job done, for example by taking notes. You should have most, if not all of these people in the workshop with you.
    • C stands for Consulted. These are other stakeholders who will have an important point of view on the project, or who will be affected by its outcomes.
    • I stands for Informed. This is the broader audience for the research. They’re likely to be less engaged than those in the Consulted category.
  • Next, write all the different jobs that will need to be done on Post-It notes. Create several columns – one for yourself, and others for each of the people in the Supporters category of the RASCI. Allocate the jobs under each of these columns until you’re confident that everything is covered. You may find that you add additional supporters as part of this process, if you’ve forgotten someone.
• Define the approach: You’ll probably want to define this in your own time (see Chapter 2), but the team may have some initial preferences or expectations for the approach.
• Define the sample: Again, you will define this more solidly later (see Chapter 3), but at this stage it can be useful to hear the team’s suggestions about the kinds of people you should be approaching to interview.
• Arrange stakeholder interviews: Now is a good time to define the other stakeholders you should be speaking to, and arranging times to interview them.
• Define communications approach: Agree the format, frequency and communications tools you’ll use to catch up and review work.
• Pre-mortem: Now you’ve got a good idea of the project objectives and approach, the team should consider the project risks. We do this using a ‘pre-mortem’ exercise: ask the team to project their thoughts forward to the end of the project, and assume it hasn’t gone well. In this imaginary scenario, what are the elements that went wrong? How could they have been avoided? This is a surprisingly fun activity, and extremely effective at identifying risks.
• Personal objectives: Finally, research projects are also a time for you and your team to learn and grow. Is there a new research technique that you want to try? Or a new piece of software that you and your team want to trial? Challenge yourself to include something new in your plans every time you run a research project.

If you’ve got less time, another way to structure a kickoff workshop is to begin with an empty research canvas document (see below), and fill it in as a team. This works well when you know each other better, or when the project is a continuation of a previous study.

Talk to Your Stakeholders

Stakeholder interviews provide a counterpart to the kickoff workshop. For all of our bigger research projects, we carry out stakeholder interviews.

Stakeholders are the main people who’ll refer to your research to make decisions in the future. They be may responsible for a part of the organisation that your research relates to, or they may have an interest in the results. For example, if you were working on a piece of research for an online shoe retailer, your stakeholders could include the Head of Marketing, Copywriter, User Experience Designer, Lead Developer and Commercial Director.

Stakeholder interviews serve four key purposes:

1. They help you define your research objectives and research hypotheses.
2. They give you a chance to gain a better understanding of the organisation you’re working with, the dynamics of the business, who’s who, and the relationships between them. It’s your way to minimise the impact of any existing politics on your project!
3. They’re a brilliant way of getting lots of people from many different areas of the business on board with your project. Having them onside can be invaluable and insightful.
4. If you’re working for a client, often stakeholders will appreciate having someone outside of the organisation to chat to. It can end up being quite cathartic for them to have someone to vent at!

Who should you include? Obviously this will depend on the time available, and the willingness of participants. However, a good guide is the RASCI. If you completed one in your stakeholder workshop, include the people listed under the Accountable and Consulted categories. It’s a good idea to include a mix of the most senior people who have a relationship to your project, and those ‘on the ground’, who will be asked to implement any changes.

It also pays to be mindful that stakeholders (especially senior ones) are often pushed for time, so can be difficult to pin down. You can increase the chances of them agreeing to chat to you if you keep the following in mind:

• You will need to convince them that meeting with you and giving up some of their day is worth their while. You can do this by briefly explaining your research and how you believe this will help. Try to explain the value of the project in their terms, rather than yours.
• You need to have done your homework and go into the interview with a good understanding of the business, the role of your research and how it can help them.
• You should treat the interview like a meeting, so we recommend sending over an agenda. This gives them a good idea of what to expect, and gives them time to prepare their thoughts.
• It also pays to show your enthusiasm!

Create a Research Canvas

A research canvas is a fantastic way to summarise your project on one page. Put this up on the wall of your project area and you’ll have a succinct view of your entire project. A research canvas summarises your objectives, approach and other key aspects of your plan in a table that’s easy to refer back to throughout the project (see example below).

Some headings may be more relevant than others, so feel free to play with the format and change the section titles until you find a version that’s right for you.

Having a research canvas will help you to:

• Define the objectives of your project.
• Make sure you ask all the questions you need at the beginning of the project.
• Have something to refer back to if you are considering changes to your approach mid-project.
• Help you to onboard new team members.

Your research canvas should be visible. Ideally, it will be printed out and posted in your team’s working area, as the start of a research wall or project space (see Chapter 8).

Project Plan

Running a research project involves co-ordinating a lot of resources and people: participants, stakeholders, note-takers, research facilities and recruiters, among others. Without a project plan, it would be chaos.

A project plan is essentially a timeline, showing what will happen when, and enabling you to make sure you’ve got enough to complete each activity before your deadlines. Once you’ve got a project plan, you can specify when you need particular resources in place – for example, when you need recruitment completed by.

All research projects follow the same basic pattern:

Within that basic framework, though, there’s a lot of variation, depending on your target audience, your methodology, your recruitment method and the scale of your project. It’s a good idea to leave a little bit of wriggle room to allow for unexpected overruns.

Make a Plan to Engage People

We’ve mentioned already that you should plan your research projects for impact, not just to deliver a report. For this to happen, you’ll need to get buy-in and engagement from stakeholders. This is part of a deliberate process we call engagement planning.

1. First, you should be clear about who you need to get buy-in from. If you’ve created a RASCI, this would be the people in your Accountable and Consulted categories. In some cases, the Informed category is important, too.
2. Identify what each of these audiences are interested in. Do they have a business need that relates to your work? Does it have the potential to affect one of their KPIs? What are their overt and covert objectives? If you talk in their terms, they’re more likely to take an interest and act on your findings. You can do this in your kickoff workshop and stakeholder interviews.
3. Identify the key messages you’ll need each audience to take out of the research. For your main project sponsor, it might be: “I understand how best to spend my budget to increase shoe sales.” For the people who’ll put the findings into action, it might be: “I understand what information shoe shoppers need in the checkout process.”
4. Identify the moments at which each audience needs to hear about the project. For senior stakeholders, and those who are less engaged, this might be a handful of times in the process: perhaps an interview at the beginning, an update midway through, and a debrief at the end. For others, you might have a weekly catchup session. Bear in mind when you want decisions to be made: sometimes this will be at the end, but if it’s a fast-moving project, you will want to feed information through earlier.
5. Identify the communication methods that will work best for each audience at each stage. Bear in mind how interested, engaged, and motivated each audience is to hear about the details. For some, it may be best to offer a resource they can dip into, like a project blog or pizza session. For others, they may want a short and punchy format like a 10-minute face-to-face update. Others may be happiest to wait for the full version, in a final debrief session. Best of all, though, is to encourage your audience to attend the research sessions. If you can get them to show up for the first two interviews, they may stay around for the rest, too.

We find it easiest to visualise this as an additional set of swimlanes on your project plan. Once you’ve created your plan, it’s a good idea to sense-check it with your colleagues to ensure it works for them, too. As well as ensuring you’ve got the right approach, this also helps to set expectations and build anticipation.

If you follow this approach, you’ll find you engage your audience and bring them with you on the journey through the project. Ultimately, it’ll mean your results are acted on, which is the whole point of doing research!

What to Watch Out For

When you’re planning engagement, there are a few pitfalls to watch out for:

• Be ruthless. Keep focused on the audiences that matter – ie, the ones you need to act or make decisions. Aim for efficiencies by looking for communication methods that will work for multiple audiences. Don’t hold a feedback session that’s not required. In particular, avoid the temptation to save everything up for a ‘big reveal’ at the end. If you can, engage your audience sooner.
• Move quickly, if you can. Fast findings (even if they’re not perfect) are usually better than polished findings that arrive too late.
• If you want to get your audience involved, showing them is better than telling them. Involving them in the process is best of all.
• To get maximum impact, you should expect to spend as much time communicating the research as you do conducting it. That sounds like a lot of extra work, but in fact you can be efficient by involving your team in activities like note-taking and analysis. Not only will you achieve greater buy-in, you’ve reduced the need for extra debrief sessions or documentation.
• Make sure you know how and when senior stakeholders want to be kept informed. If you’re not careful, you can over-communicate with them, or use the wrong channel, and run the risk of them tuning out. Instead, ask them early on how they’d like to be kept informed: a summary email, three-slide deck or project blog are good methods to suggest.

Tactics for Engagement

To help you make your plan, it’s worth thinking about some of the methods you can use to engage your audience. This isn’t a complete list – use it as a starting point to add your own ideas to:

• Stakeholder interviews (see above)
• Project space (see Chapter 8)
• Show & tell (see Chapter 9)
• Topline findings (see Chapter 9)
• Project blog / website (see Chapter 9)

4. Decide How You Will Communicate With Your Team

Encouraging good communication within the team is key to the smooth running of your research project, and happy colleagues.

We use a number of different communication patterns on our projects:

• Regular stand up meetings. These could be daily or a couple of times per week, and shouldn’t last more than around 15 minutes.
• More in-depth milestone meetings to review documents, make more complex decisions or get signoff from stakeholders. These might last up to an hour, and will be scheduled well in advance as part of the project plan, to ensure everyone can attend.
• Shared documents that the whole team can access. These include the project canvas, project plan, and others we’ve mentioned already, but also the recruitment brief, discussion guide, analysis plan and deliverables. To make them accessible, we use software such as Google Docs and Dropbox.
• Collaboration tools can be incredibly helpful, especially if you’re working with a distributed team. We love Trello, Evernote, Slack and Google Hangouts.
• For some research projects, you may be building a prototype with your project team. Make sure you pick software with a decent sharing feature so that it’s easy for you to share feedback with your colleagues.

When you decide on your approach, it’s worth bearing in mind a few factors:

• Who are the key people you’ll need to contact. What are their communication preferences?
• What software are you able to use? For example, your organisation may have rules that prohibit certain products or limit their effectiveness.
• It’s better to have a flawed tool or meeting setup that’s accessible to everyone, than to have multiple different setups for different people. In the latter scenario, confusion reigns. We’ve experienced projects where the team have attempted to use a mix of Google Hangouts, Skype, Slack, email and conference calls, with the result that messages got lost and key people were excluded from the conversation.

Work Through Risks to the Project

A risk register is a list of the potential pitfalls that might affect your project, and your team’s planned response to them. Normally, you’d produce this in two bursts: firstly as a team, and then adding in detail yourself later.

A risk register has five columns:

• The first column describes the risk – eg, “Prototype isn’t ready in time for testing.”
• The second column rates the probability of this problem occurring, normally on a scale of one to five, where one means very unlikely and five means very likely.
• The third column rates the impact of the problem if it does occur, again on a scale of one to five where one means minimal impact and five means major impact on the business.
• The fourth column is the importance of the risk. You generate this by multiplying the probability and impact columns, to generate a score from 1 to 25.
• The fifth column is response. This is what you plan to do to address the risk. You may choose a plan to mitigate it (such as “Assign additional developers to the prototype team”), or ignore it if the importance score is low.

Risk registers work best in a spreadsheet format. Once you’ve completed your table, it’s a good idea to sort it by the fourth column, so the most important risks are at the top.

Summary

A good research project takes planning, preparation and a considered approach.

• Clearly define your objectives using workshops, briefs, desk research and stakeholder interviews.
• Involve your colleagues in generating hypotheses.
• Include your stakeholders as soon as possible. Be strategic about engaging them through the project.
• Figure out the best ways to keep in touch with your team.
• Minimise the chances of things going wrong during your project by running a pre-mortem and discussing what you think could fail.