How to start a project well
And how to know if it’s worked
Starting a project well
At the beginning of a new project, we like to start with a short inception phase. In practice, this is a series of short facilitated workshops that have specific outcomes in mind. This post explains what these outcomes are, why we think they are important and how we go about achieving them.
Agreeing who is in the team
Most of our projects involve us working in multi-disciplinary teams with our clients. At the beginning of a project, we start by agreeing who is in the team and what their capacity looks like. Emily Webber’s Team Onion is a great resource for figuring this out and documenting the agreement we make.
Creating alignment on purpose
We help public services to solve messy problems. Messy problems are complex. They aren’t fully understood and there are no ‘here’s one I made earlier’ solutions.
Because there is no linear path to solving the problem it’s not always obvious what work needs to be done and in what order. To figure this out teams first need to understand why the work is happening and the outcome it’s trying to achieve.
When teams are clear on their purpose they can experiment, observe what moves them closer to the end goal (and what doesn’t) and use this feedback to prioritise what comes next. When there is misalignment on purpose, things can go wonky very quickly.
At the beginning of a project, we often like to hold a User Experience Fishbowl with the person who is ultimately responsible for the work. Through a casual conversation we create the opportunity for them to share in their own words why the work is happening, the outcome it’s trying to achieve and why they care about it. Most public sector projects have both a policy and strategic context. This conversation enables us to unpick this information and figure out the boundaries of the work.
Unlike a presentation, the fishbowl structure creates the opportunity for team members to clarify their assumptions as part of the process. Working with the team we then write up a challenge statement for the project. This acts as a north star that guides the work.
Building psychological safety
When problems are messy it’s normal for people to have different assumptions about why the work is happening. But it’s not always easy to surface this information at the beginning of a project. Many of our projects bring together people from different service areas. Our inception workshops will likely be the first time they’ve met us. They might also be the first time they’ve met one another.
For people to share openly, they need to feel psychologically safe. They need to feel a sense of confidence that others will not embarrass, reject or punish them for speaking up if they have a different understanding or hold a different set of assumptions.
As part of each workshop, we hold during the inception phase actively try and create psychological safety. For this to be built, team members often need to share something of themselves. This can include:
- Information related to the work: what are their hopes and fears for the work, or who they are most looking forward to learning from
- Information about their life outside of work: their hobbies, interests and passions or exciting family plans for the year ahead
- Silly stuff: their chosen superpowers or ridiculous pieces of advice they’ve collected from family members
One of the ways we encourage people to share is through the use of check-in questions. We participate, model vulnerability, and share as much of ourselves as we can. Over time, this process creates an environment where people can speak up when they hold different assumptions or need to share things they are worried about. It also makes work more human and fun.
Understand what has already happened
During the inception, we also need to figure out what work has happened to date. During the initial workshops, we ask our client team to share any documents or artifacts that already exist. We need to create time at the beginning of a project to digest this information and ensure we don’t duplicate effort at a later date.
More than likely, there will be several internal folks who know a lot about the work and who are not involved in the inception process. If possible it’s a good idea to meet up with them over a coffee to pick their brains to help gather the full picture.
Figure out what might go wrong with a Premortem
Depending on what source of information you use, between 50–70% of projects fail. Research conducted by colleagues from the Universities of Cornell and Colorado found that “prospective hindsight — imagining that an event has already occurred — increases the ability to correctly identify reasons for future outcomes by 30%”. One approach my pal Gwenno Edwards likes to use to take advantage of this learning is a premortem. A the beginning of a project, team members imagine that the project they are about to get started on has failed. They then generate reasons why this might have happened and figure out ways of correcting for them ahead of time — avoiding a future autopsy.
Agree our working rhythm and how we’ll communicate
Where possible we like to work in fortnightly sprints. The important thing to figure out at the outset of the project is on which days we’ll hold specific ceremonies, who we’ll invite to them and how frequently we’ll hold team stand-ups. This isn’t rocket science, and there are lots of potential options for how this can work, but getting dates in the diary early is essential in ensuring people can attend.
We also like to ‘work in the open’ sharing our progress transparently throughout the project. This could take the form of recording and sharing our show and tell sessions or writing weeknotes. We’ll figure this out as part of agreeing our working rhythm and it will save an enormous amount of time in communicating with stakeholders.
We also need to figure out how we are going to communicate with one another. To ensure we make quick progress we need to reduce the amount of time we spend in unnecessary meetings and create time for everyone to do focused, deep work. Setting up a Slack channel to communicate asynchronously a really effective way of enabling people to give and get help quickly. Where possible we do this on every project.
Developing a roadmap
Having figured all of this stuff out we should be in good shape to turn our attention to the work we’re going to do to address the challenge.
It’s tempting at this point to jump straight into sprint planning. However, most projects we work on will have some definite time constraints (e.g. we need to prioritise which problem we’re going to fix by x date or we need a prototype of this service live before y date).
These constraints can be helpful. To figure out how we are going to work within them we often like to run a roadmapping workshop. Roadmaps help to communicate at a high-level what chunks of work (and the outcomes they aim to achieve) will be delivered, and in which order.
We like to prioritise our roadmaps into three categories:
- Now, the first outcomes we’ll work towards and all the things we’ll need to do for those
- Next, the outcomes we’ll work on once we’ve completed the first things
- Later, everything else
To help ground the discussion, you can give a timeframe to the Now and Next. This might be quarters for a bigger piece of work or single sprints for a smaller project. It might be that you don’t actually know exactly when these milestones are. Don’t worry too much, humans are notoriously bad at making predictions, they’ll probably turn out to be not quite right anyway. However, a guess based on the information available at that point is a really useful starting point.
The work that falls into ‘Now’ should prioritise learning, reducing dependencies or clarifying our riskiest of assumptions. During our first sprint planning session, we’ll start to break this work down into much smaller chunks of work.
So how do you know this stuff has worked
If you’ve gone to the trouble of doing all of this work you’d hope the project has got off to a good start. But how do you know? For me, there are a few clear signs.
- It’s easy to ask people for help when you need it
- The work is distributed appropriately — the pace feels sustainable and no one person carries the load
- Everyone has a voice in shaping what comes next
- Time isn’t wasted in unnecessary meetings — when the team comes together it feels useful
- Team members assume positive intent — when things go wrong responsibility is shared and people don’t point fingers at individuals
- People don’t complain frequently or waste too much time worrying about circumstances beyond their control
- Stakeholders know what progress is being made and don’t need to ask for frequent status reports
- Team members develop meaningful relationships over time and the work feels fun
This list isn’t exhaustive, but if most of these things are happening — my guess is that the project is in good shape.
In writing this post I build on some ideas from Kath Cooper at the wonderful DXW. Go check her post out too.
