~ Weeknotes ~ 

24 May 2021

Wearing multiple hats

This week I found myself doing something I said I wanted to avoid, which was 'wearing a different hat'.

I'm trying to guard against becoming a multidisciplinary individual within an already busy multidisciplinary team because in my experience it nearly always sets an unsustainable expectation.

Don't get me wrong. I really enjoy it, who doesn't like variety and continually learning or honing different skills? But there is a reason we split design work into different disciplines.

At the start it can be exciting and fun but soon the regular context switching and multiple lines of communication will mean that you, your work and your team will suffer as you slowly but surely burn out.

In a previous role somebody described me using the words of Bilbo Baggins, you're 'Like butter spread over too much bread'.

However putting all that aside. I love being using my experience and this time it was 'needs must', so I picked up my service design hat and attempted to brush some of the rust off it.

The reason I needed to step in was due to our current service designer leaving for their next contract.

I took it as a compliment when they nominated me to pick up the design and facilitation of a remote kick-off workshop between Policy colleagues, my team and planning experts from various of Local Authorities.

Things were in flux so I couldn't do anything too specific, so what did I do?

A "Project point of departure"

Working at pace with input from various people who all want to get something out of it can be daunting especially if you're new like I am.

So I fell back on a simple but effective format for a 'kick off' workshop, it's probably known by multiple names but the one which has stuck in my head is a 'Project point of departure' exercise.

What is a project point of departure?

A Project Point of Departure (PPOD) is a way for individuals and teams to define the structure, direction and first steps of a project. The individual or team works through a set of questions and documents the answers in a shareable document.

This can either be a document that develops with the project, or it can be left as just a clear and concise record of the starting-point.

Mine was a variation on the following standard questions:

1. What is the overall purpose of the project? (express this in one sentence)
2. What specific outcomes should be achieved by the end of the project? (aim for 2-4 bullets)
3. Who are you doing the project for? And what value does it provide to those people? (aim for 3 bullets or less)
4. Who is involved and what are they responsible for?
5. What needs to happen by when? And how much money do you have? (broken down into bullet points, on a broad level)
6. How will the team work together, how will you communicate, divide tasks, collaborate, approach decision making, etc. (try to define about 5 guidelines with short descriptions for each)
7. What does success look like? What does failure look like? (aim for 4-5 bullet point for each one)
8. What projects are connected to this one? Are there any other documents or data sources that we need to take into account? (list the connections with hyperlinks to key documents)

In my part of the MHCLG we have access to an online collaboration tool called 'Mural', I used that as the place to capture contributions from the local authorities which obviously were based all across the country.

After some hiccups with people getting access to the board. It worked quite well. I used the lovely timer facility to keep things on track which helped a lot when trying balance between giving people thinking time as well as contribution time.

Other happenings

• I have been asked to sit on a panel reviewing applications for a design brief our team has put on the Government digital market place.
• I have started thinking about how I might influence the design and build of digital maps.