Back to the drawing (on)board(ing) – Manage Arrears Weeknotes – W/C 29.06.2020

Weeknotes for the Manage Arrears project – this week’s focus is onboarding.

Purpose of these weeknotes

The purpose of these weeknotes is to provide an account and a reflection on one of our more pressing issues, getting more Rent Arrears officers onboarded. This is partly for the team to have a common narrative and also to explore the issues around onboarding in the context of working fully remotely. 

Onboarding background

One of the key things that we are looking to do in this phase of Manage Arrears is to get more users using the system. Currently out of the 14 patches in the Rents Arrears team only two are formally using Manage Arrears.

We had initial discussions about this and sketched out an approach, which would have seen us onboard users in groups of two patches at a time. Patches in Arrears are made up of a Credit Controller and a Legal Case Worker but Legal Case Workers are often shared across two patches. This would have meant onboarding 3 people at a time for several weeks. Until all the patches were onboard.

Onboarding remotely

We were also trying out a new approach to onboarding. The previous two patches had both been onboarded prior to the coronavirus pandemic where much more of the support could take place in person. 

As a result we tried out an approach where we put aside a chunk of time for a video call, where we kept the lines open but with most of the participants on mute. This meant that people could get on with their work but also ask questions if they needed it. 

This had its advantages: people were able to ask and answer questions and we were able to share screens to work through issues. It also had some disadvantages: as there was a lot of conversation, which meant that officers needed to leave to make calls and deal with other issues.

This session highlighted a number of things. The first was that it didn’t make sense to try and get people to start using the new system before automation had been turned on. There were a number of recommended actions that appeared to be mistakes. On investigation the recommendations were accurate but confusing as a result of the different processes and terminology between the two systems. 

Reaching a common picture of onboarding

Another thing that emerged from this was a lack of a common picture within the delivery team about the nature of the onboarding itself. We realised that we needed to be more aligned as to what exactly onboarding people on to the new system entailed and when we should be doing it. 

This has resulted in three concrete actions, the first is to narrow our immediate scope in terms of onboarding. Instead of looking at all 12 patches and rattling through them immediately, we are instead focusing on bringing 2 more on next week. The second is to make sure that we have turned off Universal Housing automation and turned on Manage Arrears automation prior to any further onboarding. 

The third, and probably most important, action is for us to come together as a team and ask the question: exactly what conditions need to be met, regarding the product and the team, for us to be confident to rollout to the remaining 10 patches?

There are a number of considerations, including around features and processes, which are pretty standard for this kind of discussion. In addition there ones that are unique to this remote working period. It is vital that we work through these together prior to planning further onboarding. 

Other highlights

We have really started to get our head around how we will get Service Charge data out of Universal Housing.

We have started to get a better understanding of the processes involved in court agreements.

We have started to refine our first iteration of the design for the Service Charge worktray, when this is completed we will be in a position to refine it further with stakeholders and then to start testing. 

We have continued to implement our first iteration of the informal (or non-court) agreements user interface.

Personally, I’ve been having one to one catch ups with every member of the team. This isn’t something I would normally do as part of my regular schedule whilst working on developing a product. I normally try and have these conversations more informally but this has proven difficult during remote working. I have been having these conversations throughout the week and have found them a really enjoyable way of connecting with the team despite being fully remote. I would definitely recommend them. 

Previous Show and Tells and weeknotes:

Show and tell 36 video / slides 24.05.2020

Weeknotes 2 W/C 15.06.2020

Show and tell 35 video / slides 10.05.2020

Weeknotes 1 W/C 01.06.2020

Show and tell 34 video / slides 27.05.2020

Report a Problem : Week notes 3/7/20

GOOD THINGS

We’re going on Monday! We’ve had excellent contributions from so many people to make this happen. I’d particularly like to highlight the excellent work that the Contact Centre have been doing to test the system over the last few weeks.

Out first multidisciplinary continuous improvement meeting is organised for Thursday . These will be taking place every two weeks. They will be a place for everyone involved to catch up about the outstanding post go-live work we know we still need to do. Importantly, it will also be a place where representatives from the service area teams can raise any issues they’ve encountered with the service.

LEARNED THINGS

Don’t panic! The team found what appeared to be a large number of issues at the last minute. Instead of stopping the go-live we methodically went through them all. We discovered 5 or 6 places where we needed to make minor config changes to the system but everything else was either not an issue or already agreed to be fixed post go-live.

ACKNOWLEDGEMENTS

Our widely distributed team continues to do great work on this. Thanks to Matthew, Louise H., Louise W., David, Emma, Dave, Rasit, William, Ade, Sandrine, Sam, Tim, Keith and many others.

WHAT’S NEXT

  • Go live Monday!
  • First continuous improvement meeting

Manage a Tenancy Hub replatforming : Week notes 3/7/20

Welcome to the project formally known as “Single View for Housing”!

The team started sprinting this week and has done an excellent job out of the gate. This week the team has done a lot of things but here’s some highlights.

  • Crafted an excellent backlog of work for the project (thanks Stu!)
  • Got very close to adding our Housing Officers and Area Housing Managers to the current version of Single View (thanks Lorraine and Ben!)
  • Gotten a long way into setting up our development environments and AWS infrastructure (thanks Tuomo, Chris and Tony!)
  • Created a great set of mock-ups for the UI for the work-tray (thanks Gill!)
  • Moved on the process for establishing the project business cases, roadmaps and contracts

As ever, it’s all about constant adaptation so we were very happy to welcome Ana to the team today as another one of our developers.

Next week we’re going to do the following.

  • Deliver our first code into production
  • Have our mid-sprint review
  • Get the HOs and AHMs onto Single View
  • Confirm who are stakeholders are for existing technical integrations (e.g. the Qlik team)
  • Validate the service KPIs
  • Discuss how we’re going to do end-to-end testing
  • Demo of the rest of the excellent tools MadeTech and Future Gov have built with Hackney’s Benefits and Housing Needs team to the AHMs and HOs. This will show off things like the Shared Plan, Document Upload tool and SMS messaging system.

Our first show and tell will be on 15/7/20 – we’ll include the video in the next week notes.

Amazon Connect weeknotes, w/e 3 July 2020

It’s been a little quieter on this project this week; it feels like it’s settling down somewhat. However, we’ve still been tinkering with the system to optimise things and I think it’s paying off. Over the last week, the stats are as follows:

  • 2407 calls were offered (that is, received by the system)
  • 673 calls were partially deflected (that is, the caller used the bot but still spoke to an agent)
  • 124 calls were fully deflected (that is, the caller only used the bot or payment line)

We now have some more useful data in the new report as well. The deflected call rate is now 33.1% – a huge increase that properly reflects calls that are routed to the payment line as well, so not touching an agent. Even stripping out the payment line, the rate is still 16.8%, a significant increase on last week. Of those calls handled by the bot:

  • 346 callers used the balance option
  • 60 callers used the transactions option
  • But only 156 callers passed identification & verification 

That’s a pass rate of 38.4%; not fantastic but it has improved since we changed the messaging to highlight the need for the payment reference. We’ve also implemented a retry loop during this week, so callers get two attempts with each piece of information before being passed to an agent, so next week should see another improvement in this rate. 

Feedback remains steady. Although the response rate has reduced, residents are firmly in two camps. Those who have had a trouble-free experience love it, those who have had problems with the bot don’t love it. We’ve been able to do some investigation on some of the poor experiences and noticed a minor issue with the Transactions API, which has been amended. 

During the week I had a chat with colleagues at Durham County Council, who have implemented voice capture to route calls and provide recorded information, though they don’t provide personalised information like we are. It was a useful conversation and I’m reassured that we are doing the right things in this pilot, especially around reason capture as that really drove their strategy. Their deflection rate is high, and it’s a good benchmark. 

I’m going to be off for a couple of weeks but I’ll write in the middle of next week about the outcome of the service assessment and potential next steps. 

Transforming Print & Post – Weeknotes 3rd July 2020

We’re half way, weeknote 3 of 6 is here! If you missed last weeks note, don’t worry, you can still read it.


TL:DR Version

Another busy week for the team. Despite challenges around availability, we still managed to form and prioritise our user stories, create user personas and ideate what our new service could be. We recruited for and planned how we will test our ‘To-Be’ service blueprint. We also enacted some points of our retrospective feedback (around the sustainability of team engagement, more frequent breaks and finding ways to lessen the intensity of work so we feel like we can process) which have definitely helped the week feel highly productive but not quite as exhausting.


The Long read

What. A. Week.

It wasn’t an ideal start and we saw our team 2 people down on Monday and a person down on Thursday because life comes before work. Never the less, we have ploughed on and done some great work.

Planning on Monday saw us really take on board some of the retrospective points we identified last week around the intensity of work and time management challenges.

We intentionally planned less work than the last sprint to combat some of those feelings and built in more breaks during group sessions to allow the team to really process what we were thinking about and discussing. We’ve seen this pay dividends through the rest fo the week which I will come to.

We also made sure to add really clear descriptions of what we wanted to achieve with each card on our Trello board as the retro surfaced that sometimes the outcomes of a card wasn’t as clear as it could be.

First up for the week was synthesis. Maria led a great session on this and made sure the whole team knew why they were there and what we were aiming to do.

We had a great definition of what synthesis is to guide us:

Synthesis is…
A process of sense making
Sharing stories and prioritising
Creating a coherent summary of what you know so far

The goal is to develop…
Consensus across the group
A clear journey of evidence for design

Matt Cooper-Wright

Maria had set up a range of activities on our virtual whiteboard software (Ideaflip) to get us into the zone for synthesis. Considering we were 2 people down, I think we did fantastic work to end up with this

digital whiteboard view of synthesis
Our digital whiteboard of synthesis using Ideaflip

We ended up with 34 MoSCoW (Must have, Should Have, Could Have and Won’t Have) prioritised user stories that our project sponsor Cate McLaurin gave the thumbs up for.

prioritised user story tickets

Once we had our stories, we moved onto forming the personas of our users who have these needs.

As Junior described in his session, personas are fictional characters, which you create based upon your research in order to represent the different user types that might use your service, product, site, or brand in a similar way. Creating personas will help you to understand your users’ needs, experiences, behaviours and goals.

We decided we needed 4 personas to cover the needs of:

  • high printing
  • high printing and posting
  • low printing
  • low printing and posting

We also decided to factor in working preferences and levels of digital literacy as these were also key things when designing a service fit for all.

During this process, we identified that we didn’t quite understand the low printing persona’s motivations as much as we should so arranged a last minute interview to pick up on this and make sure we were representing our users as accurately as possible.Thanks to our Council colleagues in HR who supported this.

Our personas are Adrian, Carole, Nikita and Ibrahim. Expect to be seeing their persona boards in the show & tell next week!

Once we had our personas, we could start thinking about how we can meet their needs in ideation. At this point, I declare Maria the master of Ideflip because, well, just look at it!

ideaflip ideation instructions
These were our instructions for the day

We made sure to assess our ideas against the user stories and rank them as meeting, not meeting or kind of meeting the prioritised needs of our users. We also made it clear when our ranking was given based on an assumption and captured what that assumption was so that we take that into careful consideration when doing a more granular design and feasibility assessment later.

Our completed ideation assessment against user needs
We assessed our ideas against the prioritised user needs.

Finally, we made tweaks to who will be working on the project and when. We will now have Colin (from the print team) Monday, Tuesday and Wednesday rather than just Monday & Wednesday. Tony will continue on Tuesday and Thursdays. Yhanieke and Claire (from the corporate business support team) will continue to be available on all project days (Mon – Thurs) until the end of the project. We really are hoping this will help to reduce some of the feelings of ‘disjointedness’ that came out in the reto that we felt weren’t sustainable. As always, we will be keeping an eye on this and seeing how it works.

And that is where we left the week! The rest of our time was spent tweaking and making arrangements for research next week, drawing up the to be blueprint and generally patting ourselves on the back for another great weeks work.

In an act of supreme cruelty, I’ve left all these pictures too small for your to read properly because I’m going to make you wait to see the user stories, full personas and the to be blueprint until the show and tell next week.

This is because we want to be able to present the full story of the service and for all the context to be together when we do. The best place to do that is a show & tell so, if you can’t attend live, keep your eyes peeled for next week’s note where I will be sharing slides and a recording of the show & tell.