Written by Guy Whitfield
This week, a week of project introspection, we followed up on our recent backlog curation with an exercise in extracting all the higher level epics and turning them in business beneficial themes that can be used to inform the business case for Manage Arrears.
We spent time collectively carrying out a similar exercise on the results from the Priority Scoring workshop/round table that we held with the Income Collection team – we’ve taken the 17 different requirements from the team and created a living document in which we’re able to concisely describe the conditions which affect a tenants case relating to the weighting that that case should have in an income Agents Work tray.
A similar exercise was undertaken at the inception of this project with the results informing and algorithm which automates current income Office case assignment in our app. What we can see from the Income Collection teams desires for their worktray and the results of the already in place via our algorithm is that there is a lot of overlap – this is a good thing. It signifies that in our next phase as we hone the user experience for the application, it’s not so much the opinions of a team or a robot that are tilted in either direction – they largely agree with each other – its the manner in which that agreement is surfaced and presented. Challenge accepted!
We met with out Product Owner this week and spoke about our findings, it’s the start of a new relationship so we’re keen to be as transparent an open with him. He was accepting and interested. He’s obviously keen to see that where we take the next phase reflects good value both for our residents but also fiscally. With that in mind we’ll be helping to put forward our identified themes and benefits as something which we can use to base the business case for the next phase on.
Finally, a sting in the tail. Our internal users in the Leasehold team used the app this week to send letters, so far so good you might think. In recent weeks we’ve reported how well this is going. This week something different happened though. We noticed that instead of being processed by Gov Notify the next day our letters weren’t processed. We ran some diagnostics and discovered one variant of our letters was being processed and stored by our app but was not being sent through the external service. The signifier was our callback to Gov Notify status. We have visibility in the app of this for exactly this reason.
It would of course all come together on a Friday, hence the lateness of this Week Note submission (Sorry Rob). Through a combined effort with the Leasehold team, Third-party developers, our own API team and confirmation from the team at Gov notify, we have uncovered a missing identifier in one of our legacy systems. We’ve raised a ticket for the relevant fix with our ICT team, but given it’s late on a Friday the fix will have to wait until next week. We will work to ensure we restore happiness and trust with our internal stakeholders next week.
The fault wasn’t in our app, but the issue directly impinged our internal users with that in mind we have noted some learnings around dependencies and the need for inter-team collaboration since we’re beginning to use at LBH the PAAS (Platform as a service) model. As the output of our teams become less standalone and more integrated then the need to consider dependencies is vital.
Why highlight it here? We firmly believe in the core values of transparency and openness. Sharing our experiences and learnings it good for the wider audience if occasionally painful for the team.
We’ll work with Leasehold to ensure all relevant letters are correctly sent. We’re also taking part in a deep dive on Manage Arrears with senior stakeholders from both Housing and ICT and all involved teams. We have also promised a draft business case to discuss with our Product Owner later in the week.