Open collaboration pipeline
The structure of local and central government lends itself to public organisations working in silos to devise solutions to meet their own needs. This leads to huge inefficiencies through duplication of spending, lack of collaboration and sharing of knowledge.
The vision for Pipeline is to develop an online tool that enables public organisations to share details of projects from concept through to delivery. It will promote collaboration which in turn will break inefficiencies and also contribute to the Local Digital Declaration ambitions and commitments.
The following ambition:
- “We will embed an open culture that values, incentivises and expects digital ways of working from every member of our workforce. This means working in the open wherever we can, sharing our plans and experience, working collaboratively with other organisations, and reusing good practice.”
And commitments include:
- Publish our plans and lessons learnt (for example on blogs, Localgov Digital slack; at sector meetups), and talk publicly about things that have could have gone better (like the GOV.UK incident reports blog).
- “Share knowledge about digital projects where there is an opportunity for potential reuse or collaboration with others.”
- Re-platform the prototype to a scalable platform that will offer:
- improved performance
- a solution built using GDS patterns
- an opportunity to add more advanced functionality that can’t be deployed to the limited platform that the current prototype is built on.
- development of REST API’s to enable integration to other systems i.e. the User Research Library that has been developed by Hackney.
- Develop a business/benefits case to share with other public organisations to promote the use of Pipeline.
Success criteria are:
- Develop scalable prototype that is flexible and organisation agnostic to test with a much wider and larger set of users.
- A strong benefits case for every public sector organisation to adopt Pipeline.
This project will be delivered using agile ways of working. We anticipate running 7 2-week sprints with a mixed team of contractor and in-house roles (see question 12). We will utilise user centred design approaches to ensure the product meets user needs.
Our aim is to deliver an enhanced prototype of Pipeline; crucially with an API that will allow us to scale in a future phase. We want to test this with current users and potential users to iterate and improve its functionality. Moving the current Pipeline onto a new hosting environment will allow us to develop an API and redesign the front end inline with GDS design patterns.
We have created a Trello board outlining 12 essential events, including user stories and acceptance criteria. Our initial thinking is:
- Two rounds of user testing
- Transition to new hosting
- API development
- Workshop on benefits case
- Review of key performance indicators
- QA and security testing
- Accessibility review
- Completion of a service assessment
- Delivery of required outputs
We will use sprint reviews and show and tells to assess delivery against objectives. Objectives will be SMART and relate to success criteria. Each sprint will have a goal that will tie the work into the high level objectives and project vision. Retrospectives will help us improve the way we work as a project team, offer the opportunity to learn from another and deliver at a consistent pace.
MHCLG outputs will be incorporated into sprints as user stories. The final sprint will ensure that outputs are completed, polished and publishable as required.
The main benefits of this project will be:
- A single view of opportunities for collaboration; Pipeline will provide key details of the opportunity or project such as phase of delivery, dates, budget, contact details and the ability to contribute or watch an opportunity/project.
- Avoid duplication of effort through a single resource that provides functionality for status reporting, links to project/opportunity related files/documents/assets, ability to report to stakeholders or anyone who has registered an interest in the project/opportunity and REST API’s to integrate to other systems for example Github.
- Enabling the sharing of learning across similar projects to avoid repetition of mistakes and enable faster development of new products/services.
- Ultimately the reduction of costs to public sector organisations through openness and collaboration.
- Promote a culture of openness.
To validate that Pipeline meets user needs there have been two Discovery workshops attended by 25 local authorities. The outcomes from the first workshop are captured in Trello here, outcomes from second workshop are captured here and prioritised in Trello here.
Following this, we have continued to develop the prototype and have iteratively tested with 4 local authorities and a user from the GLA. Link to the prototype is here – https://pipeline.localgov.digital/
Subsequently a further 32 public sector organisations have registered to use the prototype and are being encouraged to provide feedback through a linked form.
Recently, the Product Owner delivered a workshop at the LocalGov Digital conference to demo Pipeline. Feedback was captured from the 15 public sector organisations who attended the workshop and a blog post about the outcome of that workshop can be found here.
The prototype has been built using principles and terminology influenced by GDS for example project phases follow the Discovery, Alpha, Beta, Live. It’s anticipated that the majority of public sector organisations will also follow GDS, this will keep the product as agnostic as possible and help to encourage wider adoption.
One of the outcomes of this application is to produce a quantifiable business case to support embedding Pipeline into organisations; this will focus on:
- Pipeline providing a single view of opportunities for collaboration
- Avoiding duplication of effort: reporting, delivery and build
- Enabling the sharing of learning across similar projects to avoid repeating mistakes
- Promote collaboration on projects to reduce costs
The code for the developed prototype is open source and has been made available for comment on Github
Working with other councils is essential to test and iterate Pipeline during the next phase of development. There are currently 36 organisations using Pipeline and 59 projects listed on the site.
We will follow-up with councils who are using – or have expressed an interest – in Pipeline. We intend to involve them in user testing – their feedback directly influencing iterations of the tool.
We will use the Pipeline prototype itself to post status updates, links to user research findings and emerging work on benefits. We’ll also utilise G+ suite and the HackIT website to share what we are learning and promote the use of Pipeline.
Working in sprints to deliver this phase, we will have regular show and tells. We will invite interested councils to these and will also host show and tells with our partners organisations to raise profile of the work and benefit from wider range of inputs.
We aim to organise a workshop with interested public sector organisations and MHCLG local digital collaboration unit to define and articulate benefits of pipeline, drawing on their needs as users and also their knowledge and experience to shape the benefits case and key performance indicators.
By April 2019 we will produce the following outputs:
- A benefits case – required
- User research findings – required
- An end to end user journey
- An iterative version of pipeline that has been tested with users – required
- Decision logs for key decisions
- A proposal for a “beta” phase – required
- Key performance indicators published openly
- Learning summary from an end of project retrospective
Delivery of these outputs will be built into sprints as user stories. The final sprint will ensure that outputs will be finalised and ready to share online. We propose to publish our user research findings in the user research library being developed by Hackney. We will liaise with MHCLG regarding how best to make these outputs shareable for the widest possible engagement.
We have identified three users of Pipeline and their primary needs:
Administrators – these are system users e.g. product owners who create projects and manages permissions.
Contributors – these are members of projects e.g. delivery managers who can add, edit and remove information relating to their project.
Watchers – these are interested individuals who want to receive information, status updates or changes to a project. They do not have permission to add, edit or remove information.
At the end of this phase we aim to have an enhanced prototype that is:
- Scalable – supported by an API and organisation agnostic
- Accessible – users can use Pipeline successfully first time and it adds value to their work
- Measurable – appropriate indicators have been developed and are being tracked
- Secure – has been through security testing and any issues are resolved.
To these ends, our proposed user research objectives are:
- Validate user needs from the previous phase
- Test with all three user personas, including those with accessibility needs
- Create an end-to-end user journey
- Test and iterate pipeline tool and functionality
- Test and iterate key performance indicators
- Develop a benefits case.
We will test regularly with users. The findings will inform how we iterate the design and functionality of Pipeline. This is to ensure it meets user needs and we adhere to accessibility standards.
We will work with our partner organisations and stakeholders to develop a benefits case for using Pipeline as a collaboration tool of choice to:
- Improve the quality of digital services
- Find common solutions
- Reduce/avoid costs
- Promote greater transparency in governance and accountability by working in the open.
We will develop a set of performance indicators to measure the degree to which Pipeline is meeting user needs and the relevant priorities in the local government digital declaration (see question 1).
Methods and techniques will be user-centred and be delivered using agile ways of working. This could include:
- Face to face user testing
- Remote testing
- Feedback loops
In terms of additional support, the successful delivery of Pipeline would benefit from:
- Promotion of Pipeline to other public sector organisations as the collaboration tool of choice
- Help to recruit public sector organisations as testers so that their feedback can improve the service
- Access to an economist and/or business analyst to advise on the creation of a business/benefits case
- Access to an experienced performance analyst to advise on the collection of meaningful quantitative indicators and means of measurement
- Opportunity to test Pipeline end-to-end service with the Minister for Local Government (service standard 15)
There has been no funding provided to build a scalable prototype designed and built on GDS patterns.
The initial Discovery phase was undertaken by the LocalGov Digital community and the first prototype was built by developers through LocalGov Digital. Hackney has recently provided £29,350 (Digital Marketplace link) of funding to develop Pipeline into a tool that helps to meet its local needs. This has enabled some iteration of the prototype though it is still built on an open source wiki platform that provides very limited functionality and scalability.