skip to Main Content

Why do so many organisations go through initiatives to make many small changes and then give up?

Well, the fact they are initiatives, not a way of life, doesn’t help, neither does a lack of money or time. And frankly, who truly believes we can transform the sales order process (to name but one) with a number of small measures?

So, we muddle along, and then we transform. But that doesn’t work either. Transformation projects run late, they design in exceptions, they plan mop-ups, and the benefits just don’t materialise. Transforming a process that is inefficient or produces poor quality is like sowing grass seed without first pulling up weeds.

The inefficiencies of the old process are mixed up with value added activities; people will resist change that doesn’t recognise and addresses poor working practices. [for example, if the current system produces a report that someone then has to hack about – don’t duplicate the report]

The inefficiencies of the old process throw up risks and issues that shouldn’t exist, ignoring these obstacles always bites the transformation team in the tenders. [for example, the dispatch team must keep the obsolete printer in the corner because they use perforated paper for shipping documents, so it has to be network connected]

Working from a helicopter, the 30,000-foot view, rides roughshod over the hidden requirements of a process, which may be undocumented or fail to reflect written processes. [for example, an Excel macro that converts data to meet a specific, out of process, contractual customer requirement]

Transform often means automation, and anything computer driven is unforgiving of variation. Every discrepancy found during the design phase adds to the pile of change requests. [search on-line for ‘IT project horror stories’ and pick your own favourite example]

Ideally, before a pure transformation project starts, we have:

  • Established consistency – everyone does it the same way, every time
  • Built in efficiency – waste is removed, be that a report no-one reads or reducing rework
  • Used data to set goals for the transformation project

But so few organisations work this way, so do we have to delay a project to sort out and measure the existing process? No, while establishing a solid process baseline goes a long way to guaranteeing the success of a transformation project, you would be spending money on something you plan to throw away. I would suggest that we must approach transformation in a different way. We need to drop the belief that 80% is good enough and set up (don’t roll your eyes, you do it quickly and cost effectively if you set out with the right intentions):

A transformation process that takes the time to listen and to understand what actually happens in an organisation and why.

A system design team that works with the organisation to turn this understanding into requirements (including an agreed operating process: inputs, output and action) and communications.

An implementation team that tests the new system with real people, be it a pilot or a sandpit, and incorporates lessons back into the system design/ roll out plan.

A resolution team that puts the organisation first, analyses issues and feeds back into the design of the system or implementation.

It takes a lot of guts to do a project this way, it starts slowly and deals with detail. It is so much more exciting to take the approach of the hare. Dive in, firefight our way to the end and then let someone else plan the remediation programme. However, the hare can be overtaken and so can transformation projects that target inefficient activities without a sound change methodology.

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back To Top