We know what assuming does. It makes an...

Why do we spend so little time validating our assumptions? It’s a behaviour that applies across the board in many organisations, which can torpedo the biggest transformations, in spite of the best intentions.

Before we dive in, let’s take a minute to pause and ask ourselves, why is it so important that we follow up on and validate our assumptions? The short answer, is that it helps us to identify the real challenges requiring attention within our organisations, rather than the perceived problems that can often build up a head of steam and take us down a rabbit hole from which we may never emerge.

We can walk straight into some generic, yet meaningful, examples here. The negative impact of these will be all too familiar with many readers of this article.

‘Silver bullet’ technical transformations built around perceived infrastructure issues that fail to look at the wider Organisational Structure and Operating Models. Large-scale Data Programmes built on the premise that users will automatically adopt and seamlessly slide into using new data structures and platforms. Significant delays to delivery as a result of unvalidated assumptions around technology, hand-offs or roles and responsibilities.

How do we go about overcoming these problems? If we accept that the assumptions we make, drive the key behaviours, which (ultimately) determine our outcomes, we’d be remiss not to proactively validate our assumptions. At the earliest opportunity.

Let’s take a positive example to bring this hypothesis to life. We’ve embarked on an engagement in a large function, within a multi-national organisation. The current application is struggling to process data. This is costly and is causing significant delays to time to market. Our task is to replace the existing platform to ensure the organisation meets reporting deadlines.

Sounds simple. Replace the existing platform. Reduce costs and time to market. Let’s get to work.

Before we race off, let’s stand back and take some of our own advice. Let’s validate the assumption we have been given here, which is, “the application is the reason the organisation is slow in getting to market”.

If we dig a bit deeper we might ask about the Operating Model. In this case, there is no documented Operating Model. Is this our first red flag?

Next, we might ask about the Data. How is it structured and how does it flow inside and outside of the application? In this case we learn that there are multiple transformations of data with thousands of associated rules. Could this be our second red flag?

After a short voyage of discovery, we’re already starting to think about things a little differently. Are delays to market the result of an undocumented and poorly understood Operating Model? Can we simplify the data journey and reduce the industry and complexity associated with the rules?

If we make changes on the above, will this meet our criteria for success? In this example, yes. We can document and implement the Operating Model to expedite the end to end process. We can also make changes to our Master Data to significantly reduce the requirement for multiple data transformations and adjustments.

Do we still need to replace the existing platform? Not necessarily, given the work we have completed. The business case for this is certainly not as strong as was first assumed.

Our simple approach to validating assumptions has enabled us to proactively identify the real issues at play here, saving the organisation time and money whilst providing the competitive edge required with a quicker time to market.

Get validating!

For more help and information on this article and the services we offer, contact us at info@verander.co.uk