How to manage the initiation phase of a new digital project
Awdur: Bex Rae;
Amser Darllen: 10 munud
Mae hwn yn adnodd agored. Mae croeso i chi ei gopïo a'i addasu. Darllenwch y telerau.
We recently kicked off a new project, working alongside Catalyst, to create the second version of a classification system for the charity sector.
Yep, that’s a big sentence. There’s a lot to unpack there.
The project itself is fascinating, the scope is challenging, and the various stakeholders, previous work completed and partners make it a complex piece of work. That’s exactly why this project has meant that we’ve been reflecting on one of the most important, and often overlooked, phases of a project. The Project Initiation phase.
At Reply, we’re continuously iterating on how we run projects, there are always new things to learn and new ways to improve and I’ve always been quite interested in how we deal with this first phase. In my experience, it can make or break a project, especially a complicated one with many moving parts like this one.
If you are interested in the specifics of the classification project you can read all about it in this document. But for now, let’s look at Project Initiation in relation to this project.
Some elements of a project are more likely to be well-funded than others. Project initiation, project management and project wrap-up are particularly vulnerable to underscoping and underfunding.
When it comes to cutting down a budget, CEOs and product owners rarely take the knife straight to development. They know they want to build a thing. If they don’t build it, they won’t come. That’s right, I’m quoting Field of Dreams.
Next up, design. Again, there’ll be some hesitation before they slash straight into this because they know developers need the designs to work from. Yep. I’m a designer too. I know that this sometimes gets cut as well.
Research is comparatively more vulnerable. Back in the day, before I founded Reply, I used to run research teams at different agencies, and the challenge used to be that the first thing the client, and the new business team, and the CEO wanted to cut was the research phase – I feel like I’ve died a thousand deaths on this hill. Fellow researchers in agencies, assemble!
But even research is a walk in the park compared to project initiation. Project Initiation, Project Management and Project Wrap-up: Is it possible to imagine more undervalued – and more underscoped – phases of a project? It makes those research battles look like a walk in the park. Or a walk in the field (of dreams).
So what are the key elements that go into a project initiation phase? Let’s look at them one by one:
Understanding stakeholders and responsibilities
We need to understand who is responsible for what. It ensures we’re working well together. If I had a nickel for every project catastrophe I’ve witnessed over the years that could have been avoided with a map of who was supposed to do what, then I’d… well… I guess I don’t know how much I’d have, because I don’t know how much a nickel is worth. But I’d have a lot of nickels, that’s for sure.
Looking at the example of our project for Catalyst, you can see there are many stakeholders. For starters, we have the Reply team, and we have the partners that we’re working with. We have Catalyst. There are two other teams running separate projects that will join up with ours at Charity Digital and Third Sector Lab. There’s the folks who ran previous phases of work on this project (FutureGov and Snook), AND then there’s the charities we’re engaging with throughout.
We used the RACI Matrix as a template for mapping this on this project. You map who is Responsible, Accountable, Consulted and Informed for each project task. Read more about how to implement this over on the Reply blog.
Getting to know each other and ways of working
Of course understanding the specifics of responsibilities is one thing, but it’s also worth remembering that we’re all humans. A project might consist of people who know each other, people who don’t, people who get on, people who don’t. People who work part time, full time, remotely. Some might have caring responsibilities, some might have accessibility needs. The more we can get to know each other and our needs and motivations and be understanding of this, the better. I know how this sounds, and as someone who’s maybe slightly awkward around people, this sort of thing doesn’t always come easy to me, but understanding these things can work wonders.
None of this is new either, there has been plenty written about group dynamics and facilitation. A good starting place is The forming–storming–norming–performing model. There’s also Radical Honesty and Non-violent communication as communication methods. Liberating Structures is a good tool for facilitating conversations.
This one’s more challenging than some of the others; there isn’t a template we can use and it often needs personal reflection, or an internal culture project and can be difficult to transfer across organisational teams, especially if there are currently very different cultures and ways of working. The more you can facilitate discussions to openly and collaboratively decide on ways of working together, the better the project will be. Think about working on project values together. Think about what power you hold in the project, think about what assumptions and biases you bring to it.
In the classification project, Catalyst has been directive about some behaviours, due to their own values, such as working in the open. In this instance, there were no push backs, all partners have similar values and have worked with Catalyst before, so we know the drill. And of course, there’s a pandemic happening, so we all have to be more considerate of other people’s needs and working patterns.
Rhythm and rituals
For a better outcome, as much as you can, you should really see a project team as one team working towards a shared goal, rather than client/supplier relationship. The partner who has the most power needs to be the one to concede to this way of working.
But how will we work as a one-team? How does our sprint-based research and service design process work? When will we do stand-ups, and how will these be run? What about show & tells and weeknotes? How do we ensure that we’re bringing everyone along with us?
We’re doing a weekly stand-up with all partners on this project and then focussed work and open Show & Tells. Again, due to us all working together in different ways previously, we are all on board with these ways of working.
File and folder management
We need to review where and how we’re going to store documentation throughout the project. Sometimes this is easy. We hit gold on this particular project because despite all of the many partners, we all happen to use the same platforms! (Namely Airtable for storing data, Slack for day to day comms, Miro for visual synthesis, and Google Drive for storing documentation) This leads into our research ops work, where it’s vital that we’re recording and storing data in an ethical and GDPR compliant way. We often use risk assessments called an lIA and a DPIA to work out GDPR compliance (Not to be confused with the DIPA beer!) This will lead into deciding what platforms we use to store data and deliver the project – but we weren’t storing any complex data on this project or working with any particularly vulnerable groups so we skipped it this time. If none of that means anything to you and someone else deals with your GDPR, then feel free to forget I ever said anything. But if you are the person who needs to think about data and where it’s stored, read more here on the ICO website.
Risks
We sometimes keep a risk register. Just a list of key things that may impact our work and how we can mitigate them. It’s a really helpful way to have conversations together about the difficult parts of the project.
Onboarding to work so far
We’ll often undertake some preliminary desk research during the Project Initiation phase and we’ll make sure we’re up to speed with where the current project is. This was particularly challenging with this project. There was already a version 1 of the classification system, built by two partners with a lot of knowledge in this area. We had to understand what design decisions had been made so far and how, and why. This takes longer than you think. We had meetings with the previous partners, searched for access to Miro boards and we read a bunch of interviews and documents and spent time really understanding it all. Although this took a while, it was worth it. If we hadn’t have done this we might have recovered old ground, misunderstood decisions and gone down the wrong path for a while. Which would have cost more time in the long run.
Measuring success
A good way to avoid catastrophe is to understand what success might look like. We like to create a measurement plan or define a set of KPIs at the beginning of a project. It brings the entire team together to understand the common goals and vision for the project. It helps avoid scope creep down the line. If the project is large in scope, like this project KPIs become an important part of setting direction. It helps open the door to conversations about the wide organisational goals and context. But most of all, it helps us know if we’re actually making an impact.
If your case studies are filled with content about what you did, and what you made, and how you did it, but don’t ever talk about whether it worked, and what the impact was… well… you should really look into that. If you’re a charity and you’re hiring a design agency and they’re not talking about how they’re going to measure the success of the project… well, here’s a big red flag you can borrow.
This sounds like a lot and can sometimes feel like a barrier to just getting started on the exciting project you have ahead… but believe it or not you can get most of this covered in a good old well planned kick off session. Some people might think about this stage being somewhat dull and unfortunately some people can really make it dull. But it doesn’t need to be, or rather, it shouldn’t be. We run a whole heap of interactive and collaborative sessions during this phase. It’s a great way to get the client and your team excited about the project ahead, and to start bringing you all together as a single team.
This then leads into ongoing Project Management and finishes with your all important Project Wrap up. More on those soon.
Photo by Danielle MacInnes on Unsplash
Wedi'i gomisiynu gan Catalyst
