I’m writing this post to help develop my own thinking.
Whilst there are lots of brilliant examples of user centred service design elsewhere, they’re often based in much larger organisations. That poses a bit of a challenge in terms of scaling the approach down whilst not losing any of the fundamentals.
So, here’s a hypothetical example to help me write down what’s in my head and hopefully expose any gaps in my understanding (..and then fill them!). Consider this the crappy first draft.
Thoughts/input/comments most welcome and appreciated, either here or via Twitter.
Context
The organisation has around 250 staff and has been operating in it’s current form for around 15 years. It is used to delivering change in the framing of teams and waterfall projects. Working continuously and iteratively on end to end services represents a departure from the norm.
For the purpose of this hypothetical excercise, let’s say we have identified an initial service area for improvement. We have some assumptions about where we might focus attention first based on pinch points.
Almost all of the tech utilised within the service are customised off the shelf products. There are some integrations in place, but there’s room for improvement.
The intention is to build a team to focus on this service area and continuously improve it using lean and agile methods. We would like the improvements to primarily deliver value for the people that use the service and for those that provide the service (our colleagues).
The skills we think we need
- Technical / System configuration – to carry out any IT system change required to support new or redesigned service improvements.
- Business Analyst – to define and map business processes/logic, analyse risk and keep track of budget vs proposed changes.
- Service designer – to help reframe service delivery as an end to end journey that may touch upon multiple points within the organisation. This is to ensure the experience of using the service is seamless regardless of how the organisation is internally structured.
- User researcher – to talk to people that use the service, or work within it, to better understand people’s needs and help the team design with them in the forfront of their mind.
- Project manager – to help orchestrate the work and ensure the right people and resources are available at the right times.
- Delivery manager — to help the team work autonomously, cohesively and remove any blockers that may stop them from achieving their intended goals.
- Product manager – to work with the team and the service owner to help define the direction of the service, ensure it fits with the organisations priorities and meets people’s needs.
- Service owner — has decision making authority and overall responsibility for the service and its continuous improvement.
One noteable exception here is a some sort of user experience / interaction type role. In this particular hypothetical example, lots of the immediate challenges might be described as ‘fixing the plumbing’, so I’m thinking that perhaps this role could come a little later once we’ve matured a bit. Happy to be challenged on this though!
The Team
Because we’re looking for the minimum viable team, one person may operate in one or more of the above roles where it makes sense and doesn’t inherently cause a conflict.
In my head, that looks a bit like this (although will obviously vary depending on the people in the team and the skills they bring with them).
- Service designer / user researcher
- Business analyst / Technical system configuration
- Project manager
- Product manager / delivery manager
- Service owner
This might be considered the core team — although I wonder whether some roles could be shared across other services if they’re not in utilisation 100% of the time (project manager for example?).
Approach
The team will work in short, fortnightly time boxed units of work. This is to ensure that they regularly deliver value to the service and avoid getting stuck with large blocks of work in progress where value is withheld. It also enables the team to shift priorities as understanding deepens and to respond to changing internal/external conditions.
The team will conduct bi-weekly show & tells to communicate what they’ve done, what they’ve learned and what they’re doing next. The team will also use mobile pop-up boards to illustrate what they’re working on and how they’re meeting the needs of people who interact with the service.
Governance
The team would report back via existing governance mechanisms (for example, programme board meetings). They might use a variation of the form below (from this excellent post: https://medium.com/@kyliehavelock/what-does-good-product-governance-look-like-d076df8007b3) to illustrate what the outcomes are and whether they’re being met.
That’s it, for the moment. This feels incomplete, but I’m publishing it to avoid procrastination and keep things moving. 🙂