We started this week on a high, with an impressive 37 attendants at our show and tell. That’s a great turnout at such an early stage in the project, thank you to everyone who joined and please continue to do so. These are really valuable sessions, and although feedback so far has been positive we are aware we need to think about how to engage stakeholders a bit more.
Bukky joined us on Tuesday and has cracked on with the analysis of the platform API’s, the existing repairs API and the HACT data model. He has already identified that information relating to a property such as dwelling, description & levelcode could potentially be a candidate for a platform API. He and Evangelos will continue with this research and identifying gaps for new platform API’s or where existing ones could be extended. We’re meeting with the platform API team next week, our work will be closely aligned so not only is this an opportunity to understand their pipeline of work, but also for the teams to meet. There will be a lot of collaboration between us going forward, we think the repairs team will be responsible for identifying platform API needs and the platform API team will deliver on these, though I’m sure it won’t be as black and white as that in reality!
We interviewed the ELA (lift repairs) this week, and found their use really differs from many of the other contractors. The process is very manual, RCC agents raise the repair, take a screenshot, and email it over to the ELA, and if it’s a trapping or something urgent it’s also followed up with a phone call. They don’t pick up jobs from the UH worktray. There’s a whole process after a job has taken place where a list is compiled and emailed over to Hackney to add/check SOR codes, which is then sent back, and only then the administrators go into UH to mark the job as complete. Not only do we need to make this processes easier, we also need to consider each of those individual contracts, what has been agreed in terms of ways of working and whether we’ll need an additional agreement that all contractors will be required to use the hub.
There’s another user group that we’ve yet to talk to, the TMO (tenant managed organisation). The name is a bit of a give away, it’s a group of residents that manage their own repairs and have an agreement with Hackney council with their own cost codes and budget. We know that they use UH so we’ll need to ensure that they are contributing to finding solutions for the new extended hub. There are currently 10 TMO’s and they each manage their own estate, they make up approximately 1/3 of Hackney owned properties so are a large user group with valuable insights we’ll need to capture.
UH dev is still unavailable. It is a priority but the complexity around the recovery means we haven’t been given a timeframe as yet.
Stakeholder engagement is something we need to focus on. The interviews have been really useful, though we are finding varying levels of interest. Workload seems to be one of the biggest blockers, in some areas the person who performs a specific function is solely responsible so any time spent away could have an impact on their day. We will be engaging with the contractor managers next week, plus Paul Fowler is currently putting together a communication strategy for the UH decommission which will also support us in spreading the message on the importance of this project. We’ve got lots of ideas between us, we’re going to put our heads together next week to come up with a strategy.
– Platform API & Unboxed team introduction
– Stakeholder engagement brainstorm session
– Prototype testing with contractors
– Interviews: Finance, TMO, Alphatrack & Axis
– Platform API analysis
– User story writing for the POC