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

Manage Arrears Weeknotes – W/C 15.06.2020

Purpose of these weeknotes

The purpose of these weeknotes is to provide an update on the work that we have done since our last show and tell on 10th June. It is also to flag one key area of concern for us in this project, moving away from Universal Housing. 

What have we done in the last week?

We have finalised our design for informal agreements, which are those  we are testing this next week with users in the rents team. We have also started work to implement some elements of these designs.

We have continued work on the Income API endpoints for informal agreements. This is really important work and will allow the improvements that the system will create on the quality of agreements data to be felt by wider teams in the council. 

We have finished work on refactoring our rules engine. This should make it quicker to add new functionality, including service charge and agreements functionality in the future. 

We have started to get a much better picture of the information needed by the Leasehold team for processing Service Charges. We will now be looking at how we can put these into designs for us to get feedback on and iterate.   

We are also looking at how we can better quantify the impact of our system. We have identified a number of key metrics and we are going to have a discussion with the Housing Transformation team next week to so that they can better understand our system and we can better understand what data they are already displaying. 

Rolling out the system to new users

This week we have begun our rollout of the Manage Arrears tool to the people in the Rents team who are not currently using it. At the moment only 2 patches in rents are fully using Manage Arrears. We have ambitiously set ourselves the target of getting all 12 other patches on by the end of July.

This week we ran three familiarisation sessions for those 12 remaining patches. These were very well attended and there was a fair amount of positive feedback on the new system as well as some challenging questions.

A big shout out to Elaine Geeves who led these sessions excellently, all the while trying to ride a fairly sketchy internet connection.

Moving away from Universal Housing

One of the things that the training sessions highlighted for me was how many of the current processes for people that are using Manage Arrears still rely on officers also using Universal Housing. This is concerning for a number of reasons not least because many of the benefits of the system do not get fully realised until people are using it end to end. 

Many areas that we are looking at building on in this phase will help us to move away from UH but we need to make sure that this is something that we are being mindful of as we rollout new functionality.

Previous Show and Tells and weeknotes:

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

Manage Arrears Weeknotes – w/c 1.6.2020

Purpose of these weeknotes

The purpose of these weeknotes are to provide an introduction to phase 4 of the Manage Arrears project and give you some high level information on the value we have delivered since phase 4 kicked off on 11th May. They will also flag some of the challenges that we are facing. 

Introduction to Phase 4

These are the first weeknotes for Manage Arrears Phase 4. Welcome. We are picking up on the work that has been done in the previous 3 phases. A write up of Phase 3 can be found here.

There is a new team this time that includes some people who have worked on it before: Ben, El (both from Made Tech), Elaine, Femi, Judith, and Miles (all from Hackney), and some people who are brand new to it: Antony, Csaba, Ninamma, Ludivine (all from MadeTech), Jenny (from FutureGov), Liam and myself (both from Hackney). We are also being supported by people in both the Leasehold and Rents team, especially Ian, Chorwar, Dermot, and Easton. 

The main immediate priorities of this phase is to look at the following areas: 

  • Agreements
  • Service Charge Work Tray
  • Rolling out Manage Arrears to more patches
  • Further layout improvements

What value have we delivered so far?

The main value that we have delivered since kicking off Phase 4 has been addressing bugs and technical debt in the Manage Arrears system. So far we have fixed a number of bugs, including allowing letters to be sent on the correct day when scheduling them on a Friday, improving the UX so users could return to their worktray after sending a letter, and allowing for large user names to write to the Action Diary. 

A lot of what we have done will also facilitate the delivery of value more quickly in the future. We have worked to refactor the system to increase the speed of deployments as well as making our dev, test and live environments more consistent.

This has not just allowed us to deliver value quickly but also provided a great opportunity to introduce new members of the team to the tech stack as well as delivering value quickly while we have researched new features that we are looking to deliver next. 


  • Covid-19: this is not just that the team is having to work fully remotely often with less than ideal work spaces or internet connection but Covid-19 is also impacting our ability to rollout the product. As many of the processes around arrears collection are not currently taking place it is challenging to onboard people to a tool where most of its functionality is not currently needed. 
  • Connecting with users: while reviewing our previous phase several stakeholders mentioned that one of the most important features of that phase was the development team colocating with our users in the Rents and Leasehold teams. This is something that we are obviously now unable to do and so we are having to think about alternative methods.
  • Building momentum on the Leasehold side: last phase we managed to work with Rents to get Manage Arrears into a position where their team could use it. We are looking to do something similar with the Leasehold team this phase. This is challenging as Leasehold is a very complex area with different workflows, business rules and data to Rents. Understanding enough to start but not waiting too long, and delivering value early is our main challenge on this.

Previous Show and Tells and weeknotes in Phase 4:

Show and tell 34 video / slides 27.05.2020.

Automated Server Patching Weeknotes w/c 02.03.2020


  • Patching on our on premise and data centre infrastructure is currently done manually. The infrastructure team has recently spent six months on the reimplementation of a patching system. The main goal of this project is to automate this process for the future.
  • This work is part of the DevOps programme of work, which we are carrying out with the support of Digi2al. 
  • The team is made up of infrastructure engineers supported by Dan from Digi2al to upskill:
    • Frank Barnett (Product Owner)
    • Omar Al-Okaidi
    • Tim Samanchi
    • Daniel Finch (Digi2al)
  • This project kicked off at the beginning of February. I would like to quickly thank Ian James, who excellently kicked off this project and has been delivery managing while I wrapped up on other projects. Thanks Ian!

What have we done so far

  • The under-talked about but critical logistical issues on this project have been largely ironed out. Things like getting access to Github, AWS, setting up test environments and Python development environments have all been completed and are crucial to the success of the project.
  • The team has been very busy getting up to speed with new technologies. For most of them this is the first time that they have written scripts in Python or worked with RestAPIs so there has been a steep learning curve that Dan has been helping them to navigate through.
  • The team has also started the process of writing scripts that will automate some of the key tasks that are currently done manually such as creating reading the spreadsheet that server patching is scheduled using and connecting with iVanti’s security control. 

What have we done this week?

  • We have started on our second sprint, which included the usual scrum ceremonies.
  • We have internally agreed an approach to using CircleCI to deploy patches on On Prem servers. 
  • We have built the python module that will manage scanning the template. 

What next?

  • Finalising the situation with our CircleCI licenses.
  • Finalising architectural decisions with the security team
  • Writing python scripts to update patch templates and to scan templates

Previous show and tell slides:

Complex Customer Journeys weeknotes w/c 17.02.20

Hypothesis generation

  • So far on the Complex Customer Journeys project we have been focused on gathering research and insight. This week we shifted into generating hypotheses that we can test in the future.
  • To do this we ran two sessions. The first session was designed to generate as many hypotheses as possible and to begin to identify priorities. To do this we used a framework from DXW:, namely: Because [research findings] we believe that [improvements ideas] will achieve [desired outcome] measured by [performance indicator].
  • The team generated as many hypotheses as possible from their experiences over the course of the project, we had notes from user research sessions and workshops to hand, to feed into this creation. When creating hypotheses we put question marks in as placeholders if we couldn’t think of a specific element.
  • Once we had generated these hypotheses we grouped them. We were left with 29 distinct hypotheses. At the end of this first session we quickly went through and put ⭐s on anything we didn’t understand and thought needed further discussion and ❤️s on anything we particularly liked. 
  • In the second session we each took the hypotheses with ❤️s (23! of them) and sorted them into 3 quadrants, one that mapped cost against impact, one that mapped strategicness and easiness to test and one that mapped our own confidence in the research findings and the performance indicators we had chosen for the hypothesis. 
  • From this we were able to identify a number of hypotheses that we wanted to test as a matter of priority.  
  • Zoe has been circulating and sense checking these hypotheses with the relevant services to get their input. 
  • The eventual outcomes of this work will be to create the council’s new customer services strategy with a learning by doing approach: we’ll test the hypotheses to understand how we can improve customer service delivery in these journeys; then replicate out to other service teams; and collate all findings to develop an overall vision and strategy for customer services. 
  • We’re excited about this work not only because it should lead to better, more empathetic services for our residents, but also because we’re demonstrating a new approach to colleagues around the council for how to create corporate strategies. Always happy to chat if anyone else is considering similar projects 

What else have we been up to this week?

  • Visiting Citizens Advice Bureau: Rahma and I spent Wednesday morning shadowing advisors at the Hackney Citizens Advice Bureau. This was a really great opportunity for us to get a direct understanding of users’ experiences on one of our complex customer journeys. It was really valuable to validate some of our assumptions about the confusion that the internal complexity of our system’s causes as well as giving us new insights into people’s experiences when struggling with debt. 
  • Prepping for the customer services steering group: we are working towards presenting at the customer services steering group on the 25.02.20. This will give us a steer as to which and how many of our hypotheses to prioritise as well as getting a sense as to what the process of drawing up the new customer services strategy might look like. 

Story up to the Customer Services Steering group on 25.02.20

Show and tell #1:


Show and tell #2: