At Bromford we are kicking off a new programme of transformation - entitled Bromford 2.0.

Aren't large scale initiatives everything our small but perfectly formed innovation lab should be fighting against?

Transformation programmes are mostly linear, planned, time-framed, well resourced. Almost the exact opposite of us.

We’ve personally had no success parachuting programmes into the business, for a number of reasons I'll save for another post.

What has worked is getting in the trenches and scrapping - tackling very specific challenges in new innovative ways and using the momentum of success to roll out similar work across previously disengaged teams. The potential gains here are huge, if only considered incremental compared to the Bromford 2.0 scale of change.

So can these two radically different schools of thought peacefully co-exist, or are we destined to quarrel until the smaller of the two (that’d be us, by a considerable margin…) simply evaporates off the scene?

I think we can - if we can learn the lessons of big programmes past.


When I was brand new to Bromford the ‘Customer Portal’ was all the rage. This online tool would allow customers to engage with us in revolutionary new ways - as well as monitor all aspects of their tenancy such as pay their rent or report repairs. In turn, we’d get loads of good data back about how we communicate and engage with customers so that we can improve the efficiency of all of our services. Considering where we were at technically, it was a brave and bold programme.

As it thundered along, gaining attention, it became obvious that this tool would solve a number of problems we (read: our systems/data teams) were already busy working on. Big, time-consuming problems - we’re talking about 6 month projects and then some.

So, as a business, we iced lots of them.

I personally used the line “That should be helped when the customer portal arrives” a number of times to rebuff lots of high-workload ideas that simply seemed pointless if a new, better, more incorporated solution was on its way.

Only thing is -  it never did, did it...

It stalled. 


Now, I’m pretty neutral on why, how or when projects run into the ground. It’s not our show, and the same circumstances could probably have happened to anyone, at any point.

In hindsight, I’m less neutral about the drive to down tools, self-directed or otherwise, on all short term solutions that fell under the same area. We couldn’t have known the outcome of the big project, but we stalled months worth of work in some areas, for basically no reason.

Back to the present day, warning bells went off when we started hearing “Why are we doing this over here [innovation] when 2.0 will take care of it?”. Wait - we’ve been here before!

I’m not naive, I get the irony of a programme established for driving efficiency, running alongside lots of smaller, very similar, grass-roots projects also established for driving efficiency. It screams duplication.... and inefficiency.

But instead of thinking of them as competitive activities - how about we think of these other activities as streams of information or learning, that we can tap into to really design the 2.0 solution well? Because that’s what they are.

For example - my work alongside our Repairs Support and Surveyor teams is on the surface, pretty narrowly focused on improving our approach to handling, now often proactively, recurrent customer enquiries, but zoom out and you’ll see the bigger picture of benefits:

  • A redesigned process that clusters outcomes into categories - with clear accountability and communication across each escalation
  • A means of digitally collecting previously paper-based surveys to reduce waste, and provide whole swathes of information for reporting/monitoring that were previously unavailable
  • Building technical measurements about the home (temp, humidity, surface moisture) into the surveys, so the surveyors have sound evidence to justify their decisions
  • Automated data handling & storing by office based colleagues
  • Prototype PowerBi report that collates information into one place along side call data and complaints reviews.
  • Triage support to ensure small problems are handled quickly during implementation

We’ve roughed our way to these outcomes using non-approved software, and previously untested ways of doing things because we’ve been given the freedom to redesign the service to what works best, not what we can offer through our existing systems. The service therefore, suffers far fewer compromises.  

With 2.0 redefining all of our core system requirements, this work could be construed as fundamentally pointless, but it’s not. Firstly, it’s a great temporary solution that avoids complexity of major system changes. Secondly, it should inform the redefining, in order to allow other teams to capitalise on similar advantages.

Already this approach has proved favourable with our colleagues (almost to the point where I’ve become a professional form builder!), and the waves are rippling out, enticing more people to have a go.

Progress.

So this may be the true value of innovation within the business; to ensure projects and work streams continue unbeleaguered by the shadows of bigger, more glamorous programmes - transformation or otherwise. A protective shield around continuous improvement and a means to embed new approaches, thinking or technology.

If we can achieve the right balance, the uneasy peace between the way innovation and transformation programmes have been run will be replaced by useful collaboration.

No pressure then. Let's get to it. 

@ThomasHarland

Comment