Extending Repairs Hub to RCC Agents – final Show & Tell

In our last Show & Tell for Extending Repairs Hub to RCC we showed improvements developed based on initial feedback from RCC agents that have been using the new app since 12 June.

I’d like to thank the 25+ people who have been actively involved in developing Repairs Hub since its inception last year. It’s great to see it grow, with 50+ users already registered on the system and almost 1000 repairs raised over the last few weeks.

Have a look at the S&T slides to see what users say about Repairs Hub and a list of recent improvements. Link to Slides

Extending Repairs Hub to RCC Agents

It’s been 4 weeks since Repairs Hub went live in the RCC with agents raising new repairs and answering queries about existing repairs. Agents have successfully used it to raise more than 800 new repairs. In the last month we have had the chance to add improvements based on the initial feedback from RCC agents.

Key improvements include:
– ability to cancel repairs
– improved cautionary contact alerts
– improved workflow with a direct link from the NCC app to Repairs Hub
– support for additional SOR codes (including ‘out of hours’ codes)
– resolved a bug concerning priorities in DRS
– adding name of officer who raised the repair
– limiting repair description to 250 characters (to make sure everything goes through to DRS)

We are also currently finishing work on:
– adding multiple SOR codes (DLO only)
– tagging a repair as ‘recharge’

Extending Repairs Hub to RCC Agents

The Repairs Hub has now been actively used for over 2 weeks in the Repairs Contact Centre and the agents have successfully used it to raise 500 repairs so far. During the last week, we’ve implemented some changes based on what we’ve learned from users during this time.

Improvements made in the latest release:

Added link from the NCC (CRM) app directly to the property page in Repairs Hub – there’s no more need to search twice for the same address

Added support for further SOR codes when raising repairs

Description for new repairs is now limited to 250 characters (and we’ve added a handy character counter)

Resolved issue with assigning ‘gas breakdown’ jobs to ‘gas servicing’ – they should come through correctly now

Added alert for agents to not book an appointment for immediate and emergency jobs

Added ‘raised by’ on works order page to display the name of agent who raised the repair

We’re now going into our last week and planning to make a few more eagerly awaited improvements. We will hold our last Show & Tell on Tuesday 9th July at 10:30 in the ground floor meeting room at the Florfield depot. Come join us there!

Link to Sprint 6 Show and Tell Slides

Extending Repairs Hub to RCC Agents

The Repairs Hub (RCC) team has been hard at work, preparing to launch the app to production and aiming to raise first live repairs with the initial RCC users next week. We have managed to resolve the main issues that have been bugging us for some time and are now polishing off the last bits to make sure everything is as ready as possible. We’ve been working on:

Increasing the number of SOR codes that we can support

The Repairs Hub app initially aims to support all SOR codes produced by KeyFax. We have mapped those codes directly to relevant suppliers (DLO or external), so that the RCC agents don’t need to worry about doing that manually.

Testing end-to-end with Sean from DLO

We wanted to make sure that jobs raised in Repairs Hub and booked through DRS will be correctly displayed on the mobile devices used by the DLO through 1st Touch. When testing with Sean we were able to successfully raise a repair, get it through to 1st Touch and then receive the work order report (PDF document) after the job was marked as completed.

A new repair is now logged against the actual user rather than ‘Hackney API’

This problem was much tougher to crack than we initially thought, but we’ve managed to make it work! Every repair is now logged correctly to the RCC agent using the system.

UX changes based on initial user testing with RCC agents

We have now made it more obvious which property you’re looking at and which property you’re raising a repair against in order to avoid potential mistakes. Further user stories based on user feedback have been added to the backlog.

Talking to the NCC CRM team about using their app to manage contact details

We were hoping that we would be able to use the NCC app to find and manage tenant’s contact details as well as log general enquiries. Further conversations this week, however, indicated that this might lead to potential problems when monitoring performance of the NCC team through Qlikview. We’ll need to address this question next week and find a solution that works for everyone.

Preparing for live deployment

We will deploy the latest changes to production in the next few days and are currently making sure everything will work properly, including the tricky Keyfax integration. We are also setting up accounts for an initial group of 10 RCC agents that will act as early adopters of the new system. There are some additional tasks on the ‘to-do’ list for live deployment, but we’re confident that we’ll be able to raise the first few live repairs with the new system next week.

Join us at our Show & Tell on Tuesday (14th) at 10:30am at the Florfield Depot (meeting room next to legal disrepair). As we’re almost at the end of the budget for this phase of the project, this might be our last one for now!

Working with Pipeline to share our digital efforts

Pipeline is a digital service that is designed to help us all work together to deliver digital services, so good that people prefer to use them:  https://pipeline.localgov.digital/.

Adopting Agile at Hackney

Over the last two years we have been working hard to change our approach here at Hackney, adopting Agile delivery and user-centred service design. This has meant lots of big changes in our team, how we work and the way that we manage our portfolio of projects.

With the move to Agile delivery comes a dramatic acceleration of pace and our shift from large projects to quicker, sprint based delivery has meant that our portfolio has become much more complex than before. As Lead Delivery Manager responsible for coordinating that I’ve been working with colleagues to look hard at how we can make that as easy as possible.

Hackney has devised its own Agile lifecycle, based on the Agile delivery principles set out in the GOV.UK service manual, and although we know that we need effective governance in place, it’s essential that this doesn’t slow down delivery. One of the key pieces of governance we need for delivering projects is an easy way to see what projects we are delivering and keep track of status and updates.

We are working as part of the wider local digital community

Hackney have committed our support to the Local Digital Declaration and want to help support collaboration in digital local public services. You can read more about why we think that’s important on our blog: https://blogs.hackney.gov.uk/hackit/in-support-of-the-local-digital-declaration. As well as managing our own portfolio of delivery, we also wanted to make sure that we could be open about the work we’re doing, share learning that others can use and identify opportunities to work collaboratively with other councils who are looking at similar challenges.

We started with user needs

We identified the following user needs:

  • As a delivery manager I need to report once on the status of my project so that it’s easy to update stakeholders
  • As a portfolio manager I need to see an overview of all my projects so that I can communicate our projects
  • As a manager I want to see other authorities’ pipelines so that I can identify opportunities for collaboration

We looked to see what tools might meet those needs

We did an initial pre-discovery exercise to see what tools might best meet our needs. Agile isn’t new and there are a wealth of tools that are being used by Agile teams across the globe. But we didn’t find anything that felt like it quite fitted the bill.

We felt that the best match of the tools we looked at was Pipeline, which had been built as an alpha in 2014 by LocalGov Digital. This was a good fit with our aim of working collaboratively, but would need some tweaking to give us the portfolio tracking capabilities that we needed.

We decided that rather than buying a thing or making a thing ourselves, it would be best to contribute to a community tool and see how we might ‘stand on the shoulders of giants’. We got in touch with the LocalGov Digital team and were delighted that they were up for that.

So, what did we do?

Acknowledging that we needed something quickly and with our internal developers all at capacity we devised a brief and posted it onto the Digital Marketplace. We got strong bids and chose Rainmaker Solutions to help us to build on and iterate the great work that had already been started in 2014.

We held a workshop with key users to tease out what else was required to make the Pipeline service a tool that would add real value to Hackney and other public organisations. The previous iteration of Pipeline had a promising start but its use had declined, so we needed to create a tool that would add enough value that people feel compelled to use it. A quick discovery exercise delivered lots of feedback which was captured as user stories and prioritised in a backlog for an intense 3 sprint project.

As the Product Owner for the project I ran a session at the recent LocalGovCamp event in Birmingham to demonstrate the updated service and get feedback from peers. I presented these slides and ran two quick workshops. The first was to gather ideas of the functionality that people would like to see in Pipeline and the second was to discuss why people hadn’t used the first iteration of Pipeline and consider why they might not use the updated version. The functionality discussion threw up a few ‘Robocop’ items but the main thing we found was that Pipeline would meet the needs of the users in the workshop (you can see the feedback we captured here). The barriers gave us more to consider. We asked ‘why won’t people use Pipeline’ and found a range of concerns in response (the feedback from the discussion is here):

  • Fear of working in the open
  • Scared of failing in the open
  • Duplication of effort
  • Didn’t see what value it would add to their organisation
  • A gimmick that won’t be used
  • One size fits all won’t necessarily work for their organisation

Fear of working and failing in the open’ was a really interesting barrier. We were incredibly lucky to have Mike Bracken (one of the founders of GDS) visit Hackney this week. He spoke passionately about working in the open and failing fast and learning. I believe his comment was ‘it’s easier to deal with failing if you’ve been open about what you’re doing’. Fear of failure is a cultural issue in many organisations, including local government – my view is that working in the open enables us to focus on being clear about what we’re trying to deliver.  

Duplication of effort’ is a tough one and is something we’re mindful of. Currently our project updates are posted in a public Google+ community, HackIT Delivers. Our Delivery Managers will continue to post their updates in the G+ community and will link status updates in Pipeline to the G+ posts. It’s not ideal, but is minimum duplication to share our work with a much wider audience. Further iterations of Pipeline will hopefully include open APIs that we can connect other project status update tools to.

Adding value’ and ‘it’s a gimmick that won’t be used’ aren’t technical blockers that can be fixed. We’ll show through doing. It’s a case of hitting critical mass: when the product is used widely there will be value derived from the tool and a compelling reason to use it. We can make that happen if we all use Pipeline.

One size fits all’; this was a challenge for this next iteration of Pipeline. At Hackney we follow the GDS approach for many things, but our project life cycle (HAL) has project phases that use different naming, which fitted better with how our organisation manages projects. To stimulate collaboration it was decided that Pipeline would use the standards that have been developed by GDS as that’s a model that we all recognise. So, it is a one size fits all approach but that one size is award winning and widely recognised as a beacon of best practice. We think we can adapt to it without much difficulty.

What Happens Next?

We are starting to use Pipeline and we’re keen that you benefit from it, too.

We’re meeting LocalGovDigital colleagues and the MHCLG Local Digital Collaboration Unit shortly to discuss how Pipeline might be used to help publish all of the collaborative projects they’re looking to fund and deliver – including applications for the Local Digital Fund that has been launched to support the Local Digital Declaration.

This latest iteration of Pipeline was delivered in 3 sprints. There were lots of user stories and additional functionality delivered but there is still a big backlog of additional user stories that we identified through the discovery work (you can see these on this Trello board). We will be looking at how we might fund an additional development sprint in the next couple of months, maybe using Pipeline we might find another organisation that wants to work with us to deliver the next release!