Step back from the problem and think about what “good” looks like

A few weeks ago, I sat down with a Chief Information Officer (CIO) who has a problem. He’s in the middle of a messy “divorce” (professionally, not personally). He is transitioning services from a shared services agreement with another public sector body to a new managed service. His own organisation’s IT maturity is low. There’s an expectation that the new managed services partner will take on everything (except it’s not in a state that is ready to take on). And the shared service provider is both making transition difficult (preserving its revenue stream) whilst ramping up the price to carry on providing services. The divorce metaphor is very apt. 

I was brought in (alongside a colleague with relevant sector experience) to help smooth the pain. I needed to understand what’s holding up the process – why is it so difficult to provide basic information for the managed services provider to take on the service? What are the gaps? How quickly can they be filled? And what is needed to move to the next stage? 

It’s not my usual role, but I’ve been around this industry long enough to be able to take a step back, look at the problem, and try to work out what “good” looks like. 

The challenges

The CIO presented me with two challenges: 

  1. Visibility – of what’s happening. What will be done by when and how far off the target is the transition?
  2. Passiveness – don’t just sit and wait. Bang down some doors and ask for information. If it’s not forthcoming, then flag it. There is no time for delays. 

Searching for a solution

The next day, I was mulling over the issues and I bumped into a friend (on the market in the town where we both live). We went for a coffee, and I told him about my problem (without compromising any confidentiality). My friend has a military background, followed by IT Service Operations and, more recently, security (he’s a Chief Information Security Officer – CISO) so I shouldn’t have been surprised by the advice he gave me. The way he saw it was that there are a bunch of service transition “packages” but the business as usual (BAU) service isn’t complete. Meanwhile the CIO has no visibility and would like to see where things are and the plan for where they will be.

After our conversation my mind was clear. I needed a way to track progress. I wanted a dashboard to tell me the state of each service component or process. Then, the applications, servers and other infrastructure could fall in beneath – but I needed to know there is a service to transition them into. 

There are many problems with dashboards (though the etymology of the word is about protecting riders on carriages from what might be thrown at them from below… so maybe that’s quite appropriate after all). Red/Amber/Green (RAG) statuses can be problematic too (both for cultural reasons and because of accessibility, although that can be overcome with appropriate design). But I didn’t want perfect – I needed functional. At least for the first iteration.

The chosen approach

The Microsoft-focused Solution Architect in me was thinking Power BI but I lacked the skills, time and access to licenses. I needed something that could be developed quickly and updated easily. My initial PowerPoint deck with, “this is what we said we would do”, “This is where we are today” and lots of red, turning amber then green was quickly pushed aside by a colleague in favour of Excel. In fairness, the world runs on Excel – and that’s not necessarily a bad thing. With the addition of a few formulae, some data validation and some conditionally formatted cells, we soon had a dynamic report. It highlights missing information. It highlights support status. It highlights key dates (and missed dates – because I’m also realistic).

Answering the exam question

The summary sheet should answer the CIO’s visibility issue (once it’s securely shared) and constantly pushing for the detail should strike out any perceived inactivity or a lack of initiative.

It’s not innovative, but it is elegant. And it works. 

So I have the tech in place – now for the difficult bit (the part that involves people) – dragging out the missing information to turn cells from red to amber to green. And the good thing is that, based on a meeting yesterday, it feels like there are a bunch of people in the managed services organisation that can see the value and are invested in the solution (they are even adding sheets for extra information – like tracking risks, issues and dependencies). That’s half the battle. “All” I need now is to get the various projects that hold the information on the various applications, servers, etc. to join in.

I may return to this subject with an updated post when everything goes live. Or I may not, for commercial reasons, but here goes… wish me luck! 

Featured image: author’s own.

Not-so-helpful social media “help”

Social media is big business. And almost every major business to consumer (B2C) organisation has at least one account on each of the major social media platforms (at the time of writing, that’s Twitter, Facebook and Instagram but I’m sure it will change over time). 

Unfortunately, there’s a concerning trend starting to emerge – one where the “conversation” is moved to control the brand image. Many brands have set up <brandname>Help accounts for their customer service so that the main brand account is “clean” – pure marketing, untarnished by customers expressing concern about the products and services. Meanwhile, the “Help” account may be operated by a communications agency, simply offering a face and redirecting customers to other channels. 

And that’s where the problem lies. If you want to offer omnichannel support, then you need to meet your customers where they contact you. It’s no good offering “help” on Twitter when all you’re really doing is advising customers to phone your contact centre. That does not help. That’s obfuscation. It’s a blatant attempt to preserve the online image of the brand, whilst offering shoddy customer service. 

So, here’s my plea to brand managers across the UK. If you offer a <brandname>Help account, then make sure it provides real assistance and is not just signposting to another channel. 

I’ll provide an example here, from @KwikFitCS (who responded to my tweet for the main KwikFit account… more on that in a moment), but they are not alone…

Then there’s the issue of the information that <brandname>Help accounts ask for to verify you before they will provide help…

In the example above, @BootsHelp replied to a tweet sent to @BootsUK. And the issue I was reporting was a website problem that was not specific to a single account – the web team could investigate without my personal details. Maybe I should be the one looking for the verification here… not them? That may sound a bit extreme but what’s to stop anyone from setting up a spoof <brandname>Help account and harvesting information from disgruntled customers? (In fairness, the @BootsHelp account has been verified by Twitter, but the @KwikFitCS example earlier was not).

And Boots is not alone – here’s another example from @Morrisons, the UK supermarket chain:

The request went on to a second tweet:

So, come on B2C Twitter. You can do better than this. How about providing some real help from your social media channels? Preferably without requiring a long list of personal details.

Featured image by Biljana Jovanovic from Pixabay.

Failure Demand in action

Recently, my work has involved some analysis of a local authority’s business processes. As part of that I’ve been thinking quite a lot about the concept of “Failure Demand”. For those who are unfamiliar with it, Failure Demand is described by the occupational psychologist and author John Seddon as:

“It is demand caused by a failure to do something or do something right for the customer. Customers come back, making further demands, unnecessarily consuming the organisation’s resources because the service they receive is ineffective. ”

Failure Demand – Vanguard Consulting Ltd

Whilst the Vanguard page is worth a read, there’s another great example of Failure Demand in the “How to break the first rule of Systems Thinking” post from ThinkPurpose.

What does Failure Demand mean in practice?

Any system used to provide a service has a given capacity. To use this efficiently, there is a balance between reducing resources and managing demand.

On the resource side, we can look at how resources are used:

  • Do we have the right people and skills?
  • Are they motivated and focused?
  • Are processes efficient?
  • How is IT used?
  • Can self-service help?

When it comes to demand, the first question to ask is not be how effective the use of resources is. We should really ask are they doing the right thing? Does it meet the customer need?

If it doesn’t then there will be repeat contacts, often relating to Failure Demand – where the volume of work is increased by managing incidents of failure within a process. Examples of Failure Demand include “you’ve sent the wrong item” or “the person didn’t meet the agreed appointment”.

It often takes longer to put something right than to get it right first time. An organisation can implement the very best systems but if it doesn’t meet customer needs in will fail. This is true whether that customer is internal or external; paying for a service or not; client, citizen, traditional “customer” or student. Customers will become frustrated and annoyed that they have repeated contacts to avoid issues. Staff suffer reduced morale as a result of their increased workload.

A real world story of Failure Demand

I spent a good chunk of one day last week working from a car dealership. It doesn’t matter which one… this could have been one of many up and down the country. I also know they are really hot on customer satisfaction. I’d like to make it clear that all of the staff involved were friendly, attentive and did their level best to help me. This is not a complaint, just a true story that helps me explain the Failure Demand concept.

My car is 3 years old, so it was booked in for a service, statutory MOT test, warranty checks, and a quote for an extended warranty.

As the day went on, I saw the Service Manager getting more and more stressed. He wants to do the best he can for his customers but the team is down from 4 to 2 at the moment. That’s going to be tough, but then we layer on the Failure Demand.

At 12:30, my car was nearly ready (it just needed cleaning) and I paid the bill. That was proactive, working to close my account and get me on my way. Great customer service, nothing so far to detract from the outstanding feedback that the dealer hopes to receive (maybe I’ll come back to that in another post).

But I asked about the warranty quote I had requested a week earlier. The person who could deal with that was off work (for understandable personal reasons) but the receptionist who had booked my appointment had assured me it would not be a problem. so, a message was left and someone will call me back after the weekend (Failure Demand 1).

At 13:30, I chased up to see why I was still waiting for my car. It hadn’t been cleaned (Failure Demand 2).

At around 14:00, I got my car back. The service handbook had been stamped and details added for the third service but the second was blank. I always take my car to this dealer, so it must have been missed last year. So the Service Manager looked up the details and added them to the book (Failure Demand 3), once he had found his stamping machine.

By now, I was embarrassed that I kept on going back with “things to fix” and I drove away. As I left, I found that my seat was in the wrong position, the dashboard display was unfamiliar, the doors automatically locked (and much more besides). The profile settings associated with my key were missing!

Having heard the receptionist fielding calls to try and let the Service Department focus on customers who were already in the building, I knew that phoning would not get me an answer any time soon. So, I returned to the dealership to see if the settings were lost for good, or backed up somewhere (Failure Demand 4).

Another Service Manager confirmed that they are not backed up. Some software updates are non-destructive. Others less so. So I left again, disappointed.

Except, as I started the car, my seat moved itself, the dashboard was set up as I expected! My profile had loaded but, presumably the software update had been incomplete before. Now it had finished, everything was back (phew).

Later that day, I received a text message. It contained a link to the video report of the inspection on my car during the service. Nice to have, except I’d authorised the repairs hours previously. Not exactly Failure Demand, but potentially another issue to fix in the process.

So, what’s the answer?

The intention is to move to a position where available system capacity is focused on “Value Demand”. Value Demand is characterised with things that deliver value to the customer or to the organisation, such as provision of information, or just getting it right first time.

If the warranty quote was ready when I paid the bill, the car had been washed when I was told it would be, and the service handbook had been stamped first time then I would have been happy and three items of failure demand could have been avoided. If the Service Manager had known to tell me that software updates might still be taking effect when the car was restarted I might have been less concerned about the missing profile.

The customer would have been happier, the Service Department’s workload would have been lower, and the Service Manager would have been less stressed.

It seems that spotting these issues as a customer is easy… the trick is working out how to fix them in my own work processes…

Featured image: author’s own.