Services
Blog

Impact beyond Alpha

When I joined the company last year, I moved from in-house product management at tech start-ups to project-based work for public sector clients. When I was in-house, I was always in a position to drive change – in culture, in business processes, in quality – from within, and on a continual basis. But in this new environment, I saw a challenge:

How can we contribute to the wider cultural environment and learning at the client institution within the confines of a short project?

Enacting our company’s mission – to help institutions embrace the opportunities of the internet era – is challenging during Discoveries and Alphas, which may last 4-8 weeks depending on budget. You build up a pretty broad knowledge of the problem landscape and a deep one of the problem itself. You’ve created relationships with individuals inside and outside the institution who have a vested interest in how the project progresses, and perhaps want to learn more about working in a digital way. You’ve opened lines of communication and piqued people’s interest.

And then you leave. There might not be another contract team picking up the next phase for weeks, or months. And your main point of contact might move department, or move on. So how can we be confident that the work we’ve done is used, and of use?

I’d love to hear how other professional services suppliers address this, and what people on the client side have seen work – here’s what I believe to be helpful from my experience thus far.

When you’re there

On my most recent project we had the absolute luxury of a user researcher from the client side who was fully embedded in our team. Having her on board was a win-win – she got more hands-on experience and we got her background knowledge. I’m confident that on our departure she’ll be an invaluable provider of insights to the wider team, and be able to help future suppliers hit the ground running with what she’s picked up.

At the Food Standards Agency (FSA), we’ve been carrying out several discovery projects simultaneously with different Notbinary teams. This has created an added advantage of internal information sharing – each week we have a “Scrum of Scrums”, intended not for project updates but for identifying shared cultural or process challenges and offering support. The client has a digital presence at these sessions, creating a collaborative culture of improvement. They’ve also invited us along to their team’s away days, giving us the opportunity to help shape the team’s culture and priorities.


We’re actively engaging with the suppliers of the next development phase. We’re lucky in that Deeson, who are a sister company in our group The Panoply, provide the website support for the FSA, so we have a natural channel of communication. But even where projects are, perhaps, tangential, we aim to foster those inter-supplier relationships. At BEIS, for example, a parallel project has some crossover in the relevant people for user research. We’ve been in a position to learn from them about user recruitment tips and to offer feedback on the clarity of their documentation.

I’d like to do more of this. It seems that in many institutions there is a whole host of research, resources and cheat sheets that should be made available to incoming suppliers to accelerate their landing. We’ve recreated things – from user studies to department maps to content reviews – that almost certainly exist in the depths of filing systems. While I appreciate there’ll be some anonymity and data sharing restrictions, it seems a wiki of what exists might be a starting place so that people can ask for it. It would save clients time in asking around for documents, and enable us as suppliers to contribute to the overall canon of work at the institution.

What you leave behind

As with developers who criticise previous devs’ carelessness in code, so I’m sure we are hypercritical of the research work we inherit. This is something worth bearing in mind when we round off a project – our work is likely to be read or watched by other people, weeks or months in the future, who have never met us or had any interaction with this project. If we want our work to stand that test and continue to be of use, we need to document and present it accordingly. It is not, then, enough to write it down clearly. We also need to explain how to read it, who it might be useful for and why, and state its limitations. We should specify what sources we drew on and how we accessed those. If possible, including a contact sheet with “who to talk to about…” is of great use. Basically, we should be spending time on the documentation, even where it feels like the client is super clear on the next steps.

We also encourage client product owners we work with to brief colleagues who are taking on the role about what to expect and what surprised them about the ways of working. While we always onboard and support our product owners, we’re less likely to know what normal looks like in their working lives, and therefore which elements of our approach might jar. It creates some peer-to-peer coaching and allows us to start a few paces forward with each new project.

The other thing I’d like to focus more on is how to ensure the client is actively participating in agile prioritisation and decision making. Not observing, or feeding back on, but doing; running stand ups, facilitating retrospectives, specifying sprint goals. Digital can still feel ‘other’, and therefore daunting, to policy makers in particular. As we know, learning through doing is effective, and builds confidence for continuing the work and the approach on our departure. But it is a challenge to balance this with the understanding that we’ve been brought in because the client doesn’t have the capacity to fully own the project, so we can’t always get them in the room when those decisions need to be made.

Many speak of a shared ownership of projects with the client but I’m curious as to how often this is fully played out. In my experience, there’s a chasm between digital team members – who are comfortable with the process but don’t have as strong a voice on the final result – and policy team members, who are the reverse. While as far as possible we aim to be an extension of the digital team, our ability to close that gap is limited.

The onus, then, has to be on the client to bridge supplier-led projects like ours – stopping suppliers repeating work that’s already been completed, applying the learnings to other ongoing projects, and nurturing changes in ways of working. Ultimately, this is the best way to be sure that bringing in suppliers for short projects is cost-efficient and, importantly, furthers the institution’s progress to embrace the opportunities of the internet era.