In the Digital Technology and Strategy team, we routinely team up with policy professionals to work on digital projects. Coming from different backgrounds and with different approaches, it is important to decide how the collaboration will work before starting work.

We’ve also approached this challenge by creating a ‘ways of working’ agreement. The purpose is to set expectations on how the project will run and what people’s contributions will be.

Below is an outline of the agreement we are going to test with some upcoming projects.

Request

What is the ask? This might be around defining the problem, bringing in a supplier, engaging in digital conversations, sitting on working groups, organising assessments or leading workshops.

Policy area summary

A brief description of the policy area and the problem the policy is trying to solve. This should include information about ministerial steers, noteworthy articles and important statistics.

Who are your users?

Who is affected by the policy? This can include members of the public, ALBs and the department itself. This should be as granular as possible.

Expected duration of work

This should be a fixed time period or specific to a particular output to be achieved. It can be according to quarters too.

Team

Who will be working on this project and what skills do they bring? We believe that the following roles are compulsory when embarking on a project:

  • policy lead: expected to own work and provide policy expertise
  • service manager: expected to have ultimate decision-making authority. This role is expected to come from the policy area
  • product manager: makes sure the work meets user needs
  • delivery manager: expected to help the team organise the digital project
  • user researcher: expected to help build an understanding of the users affected by the policy area

Optional: technical architect, developer and service designer.

Scope of work and ways of working

As digital professionals, we would aim to transfer agile ways of working and user research and service design techniques to the policy team. We would expect the policy team to attend user research sessions too.

Likewise, we would expect the policy team to organise a skills-share session with digital professionals to explain the current policy landscape.

Outputs

What will be produced because of this work? This could be: definition of the problem, KPIs, service maps, list of prioritised user needs, user journeys, a supplier brought in, an understanding of the technical landscape,  deciding whether something needs to be built or procured, deciding whether the project should be killed, and so on.

Or it can be specific to the phase of the project as well, for example discovery, alpha, beta and live.

What is the policy area’s measure of success?

This may be focused towards a particular outcome or may be a definition of what good looks like. You can frame this as SMART objectives (specific, measurable, achievable, realistic and timely).

What if things don’t go as planned?

What is the mechanism in place to resolve issues or review terms of the agreement? We use retrospectives to reflect on what’s been working well, what hasn’t been working well and what we could do better in the next fortnight.

If issues can’t be resolved in the retrospective, then a conversation between senior leaders takes place.

Conclusion

The ways of working agreement should be developed collaboratively with the policy team. The aim of the agreement is ultimately to help policy and digital professionals become one team.

Further reading

The differences in the way policy and digital professionals work inspired our recent discovery looking at how digital professionals can work better with policy professionals.

Original source – Stephen Hale

Comments closed