“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?