IT and Improvement

Bruce_the_Shark_by_hayn“Asking a consultant if you should….put in a new computer system is like asking a hungry Great White Shark if the water is warm and you should go for a swim.” (Seddon quoting Craig, D and Brooks, R)

We all know about the wonders that can be achieved through technology…we also know the massive pain that we can suffer from trying to jump on/ implement the next ‘big thing’.

Another quote that fits well in this space:

“IT marketing is more hyped than next season’s fashion colours and the MTV awards combined.” (Unsourced)

John Seddon contends that the problem with IT is with the way we approach it, this being something like:

  • We see some potential ‘holy grail’ dangled in front of us that seems to play to our symptoms;
  • We write some specification of what we think we need/ how we might use the ‘shiny new thing’;
  • The IT provider then takes this, re-writes it in their own version (a straight jacket if you will) and then delivers against this;
  • …which then fails to deliver against our actual reality (which only now we begin to properly understand…but this is now too late);
  • …so the supplier blames our original specification;
  • …and succeeds in selling more ‘implementation consultancy’ to ostensibly ‘put matters right’ or, at the risk of being cynical, ties us further into the abyss of their technology.

Seddon proposes that our approach should be to “understand and improve – then ask if IT can further improve.”

  • Understand: Ignore IT. Do not even assume the problem, or solution, has anything to do with IT. Instead, work first to understand the ‘what’ and ‘why’ of current performance as a system…which means learning about demand, capability, flow, waste…and the underlying causes of waste;
  • Improve: Improve performance without using IT to do so. If you currently use IT, either leave it in place or work without it. Now, improve doesn’t just mean the process…it very often means the management system surrounding it;
  • Ask ‘can IT further improve this system?’: It is only now that you can address the benefits that potential IT counter-measures can bring because you are asking from a true position of knowledge about the work. This is IT being ‘pulled’ into the work rather than dictating the method (“the way the work works”).

And, throughout all of the above, we should be measuring the capability of the system against its purpose (from the customers’ point of view) and can then consider whether each change in method (including the use of IT) has in fact been an improvement.

Now, an obvious chicken-and-egg question arises here: ‘…but don’t I first need IT to measure capability?’. A couple of thoughts in reply:

  • You don’t need IT to capture the demand trigger point and its satisfaction point….though it is likely to make it much easier – the same ‘understand, improve and then ask if IT can further improve’ applies to IT reporting. Before touching IT for reporting, you need to understand what you should be measuring. I have seen most IT implementations deliver a suite of out-of-the box reports that do not measure capability;
  • Even if your IT ‘solution’ delivers you such measures, you need to understand whether they are being distorted by the process performers due to the effects of the management system on their behaviours? …perhaps this needs focus first?

Two parallel tracks

railway-track-leading-into-distanceI get a number of different reactions from people when I discuss organisational ‘systems thinking’ ideas with them. These range:

  • from “wow, that’s so right…but we are completely stuck in our current ‘command-and-control’ reality and surely can’t do anything about it!” ;
  • to “we need change and I can’t wait around for your theory to come to fruition – I’m going to accept things as they are and tinker at the edges as best I can…otherwise I will go mad with frustration!”.

To quote Russell Ackoff: the later response above is basically trying to make a “wrong thing righter” or, in effect, limit the damage.

However, I am very mindful that people can’t feast on ideas alone and that the point is to improve. All the theory in the world won’t help if we can’t apply it.

I have pondered this dilemma a lot and often…and came across (what is to me) a profound answer to this dilemma, as written by Alfie Kohn:

“When something is wrong with the present system, you move on two tracks at once.

  • You do what you can within the confines of the current structure, trying to minimise its harm.
  •  You also work with others to try to change that structure, conscious that nothing dramatic may happen for a very long time.

If we move exclusively on the latter track, such as by mobilising people to dismantle [the destructive instruments of the] system, we may not be doing enough to protect [our colleagues] from the destructive effects [of these instruments] with which they are going to be controlled in the meantime.

But – and this point can be more difficult to recognise – if we simply reconcile ourselves to the status quo and spend all our time getting our [colleagues] to accommodate themselves to it and play the game, then nothing will change and they will have to do the same with their [colleagues and on and on].

As someone once said, realism corrupts; absolute realism corrupts absolutely.”

So, we need to simultaneously travel along two tracks.

We need to accept that our progress along the (truly) transformational track of changing our management system will take time….but we MUST start and sustain this journey (i.e. not see it as an impossibility) whilst also doing what we can within our current daily realities. We can only do this if you and I continue to think, collaborate and learn….which, I suggest, may be intrinsically motivating for us and give us a clearer sense of purpose.