Mind the gap, (ignore the chasm)

Mind the gap, (ignore the chasm)

by mnewman, June 1, 2016

On joining a running programme or project one of your first actions as the incoming consultant is to get hold of the case for change and check for chasms. Surprisingly for such a large object, they tend to hide themselves in plain sight.

Bridges

 

The case for that new IT system might be a project initiation document, it might be a PowerPoint, it might even be an actual business case. Go find it. If you have a project currently, go grab the one you have. We need to check for chasms. What does a chasm look like? Let’s check some manageable examples using what, why, result:

  • What: an end-to-end order system. [One of the] Why: Account managers currently have no visibility of order status. Result: Customers get forewarning of problems with their order, increasing customer sat.

Did you see it? No? Maybe? Let’s try another

  • What: Dashboard for process as input to governance Why: No visibility into current performance. Result: Performance improvements for process estimated at x%

If you didn’t see it, just add the word ‘how’. Not “how are we going to implement this?” but “how does the ‘what’ realise the result?” Even if there is already a ‘how’ (likely filled-out with the former). Do it out loud.  If the answer has any of the following words or phrases: enables, allows, people will, team ABC will, helps, should, would, could or similar; you’ve just jumped a chasm. You’ve made assumptions.

Don’t panic, it’s deceptively easy to make this error. There are two effects at work here. First the IKEA effect, where we misattribute more value to things we had to assemble ourselves and assume others agree. Second is a need to place oneself in the role of ‘user’ to check whether the tool is capable of providing the benefits, only assuming behaviours in oneself that will help reach the goals and then assuming that everyone will act in the same way (they won’t).

The results of this exercise is the description of the people change. People will argue that they have already specified this: “We’ve got training on the new system/process/tooling. We’ve got awareness sessions and demonstrations”. These are all excellent initiatives, but they all address the delivery of the ‘what’, they don’t close the gap between delivery of capability and leverage of that capability.

Get the thinking straight at this point and the rest becomes a lot easier. That frightening list of stakeholders makes more sense. The need for more than a project update newsletter becomes self-evident. The impact analysis starts to form itself and asks to be filled-in. Tips:

  • Get in early and challenge the thinking
  • Don’t be dissuaded by “I think you’re over-doing it” (but don’t overdo it)
  • Use metaphors, stories, examples to demonstrate that you just can’t take people’s acceptance and action for granted
  • Start the ball rolling and use the lightbulb moment of realisation to start the rest of the change journey.

On the lightbulb moment. It’s actually an event you can witness. Your sponsor will go from “the challenge is the tool delivery” to “uh-oh” to “OK, he/she (you) anticipated this and has it covered”. So the last tip:

  • Be ready to give comfort when people start to look nervous: you know how to work this. No-one likes a heap of new problems with no solutions.

Let the case for change go through without the people change, and you’ll be fighting for the rest of the project. Grab the bull by the horns. Do it.

 

No Comments


    Leave a Reply

    Your email address will not be published Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *