We recently kicked off a new project, working alongside Catalyst, to create the second version of a classification system for the charity sector. <\/p>\n
Yep, that\u2019s a big sentence. There\u2019s a lot to unpack there.<\/p>\n
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\u2019s exactly why this project has meant that we\u2019ve been reflecting on one of the most important, and often overlooked, phases of a project. The Project Initiation phase. <\/p>\n
At Reply, we\u2019re continuously iterating on how we run projects, there are always new things to learn and new ways to improve and I\u2019ve 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. <\/p>\n
If you are interested in the specifics of the classification project you can read all about it in this document.<\/a> But for now, let\u2019s look at Project Initiation in relation to this project.<\/p>\n 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.<\/p>\n 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\u2019t build it, they won\u2019t come. That\u2019s right, I\u2019m quoting Field of Dreams<\/em>. <\/p>\n Next up, design. Again, there\u2019ll be some hesitation before they slash straight into this because they know developers need the designs to work from. Yep. I\u2019m a designer too. I know that this sometimes gets cut as well.<\/p>\n 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 \u2013 I feel like I’ve died a thousand deaths on this hill. Fellow researchers in agencies, assemble!<\/p>\n 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 \u2013 and more underscoped \u2013 phases of a project? It makes those research battles look like a walk in the park. Or a walk in the field (of dreams).<\/p>\n So what are the key elements that go into a project initiation phase? Let’s look at them one by one:<\/p>\n We need to understand who is responsible for what. It ensures we\u2019re working well together. If I had a nickel for every project catastrophe I\u2019ve witnessed over the years that could have been avoided with a map of who was supposed to do what, then I\u2019d\u2026 well\u2026 I guess I don\u2019t know how much I\u2019d have, because I don\u2019t know how much a nickel is worth. But I\u2019d have a lot of nickels, that\u2019s for sure. <\/p>\n 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\u2019re 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\u2019s the folks who ran previous phases of work on this project (FutureGov and Snook), AND then there\u2019s the charities we\u2019re engaging with throughout. <\/p>\n 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<\/a>.<\/p>\n Of course understanding the specifics of responsibilities is one thing, but it\u2019s also worth remembering that we\u2019re all humans. A project might consist of people who know each other, people who don\u2019t, people who get on, people who don\u2019t. 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\u2019s maybe slightly awkward around people, this sort of thing doesn\u2019t always come easy to me, but understanding these things can work wonders. <\/p>\n None of this is new either, there has been plenty written about group dynamics and facilitation. A good starting place is The forming\u2013storming\u2013norming\u2013performing model<\/a>. There\u2019s also Radical Honesty <\/a>and Non-violent communication<\/a> as communication methods. Liberating Structures<\/a> is a good tool for facilitating conversations. <\/p>\n This one\u2019s more challenging than some of the others; there isn\u2019t 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. <\/p>\n 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\u2019s a pandemic happening, so we all have to be more considerate of other people\u2019s needs and working patterns. <\/p>\n 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. <\/p>\n But how<\/em> 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\u2019re bringing everyone along with us?<\/p>\n We\u2019re 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. <\/p>\n We need to review where and how we\u2019re 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\u2019s vital that we\u2019re recording and storing data in an ethical and GDPR compliant<\/strong> 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\u2019t 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\u2019s stored, read more here on the ICO website.<\/a><\/p>\n We sometimes keep a risk register. Just a list of key things that may impact our work and how we can mitigate them. It\u2019s a really helpful way to have conversations together about the difficult parts of the project. <\/p>\n We\u2019ll often undertake some preliminary desk research during the Project Initiation phase and we\u2019ll make sure we\u2019re 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\u2019t 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.<\/p>\n 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\u2019re actually making an impact. <\/p>\n If your case studies are filled with content about what you did, and what you made, and how you did it, but don\u2019t ever talk about whether it worked, and what the impact was\u2026 well\u2026 you should really look into that. If you\u2019re a charity and you\u2019re hiring a design agency and they\u2019re not talking about how they\u2019re going to measure the success of the project\u2026 well, here\u2019s a big red flag you can borrow. <\/p>\nUnderstanding stakeholders and responsibilities<\/strong><\/h2>\n
Getting to know each other and ways of working<\/strong><\/h2>\n
Rhythm and rituals <\/strong><\/h2>\n
File and folder management<\/strong> <\/h2>\n
Risks <\/strong><\/h2>\n
Onboarding to work so far<\/strong><\/h2>\n
Measuring success<\/strong><\/h2>\n