Many companies have embarked on a Digital Transformation strategy in recent years. Most business leaders would agree that the only way to survive in the new, digital, world is to embrace it. Unfortunately many of these initiatives either fail outright or, at the very least, fail to deliver the anticipated business outcomes.

There can be any number of reasons for this but a few of those reasons present so consistently that we can safely call them The Usual Suspects. 

Bespoke Code Solutions

The most common mistake when approaching Digital Transformation is thinking your internal IT team of Web or Java developers can drive this for you. Many IT Directors or CTO’s do this at their peril.

This is not because your team is incompetent or lacking in skill. It is because a bespoke, or custom, code solution will simply take too long and be too expensive to produce. What may look like a cheaper option in the short term will actually cost companies dearly in the long term.

Setting aside the fact that internal IT teams already spend 80% of their time just keeping up with current business demands, the scope and complexity of a Digital Transformation is too big to handle with custom code. There is simply too much code to write and too many things to think about or consider. Vital considerations will be missed and the consequences will be dire. Any director who asks this of their team is setting that team up for failure — even a team of rock-star developers. When we ask our internal IT team of bespoke developers to deliver a solution of this magnitude, we simply ask too much.

A prime example of this is a failed project at one of the UK’s leading national broadcasters several years back. When the organisation embarked on its Digital Transformation it adopted a custom-code approach. Four years and two external solution providers later, the organisation was forced to announce publicly that the initiative had failed. Heads rolled and over £100M was wasted. Retrospective analysis cited the ‘custom-code approach’ as one of the most significant factors that contributed to that failure.

It is worth noting that one of this company’s major competitors did the same thing and started at about the same time. They elected to build their solution using Customised Off-The-Shelf (COTS) Products, which included MuleSoft by the way, instead of a bespoke code solution. Around the time that the abovementioned company announced its failed initiative to the press, this competitor’s solution had already been live for over eighteen months. 

hiring rocket scientists to perform brain surgery

This is similar to the above — only this time from the perspective of the resources chosen rather than the technologies selected.

In the publishing industry, experts exhort writers to ‘write what you know’. Of course, this is easy as writers naturally gravitate to what they already know in any case. Developers are the same. If you ask a Java developer how to solve a given problem, they will offer you a Java solution. A C#/.Net developer will recommend a C#/.Net solution. Conversely, a Database Administrator (DBA) might recommend a rich set of SQL Triggers, Functions and Stored Procedures to achieve the same result. We write what we know.

Digital Transformation is broader in nature and, by definition, involves connecting a multitude of different systems. Enter Integration!

Now here is the pitfall; having heeded the first warning above and selected your preferred integration technology (ahem MuleSoft), you might be tempted to let your team of application / data-driven solution architects and developers loose on this new technology. They will attack the problem with gusto and they will design and implement what they know; an Application (or maybe a Data-Driven Solution) — using Mule flows.

They will recognise that the solution is not working; they just won’t understand why.

Nobody will notice the problems at first; those will appear much later — probably too late. But eventually, the cracks will begin to show. Frustrations will build, failures will present (often only in production) and deadlines will start to slip.

In these instances, your team is likely to blame the product, and why wouldn’t they? They will recognise that the solution is not working; they just won’t understand why. From your team’s perspective, the Mule will look like a strange and obstinate beast that flatly refuses to do what is asked of it and often behaves in ways that border on bizarre. Of course, the assessment is unfair.

This is neither the Mule’s fault, nor your team’s fault. I’ll be brutal here; it is management’s fault. When you select a powerful stable of MuleSoft products, you need more than a team of application developers to leverage that power — you need Mule Whisperers.

One final word of caution on this subject. Many an IT director will correctly identify this pitfall and attempt to solve it by sending their team of application developers for training and MuleSoft certification. While this is a big step in the right direction, it is not enough. See my article, The MuleSoft Certificate and the Ninja, to understand why.

Neglecting the human aspect

One of the most neglected  aspects of any transformation, digital or otherwise, is Change Management; or managing basic human nature through the transformation. We cannot drive Digital Transformation without buy-in from those employees who have dedicated years of their life to making a business what it is today.

The main challenge is that most people hate change. We don’t like it when someone forces us to change the way we have always done something. This presents the first hurdle.

Then there is the question of vision. I am reminded of the quote attributed to Henry Ford, ‘If I had asked people what they wanted, they would have said faster horses.’ As a result, visionary leaders often choose to exclude those employees who work at the coal-face in the early phases of a transformation project. The assumption is those employees don’t have the necessary vision to embrace the required transformation. This assumption can be true to varying degrees and presents a second hurdle.

However, if you add to this by making new methods and processes more cumbersome than existing ones for your work-force, your project is doomed from the start. Your employees will find short-cuts and circumvent the process at every turn. Ultimately, this will erode the value of your digital transformation.

Let’s face it; we undertake transformation in order to make life better for our business. This includes its customers and its employees. Why wouldn’t we engage with the employees who use our existing systems and drive our business processes to understand how we can make their lives easier while pursuing business objectives through Digital Transformation?

I have lost count of the number of projects I have worked on where business / technical analysists, architects and designers engaged with stakeholders at management level in the early stages but were kept at arms-length from the employees who physically worked at the coal-face. In fact, all too many projects only engage with the actual workforce as an afterthought when they approach go-live.

It is often at this point that we discover we have missed one or more fundamental aspects of a process or have completely misunderstood how people get their day-to-day work over the line. There is nothing more terrifying for a project team than that moment when they discover everything they were told about the process is wrong.

The result is a solution that is not fit for purpose and which employees will never use because, well  — they need to finish the job and deliver their managers’ and customers’ expectations. And as long as the new solution remains a hindrance to that end rather than a help, they will continue to find ways around the problem.

The truth is employees will always take the path of least resistance. Better to build solutions that come in line with that than to forever fight the tide.

I am reminded of the story about a university that spent a fortune on landscaping its new campus. The true stroke of genius, however was how they protected their lawns from constant foot traffic. Instead of spending a fortune building the pathways along which students should walk, they opened the campus up — and left the students to find the most convenient routes around campus. Within a few weeks, or months, the grass became damaged as ugly compacted pathways began to appear on their pristine lawns as a result of natural foot-fall. 

Once the those lawn areas were properly destroyed and the pathways well-established, they brought the contractors back in and built beautiful pathways over the ugly ones that the students had already ‘created’. After that, their lawns remained forever pristine with minimal effort because they had first understood how the students moved around campus and then worked with them to create beautiful pathways on the routes they had already defined.