Objective perspective

We’re all sick to the furry little mintballs of hearing the line: “80+% of all transformations fail”. Clearly, transformation isn’t easy, but in IT, we do rather surround major change with an air of always-doomed-from-the-start gloominess. I think we should shift our perspective to be more on the lines of “80+% of transformations stall” – and then have a long hard look at why this is the case. For me, there’s one very clear answer.

I’ve looked at the ways in which transformations can go wrong. Typically, they hit the buffers when:

• They become extremely complicated, with multiple strands all developing at once and competing to be the priority workstream, with nothing being completed due to thousands of demands on capacity

• The senior team gets cold feet at the cost/time it will take/direction of travel

• Sub-teams are developing disconnected standalone projects within the overall programme 

• A catalogue of mission creepage – sometimes going back years – has changed the content of the programme beyond all recognition

• And as for culture… well, it can be broken, bullying, bullish or backbiting…

In some stalled transformations, you’ll see all of the above. By the shedload.

There’s a very simple starting point which will begin to address all the above problems; refocus everyone; and restart the programme.  You just revisit the programme objective.

Successful programmes depend on there being a clearly stated objective. This needs to be simple; agreed, believed and sponsored by the leadership team; and oft repeated.

The programme objective is the yardstick by which any activity is ruled in or out. By making the objective clear and memorable, it becomes the litmus test by which anyone working on the programme can judge whether or not to pursue any particular activity.

So for example, if your programme objective is “to merge two operational systems after an acquisition”, everyone will know what we’re trying to do. Therefore, if only one of the original companies had a CRM system, there’s no excuse for the Marketing Department to try to sneak in a cheeky CRM upgrade - because no merging is required. It’s add-ons like these, the might-as-well-do-it-while-the-bonnet’s-ups, that cause chaos, confusion and creep.

Keep the objective as simply worded as possible: e.g. “to separate”, “to replace” or “to make more secure”. Avoid woolly stuff – e.g. “to enhance customer experience” – because people can make anything fit inside the transformation remit if it’s open to interpretation. You’ll meet people who will argue that upgrading payroll software enhances customer experience, because it frees up capacity in Finance for improved invoice checking!

Most “failed” transformations are just “stalled” or “over-complicated” exercises, and therefore most can be stripped back and restarted. Ignition Transformation’s Blue Light service can bring an objective perspective and support you to get back on track – see more at: