Digital transformation is just business change. There – said it. It is, though. It just uses other words to describe the same thing we’ve always done – badly mostly, and to be fair a lot of “digital” is done badly, too.
The clue is in the first word – business. It is, or rather should be, business driven. And by “business”, that means all aspects of business, not just some director of XY&Z.
Too often though, digital has become yet another excuse to chase buzzwords – big data, artificial intelligence (AI), blockchain and all the others. And it continues in many cases to be driven by a desire to use the latest technological whizzbang and then shoehorn in a notional business problem.
The myriad technological offerings on the menu has many teams salivating at the endless possibilities to explore new horizons, which can be diametrically opposed to the job at hand – namely, fixing a business problem.
Exploration has its purpose, most pertinently in taking the business problem and proving the solution – big data being a classic example. How often do organisations do big data because the industry says you have to do big data, but without ever contemplating what they actually want to do with this new-fangled data lake other than swim in it?
What about actually proving the value from correlation of, and relationships between, data assets in any way shape or form and then maybe defining the analytical stack that underpins it, ontologies, data models et al; all prior to deciding the technology, be it Hadoop or whatever?
If you do not start with a succinct business problem, you’re most likely going to deliver a digital lemon. Sorry, but that’s the way it always has been and always will be. With that comes the need to have the business at the heart of that discussion, while also keeping them honest.
Too often, digital teams dictate answers, in the self-same way that IT always knew better than the business what the business needs. This happens mainly because the business “doesn’t know what it wants”, or rather they’ve not clarified their requirements through proper engagement to identify the real business driver and problem to solve.
You cannot jump into “solutioneering” without actually knowing what the hell it is you’re solving with such a solution. You just end up in the age-old tradition of the tail wagging the dog, and that way, lemons reside.
Even if you can fail fast, if you’ve not truly explored the problem to understand it fully, you’ll continue to fail, even if you deliver. Hey, you might get lucky, but I’ll bet my bottom dollar that most deliveries would come in very handy on pancake day.
Digital teams often meander off-track to deliver what they think the business needs without remaining true to the business problem – which is no different to what IT change has been doing really badly for years. This often leads to delivering digital-laden buzzwords like big data, without actually proving an outcome and respective business worth first. It’s OK, though – you’ve ticked off big data on somebody’s CV, so it’s all good.
It costs a fortune for almost zero business benefit, you’ve not retired the old data warehouses yet, and now you’ve got double of everything and no idea what to do with it – but it’s all good. There is no use in building it and then figuring out what you’re going to use it for.
This isn’t only true of big data, it rings true for any solution. The problem always comes first, otherwise you may as well become a supplier. You’ll at least have a better marketing team for your lemons.
The CV point is somewhat tongue-in-cheek, but look at your CIO or CDO, and see what their career history is. If they move every two or three years, they are very unlikely to still be in situ when the delivery hits business operation.
As such, will they care if it is slightly citrusy as it is no longer their problem? Surely there are no actual CIOs who just want to appear to do digital transformation, and every other buzzword, in order to get the next gig. Are there?
Bring people together
Put simply, if you try to boil the ocean without first proving you can heat up a small section of water, then in all likelihood you’ll fail. It is so common to see teams jump into delivery without first having explored whether the problem actually exists, its priority and whether the notional solution actually does solve the problem.
It doesn’t matter which methodology you use – you’ll fail. And you’re unlikely to “fail fast” because you set your goals way too high without defining and proving, or disproving, a hypothesis first, and sold it as the answer. Failing in overall delivery is a hard pill to swallow. You’re admitting mistakes to your customer.
But think of it this way – would you as a customer prefer someone that admitted their mistakes quickly before re-engaging, or someone that just ploughed on burning money to ultimately fail at the great expense of time, materials and money?
It’s not that business change – sorry, digital transformation – needs a massive layer of governance plonked on top; just an element of common sense before jumping into code or hyper-scaled, cloud-brokered lemons.
Oh, and do bring your security teams into the change from the outset. They’re a pain and you’ll probably have to drag them out of their ivory tower kicking and screaming, but they can help, or, rather, you can help them. And in fact you can use your business/digital transformation to unblock the ineffective blockers they’ve been implementing in isolation over the years for more effective and business-empathetic risk mitigations.
Most of all, it is about bringing people together. Defining problems. Finding notional solutions. Proving, delivering and improving. Or you could just implement AI and it’ll do it for you.