Value, Urgency and Organisational “Maturity”

When people hear about Cost of Delay they sometimes doubt whether their organisation is ready for it. They say things like, “We don’t have the maturity for it”, or “We couldn’t do that because our stakeholders wouldn’t support it”. This hypothesis, that the organisation isn’t ready, is a common response to a lot of ideas about improving the way organisations work. I wanted to say a few words about this, from my experience. As always, your mileage may vary…

The organisational melting pot

In my view, organisational maturity isn’t homogenous. Rarely does an organisation have a single state of “maturity” or culture. Instead, they are somewhat inconsistent. While we tend to anthropomorphise them, organisations are not a person with one face and personality, they are more like many, many, different people, multiple faces and a multiplicity of personalities.

This is true not only for large multi-nationals, (where there are often large differences in culture from one region to another), but even in relatively small companies — between departments, teams and even within a team itself. Some say that culture is set from the top, by the leadership – and to some extent I would agree. In other respects though, I would suggest that culture is really a manifestation of the whole, reflecting and absorbing little bits from everyone in the organisation. And, of course, those bits tend to be quite different. It’s a great, big, fantastic melting pot.

It’s often not as hard as people think

Only a fool says “Don’t go near the water ’til you have learned how to swim.”

A couple of weeks ago I had a case that illustrates this. I’ve been working with an organisation, helping them to deliver more value, faster flow and better quality solutions. One of the areas we’ve spent some time exploring is whether they might want to experiment with using Cost of Delay to improve the way they control demand and prioritise work across a complex stakeholder map. What I found interesting is the different response this generated. On the one hand, there were plenty of people who saw the difficulties of doing this with multiple stakeholders, each of whom effectively “hold the purse strings” and are quite used to treating I.T. as an order-taker. When they don’t get what they want, the typical response is to “escalate”, using hierarchy to push more work onto I.T.

Despite the obvious challenges, there was one person who immediately saw the potential of using Cost of Delay, and gave it a go. After a couple of sessions walking through it, we calculated the Cost of Delay and CD3 scores for a dozen or so regulatory features that were planned for development in the next couple of months. Despite all of the very real challenges, in a very short time we had managed to do a much better job of:

  1. scheduling the features based on more objective value and urgency analysis
  2. transmitting Cost of Delay estimates to the team, helping them make better trade-off decisions, and;
  3. changing the focus of the conversation, from cost and delivery dates, to value and urgency.

Let’s be clear: the point is not to be precise — it is to do better than gut feel, and surface the assumptions we tend to hide in our typically large-batch business cases.

Find one brave soul

The point of the story is to give you some hope. Time and again I have seen people who have had the gumption to give it a go surprised at how relatively simple it turns out to be. You just need to find, encourage and support the one person who is brave enough to give it a try. It’s not like they have to donate an organ – if they don’t like the result, or find it doesn’t help, they can archive it all in the nearest “round file” (or perhaps recycle the paper).

What tends to happen next is the really cool part. Having shown that it is possible, others start to figure out that this might be a way of reducing the “yelling and screaming”, politics, horse-trading and HiPPO handling they usually have to deal with. The impossible has been shown to be possible after all and the once solid defence of “we don’t have the maturity to do this” evaporates as the flimsy excuse it always was. The truth is that maturity comes from experience and to gain experience we have to try new things.

Change where you work

The other thing about organisational maturity is that it’s not a static thing, either. Rather, it is dynamic, always changing, always reacting to new inputs and feedback. Organisations are a complex adaptive social system. In today’s hyper-connected world with global markets and fast-paced technology shifts, organisations are perhaps changing faster than ever before. It would be foolish to dismiss a developing or distressed organisation as being unwilling or incapable of improving itself given the right encouragement and the opportunity to learn.

Age high price maturity

If you are reading this, then I think I can safely assume that you are looking to drive some sort of change in the organisation where you work. We are change agents. We perturb the system (sometimes in a slightly painful way) in an attempt to improve the whole. And, we tend to be impatient about it. We see the value of working in a different way, and we know that it matters and that it is urgent. Since when did we sit around waiting for all the pieces in the puzzle to line up?? Not trying new things is a sure way of achieving permanence of immaturity. Kent Beck tweeted a picture of a poster at Facebook the other day which summed this up nicely: “Nothing at Facebook is someone else’s problem”.

The time to get started with Cost of Delay, or any other continuous improvement idea is “yesterday”.  What are you waiting for?

As I said earlier, YMMV. This is just my view, based on my experience. I’d be interested to hear thoughts others have on this subject.

Comments 2

  1. Pingback: How mature must an organisation be to implement Cost of Delay. | The IT Risk Manager

  2. Pingback: Fixed mindset and patterns of resistance - Black Swan Farming

Leave a Reply

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