What a Modeling Lead Needs part 2 – Fear

Peter Harrad explains why a modeling lead needs to point to the fear factor - the possibility of future risk reduction to ensure modeling initiative success

Related Articles

Sign up to our newsletter

Thank you for filling out our form. Loading animation

Part 2: A Modeling Lead Needs Fear

Last time I was cynical and described how most guides to setting up a modeling practice ignore the need to remind executives of the pain that the organization is experiencing, through horror stories of past problems. Now I'm going to talk about how important it is to think about problems still to come.

In the years that I’ve been working with organizations that are setting up modeling practices, I’ve had to come to terms with the fact that a least 50% of initiatives get cancelled, often before they even get started. Simply put, the business case is not accepted. Modeling and analysis ends up being seen as a ‘nice to have’, and other initiatives take priority.

Why though? Often the executive suite understands what the modeling team can achieve, they just see other efforts as more important. And often it's because the cheerleader for modeling and analysis is too optimistic.

It's the nature of a team lead, an advocate, to be optimistic – they present what an enterprise modeling effort can enable. Better communication. Business transformation. Business agility. Reduced operating costs.

There's a couple of things that all of these have in common – they are uncertain, they are hard to measure, and they are dependent on internal buy-in. Any executive worth their salt heavily discounts the value on all these three factors – they're just too uncertain. Executives hear promises of fantastic things that will happen all the time. They spend the rest of their time dealing with problems and disasters. These are tangible, and the sad truth is, this is what occupies their day, and their attention.

So while better communication, business transformation, business agility and so on are all valid reasons for modeling, the case for modeling should reference the other payoff that it provides – risk reduction.

The risk of data breaches. The risk of regulatory non-compliance. The risk of failed product launches. The risk that the spinoff of a division will fall through because no-one knows which systems the division depends on, and it takes too much time to investigate (this was a concern when Ford sold Jaguar Land Rover).

So – risk reduction is likely to be the point that resonates, rightly or wrongly.

 

In closing this post, I want to consider what you can do to identify the risks that you propose to reduce. The first question is, where to find these risks?

If you've been at the organization for a while, then it's likely you already know what the risks are that keep the CIO up at night. For example, a healthcare insurer will worry about HIPAA compliance. But what if you're newly hired in?

The best source is likely to be the risk registers for previous large projects. It's possible that the organization will have their own living risk register – but in my experience, best not to bet on it.

The second consideration to apply, though, is to seriously question which of these risks your modeling effort can realistically help. For each one, try to create the elevator statement that expresses how modeling will address this (in case any reader is not familiar with the concept, the elevator statement is the one or two sentences you speak to someone explaining your case while sharing an elevator with them).

This might sound trite – to reduce the complexity and effort involved to a couple of sentences? The important point is to boil it down to the point that a busy executive can 'get it'. If you can point to a similar organization that has been bitten by this risk in the past, so much the better – see my previous post on the value of war stories.

There's enough literature out there on how people focus on resolving the downside before they focus on the upside. In Maslow's hierarchy of needs, the safety rung is number 2, self-actualization is rung 5.

There's even a sales methodology on leveraging pain points – SPIN (Situation-Problem-Implication-Need), which revolves around getting people to state their issue and then encourage them to dwell on all the issues that the problem causes.

 

It’s human nature to focus on the immediate and the negatives. While it might seem manipulative to adapt to that, highlighting the risk reduction aspect of a modeling initiative can easily be the difference between approval to move forward and a de facto permanent postponement of the idea.

Are you ready to
architect your digital future?

Book a Demo