Why do some transformations fail?
Transforming an inefficient or poor quality process is like sowing grass without weeding first.
People resist change that fails to recognise and address true working practices. For example, if the current system produces a list that someone has to hack about – don’t duplicate the report.
Ignoring obstacles always bites the change team in the tenders. For example, dispatch must keep the obsolete printer in the corner because they use perforated paper for shipping documents. So it has to be network connected.
Taking the 30,000-foot view hides important detail. For example, an Excel macro that meets an out-of-process, contractual customer requirement.
Finding these variations during the design phase adds to the pile of change requests. Search on-line for ‘IT project horror stories’ and pick your favourite example.
Ideally, at the beginning of a change project, we have:
- Consistency – everyone does it the same way, every time.
- Efficiency – no waste be eliminating a report no-one reads or reducing rework.
- Goals for the project – covering outcome and scope.
So, must we delay a project to sort out the existing process? No, establishing a solid baseline could contribute to the success of a change project. But you would spend money on something you plan to throw away. I suggest we take a different approach to transformation. Let’s:
- Understand what people do and why.
- Work with the organisation to build requirements.
- Tell people what is happening and listen to their response.
- Test with real people and incorporate lessons into the solution and roll out plan.
- Put the organisation first, analyse issues and prevent re-occurrence.
It takes a lot of guts to run a project this way. It starts slowly and deals with detail. Would you rather take the approach of the hare? Dive in, firefight to the end, then repeat on the remediation programme. Remember, the hare can be overtaken and so can transformation projects without a sound change method.