Notes on New Digital Service Feedback
As before it is important for me to state upfront that while I work for the Government Digital Service in the Cabinet Office everything I say here is in a personal capacity.
Quote: “To truly deliver services and information fit for digital, and for the future, Parliament needs to think radically about the entire end-to-end process, not simply designing processes to take the information Parliament produces and put it online.”
The first thing I would note is that putting a senior experienced manager in change of a combined digital team will not be sufficient. It is imperative that that this is done in conjunction with a wide ranging transformation project which must have a remit that reaches beyond the bounds of the digital team. For example, when implementing an Agile development methodology it is vital that Product Owner roles come from ‘the business’ and not from within the delivery organisation.
Similarly, when introducing the concept of ITIL Service Managers it is critical that those roles are filled from those that represent the ultimate end users of those services – whether they will be citizens, internal Parliament users or other organisations.
Quote: “Investing so much in one individual is very risky. Perhaps it would be a good idea to have mySociety lined up to conduct a follow up review of the Digital Office after 2 years. If this follow up report identifies poor performance (based upon some agreed criteria) in either the Head of Digital or the senior management team there should be some mechanism to remove them (e.g. fixed term contracts for all senior staff).”
Fixed term contracts are not unusual in this area. However, it would be important to agree a set of SMART criteria against which the digital team can be assessed at the end of the period. This can be very tricky to do when there is no financial conversion funnel. The important things are whether the users reached the information they required and had an overall successful digital experience. This is best done via detailed analytics, itself a complex skill, and user feedback surveys.
Quote: “The digital director would need to be a member of the management boards of both houses and have the status equivalent to other departmental directors and be supported by a Chief Technology Officer.”
It will be important for the new role to be sufficiently senior to be able to influence key stakeholders. The Office of the government Chief Technology Officer (OCTO) has significant experience in both recruiting for such roles in government departments and defining how it will fit in with existing organisational structures.
Quote: “There are too many Boards, without the right skills to make the right decisions. There is too much adherence to structures and governance that stop getting things done.”
The only valid measurement of success is delivery of a service that fulfils previously gathered user needs in a manner that returns a high satisfaction rating. If there are parts of the organisation that are impeding that work, for example by extending the length of project Discovery Phases, then they should be treated as blockers and addressed by the new Digital Director.
Quote: “Should the Digital Service have a monopoly of supply of IT services?”
Definitely not – it will certainly sometimes be the case that outsourcing pieces of work to 3rd party SMEs, potentially procured via the GDS Digital Services Framework, will be the best way to proceed.
That said the Digital Service will still have two critical functions to perform as part of any service introduction. The first of these must be spend control. One of the keys to GDS’s success is the manner in which OCTO has spend control over IT and digital spend across government. This has allowed highly experienced technologists and delivery managers to have a say over which projects can proceed and how they will be approached (i.e. in small Agile chunks rather than large scale waterfall developments). The second function provided by the Digital Service is accreditation. There must be a team that assesses whether a service is fit for purpose to be allowed onto the Parliamentary website. It is suggested that this team works with a published service standard similar to the one used by GDS to assess government transactional services. This should include a number of critical components including the ability for the service to be continually improved and to provide an Assisted Digital component for those users that cannot use the digital system.
In general it is very strongly suggested that the new Digital Director and the members of his team spend some time shadowing the Transformation Team in GDS to discover how they have been working on digital transformation project across 24 government departments.
Quote: “How will the momentum of the project and staff morale be maintained: importance of continuing communications about what is happening.”
There are a number of ways of helping to achieve this goal. A well rounded comms plan is a must and should cover digital and number of areas including:
- Blogging – for example Mike Bracken, Executive Director of Digital in the Cabinet Office, made great use of weekly 5 minute update videos as part of the GDS blog for the first several months of its work
- Agile project development should include internal public show and tells every sprint
- Teams should be encouraged to post regular week-notes style updates
- Social media – see the GDS Social Media Playbook
- Non-digital channels such as notice-boards and internal publications
- Existing hierarchical communication channels such as staff meetings
Each of these channels should provide a mechanism for giving feedback.
Perhaps the single most important thing that can be done to help staff feel they are more involved in the overall change process is to give them access to the prioritised backlog of work that is taking place. If this work is kept in a cloud based service such as Trello it becomes easy to either give read-only access to specific people or to anyone who wishes to read it – giving maximum transparency. Such platforms can also be used in read / write mode to allow people to be able to provide feedback within the tool on the specific actions listed.
Quote: “There should be recognition of the variety of users of Parliament’s digital services, including internal users, with different needs and priorities.”
The other key mechanism for ensuring that staff, citizens and appropriate organisations feel part of the development of new digital services is to ensure that they are included as part of user research (short video, GDS blog).
This is a vital part of making sure that any services that are developed are focused on key user needs.
Service design phases
Quote: “Decision-making is something that is problematic in our experience on projects, with a sometimes extreme risk averse-ness that can cause months of slippage to a project. There is sometimes an absence of policy, but a desire to introduce a change – and the belief that the introduction of an IT solution will bring with it the answers to how we need to do things, which is the wrong way round.”
Quote: “Decisions have to be implemented: too often, decisions are not fully implemented or there is an unclear differentiation between policy decision and discussion.”
The strategy is delivery.
The method to address this issue is to use the four-phase service design method:
- The Discovery Phase is the fixed-cost timeboxed period during which user needs are gathered, limitations (contractual, policy, technical, etc) are defined and technical architectural designs are drafted. It is expected that the Discovery Phase will last no more than 4 to 6 weeks. It is very important that the valid outcome of a Discovery Phase can be to halt any further work on the project.
- The Alpha Phase is where an initial prototype of the service is created. Extensive user research should take place during this phase. There should be regular show and tells every sprint gathering further feedback. At the end of this phase the service should be made available for real usage to a limited number of users. The Alpha Phase is expected to take between 10 to 16 weeks.
- The Beta Phase is finalising the service before it is made live to all users. This may be completing final user stories beyond the initial minimum viable product or final integration with other services. The Beta Phase is expected to take 8 to 12 weeks.
- The Live Phase is when the service is made available to all users. However, this is only the start of the lifetime of the service. It is critical that the multidisciplinary product team remain in place to not only provide support for the service but to also continue to introduce improvements base on user feedback and analytics data.
Working in this way distributes the risk and decision making throughout the project allowing senior stakeholders to feel more comfortable during development due to continuous demos and vocal feedback from users.
Quote: “Could the Digital Service make more use of cheap technology solutions eg open source?”
The short answer is yes – many large scale services in and outside of government are built on top of open source components. However, support costs for services are often proportional to the complexity and resilience of the architectural design of the infrastructure as much as any licenses for proprietary software. Carefully crafted cloud based RESTful services currently provide the best solution in this area.
Quote: “‘Legacy software’ is often fundamental to the work of Parliament and should not be dismissed as out-of-date.”
‘Legacy software’ is, by its very definition, out of date. If an older service is an important part of how Parliament works then it should be assigned its own ITIL Service Manager and be treated the same as any other Live Phase product with its own product group providing continuous improvement based on a published roadmap.
Quote: “There need to be clearer governance arrangements for the website. Who is its editor?”
Content ownership is highly likely to be distributed. It is strongly suggested that one of the easily findable pages on any content provision service will contain a list of content owners and contact methods for them.
It’s further suggested that these content editors form their own community of interest and work closely with their readership, via active user research, to provide continuous improvement of their individual areas.
Quote: “Don’t forget that some people aren’t or won’t be digital – Parliament needs to cater for their needs as well.”
There is an entire team at GDS working with departments to build their Assisted Digital solutions. These must include capability to provide channel shift assistance to digital for those that want it and Digital Inclusion statements for those with no or limited IT skills.
Many of the questions raised in the Feedback document can be directly addressed by reading the 26 points in the GDS Digital by Default Service Standard.
Quote: “There are lessons to learn from the creation of the Government Digital Service, but our Digital Service will not be a replica. We have different users and different aims.”
I respectfully disagree. The purpose of GDS is to find out the user needs of the people who will be using GOV.UK and the various government digital transactional services and work with departments to implement quality solutions that fulfil those needs.
Any organisation providing digital solutions should be based around the same fundamental ideas regardless of their user base, funding model, internal stakeholders or history.