dxw works with organisations to help solve complex problems for their users. We often start projects where we’re faced with a new problem space and where our clients have the most domain knowledge. This means our clients are, and should be, directly involved in our work, both throughout a project and in setting it up for success.

Start with an inception

When we start a new project, whether it’s in discovery, alpha or beta, we’ll run an inception. Inception helps teams to build context of the problem space and gain an understanding of the environment they’re operating in. Investing time up front during inception to build clarity for teams is valuable throughout a project.

It’s essential that the project lead gets a head start, so they can shape the activities a team will do during inception and think how best to use the team’s time and effort.

This blog post will talk about some of the activities we run during an inception, so others can try them out. We often tailor our activities to the phase of work and how fully formed the thinking is.

Run a kick-off workshop

It sounds fairly simple. But, during inception, a kick-off workshop should focus on building clarity and a shared understanding as a team. A kick-off meeting is often the first time a newly formed team comes together. All team members should be there and a facilitator should create the time for project stakeholders to explain why this work has been commissioned and what outcomes the project is looking to deliver. As well as an opportunity for the team to ask questions.

I usually ask someone from our client team to create a short summary of the intent of the work. This can be as detailed or as brief as it needs to be. It will be different depending on what phase of the project you’re in or how formed the current thinking is. The purpose of this session is to support a team in orienting themselves, learn why the work has been commissioned, and hear the perspectives of the people who know the most.

Narrowing down the format of how a stakeholder delivers the message allows us to be more concise and include only the most important information. You’ll need to make time for them to create this summary. Some questions that might be useful to think through are:

  • Why are we doing this work?
  • What problem are we looking to solve?
  • Who will benefit from achieving these outcomes?
  • Any context and insights into the organisation

It’s important to remember that it’s okay if this isn’t perfect. The value is that a team can hold this in their heads throughout the session and ask questions as they learn more. It should be used to tease out thinking and at this stage, we really just need to be able to summarise the why behind the work.

Understand what’s already known through desk research

Inception is a really good opportunity to make sure we understand what’s already known, so we’re learning new things as a project progresses and can avoid duplicating effort.

This might be reviewing artefacts that have been created. For example, you need to give a team the opportunity to digest any reports from a previous delivery phase.

It’s a good idea to get your hands on as much information as you can find. We ask our client team to share anything that could be helpful. This might include access to an existing test environment, process maps, user research reports, and so on.

Asking people who know about the work to share that is often a useful way for the team to absorb the context. This might be a show and tell of what we know about our users, their needs, and the known pain points, or a demo of an existing application.

Working within the public sector, it’s also important to understand the policy intent or strategy the work sits under, and any regulations or standards that you might need to consider.

As a project lead, you’ll need to build time in for a team to analyse these artefacts and existing knowledge. In the early stages of a new project, you’ll also need to rely on existing team members or stakeholders to share information with you.

Roadmap to build clarity

One of the activities we run during an inception is a roadmapping workshop. dxw have 2 approaches to roadmapping that we’ve written about in our playbook:

In the early phases of a project, building clarity is an important step to help teams build momentum. Roadmapping workshops can really help with this.

We think that a good roadmap:

  • sets the direction a team is heading in
  • outlines the benefits and outcomes that’ll be delivered, whether that’s for users or for the business
  • helps teams to measure their progress
  • allows teams to build certainty over time

Roadmaps should be understood by everyone who’ll use them. While the output of a roadmapping workshop is valuable, the act of roadmapping itself and the conversation it generates is where the real value is. It allows teams to build a shared understanding of the outcome they’ll deliver.

There’s some effort required before you begin a roadmapping workshop, in terms of making sure the right people are involved and that you’re asking the right questions. You’ll also need to capture follow up actions to make sure the conversation generated can be practically applied to what comes next. Any member of a new delivery team can and should be able to facilitate the session.

Describe the outcomes you want to deliver

Depending on the stage of the project you’re in, by the end of inception, we should be able to articulate what outcomes we expect to deliver. These might be immediate outcomes at the end of a project or longer term objectives that could be delivered over a period of years. It’s up to the team how these are framed.

Define your delivery approach

Based on what you learn during inception, it’s important to think about how you will structure the project. Think about the delivery approach you’ll take based on the types of activities the team will be doing:

  • Research sprints will help you to learn a lot about users in a short space of time
  • Design sprints, when timeboxed, are useful ways to rapidly tease out the value in a potential solution or proposition
  • Longer development sprints allow you to focus on what you can ship within a set scope and focus on delivering the most important things first, releasing value early to users

You’ll need to adapt your approach depending on your delivery phase. It’s important to consider this at an early stage and reflect on this as a project evolves. Not everything will fit within a fortnightly sprint cycle and that’s okay.

You’ll want a high level plan from the inception that includes the outcomes you’ll deliver and the approach you’ll take to get there. The whole team should input to this, and it will help the team have autonomy in the work.

Share this plan with the organisation and stakeholders you’re working with to confirm your shared understanding of what you hope to achieve. Getting feedback is an essential step to know if you’re heading in the right direction as a team.

Write down the things you’re worried about early on

Most project plans will talk about risk. But early on in a project, I prefer to get the team to think about things we’re worried about. Not everything will be a risk to project delivery, but there might be things that we’re anxious about, or things that worry us, that we need to be aware of.

Last year, dxw partnered with the team at Paper. The UX Designer from Paper, Urska Ticar, facilitated a session for the delivery team based on the workshop “Stinky Fish” from Hyper Island’s Toolbox. The workshop is a short activity to run early in a project to share concerns. The aim is to create openness and “clear the air” within a group. Stinky fish is a metaphor for “that thing that you carry around but don’t like to talk about – but the longer you hide it, the stinkier it gets.”

I found this a really helpful exercise for a new team. You can learn a lot from a team and what they’re thinking about, and it helps project leads to identify risks and issues early on.

The activities I’ve shared in this blog post are workshops that I’ve run frequently in the past that have had a positive impact on setting projects up for success. They help to create clarity in the work you’re there to deliver, and build a good environment for teams to empathise with each other and learn how they’ll work together.

The post How to set projects up for success appeared first on dxw.

Original source – dxw

Comments closed