This is a discussion about Digital transformation that addresses mostly the approach to delivering transformation and the rationale and drivers, but I have stayed away from some very important themes such as how to develop strategies for tomorrow, how to prepare an organisation or the change and how to lead the organisation into a new future.
This article was prompted by repeatedly reading very poor advice published by world leading Management Consultancies describing how to go about delivering Digital Transformation from a technical viewpoint. Above all, what I learned from this exercise is that it is good to have broad knowledge, but it is wise to stick to advising on what you know at real depth.
Some short but inevitable background
The narrative has become old, boring and shocking in it’s apparent inability to learn any real lessons at all. The first Chaos report appeared in the 1970s. Shock horror these fellows in with the new-computer technology that threatens our jobs are not delivering, the end if the world is surely nigh. Luckily for Granddad, there was no Facebook or Linkedin to blow this sad little tale into a hurricane of “bovine faecosulosis”.
The dot com boom through the nineties gave grist to their mills as we built Amazon and Google plus thousands of revolutionary new businesses that disrupted the status quo and the transformation of our world crept into view stealthily while the “experts” were looking somewhere else and dreaming about the past as too many of them still appear to be.
During all of the dot.com boom we were assaulted with a repeat of the same old mantras about projects failing and poor planning and wrong skillsets and the whole sad boring story all over again. All the time though, good projects were started and they transformed industries and closed down slow movers acting quietly and efficiently with an inevitability that would have been sending out chills if anyone was awake.
Out of this indignant tide of complaints the ”Agile boys” had a field-day dreaming up a new religion that would fool the developers into thinking they were in charge of the product at last, while fooling the old school into believing they were micro-managing these ”overpaid techies” at last, for at least ten minutes a day, and the cycle went round again.
Now it is no longer “dot com”, it has a new name “Digital Transformation”. You’ll never guess what Digital Transformation means, well, it is about building digital businesses to disrupt old fashioned ones. I wonder who thought of that?
Rant over here is the useful stuff and it is worth reading to the end, I promise you
To truly appreciate the division that exists between views of what Digital transformation means, you have to look at this from different viewpoints. I have chosen the more prevalent points of view, but you may be entirely right in asserting that I have ignored a much more important one. The most important lesson is that there is more than one point of view and all of these viewpoints matter in one way or another.
Here is what Digital Transformation is not and never was, though I am not pouring water over anyone involved in these activities. Digital transformation is not smartening up the website a bit and being a bit more digital. Is it not giving someone responsibility to send a few tweets every day on your behalf. It is not replacing the card index with a CRM and it is not moving your data from a perfectly good server to a perfectly good cloud server. All of these activities and long of list of similar activities of a digital nature may well be valid for a great many people and I am not knocking this, what I am saying is that these activities do not amount to digital transformation.
So what does count as digital transformation then?
Digital transformation is a revolution in the way we think about making, buying, selling and distributing goods and providing services, in the way we communicate and in the way we govern ourselves.
When steam replaced the horse, it took a long time for the last cowboy to leave the cattle drives and the last barge to give up the canals.
Steam engines and later diesel engines transformed our world. They were not a slight change in the way we get stuff form A to B, but a change in mindset. First the definition of A and B were able to change. Instead of being a journey of many weeks from London to Manchester or many months from Wyoming to New York, it became a matter of days and then in some cases hours. The belief that we can move goods across the country and across the globe swiftly opened other minds to the potential for freezing food stuffs and the whole dynamic changed again. It didn’t stop until Henry Ford was transporting individuals around the country in their own private mechanical carriages and it hasn’t quite finished yet.
When I built my first eCommerce site in 1997 for the client of an advertising agency who was my client, I remember explaining to their client’s CEO that in my view this meant the end of the supply chain as we knew it. Why I asked, would anyone give so much of their margin to a middleman when the customer is an email or a website visit away at all times and an automated website can do demonstrations and answer questions. In the end, he won that argument as CEO’s do and five years later I was beginning to doubt myself as the pace of change struggled against the inertia of tradition, but today nobody is in any doubt about who was right. One supply chain after another is disrupted with business models and ideas that circumvent the old cosy relationships and lure the customer into new and more rewarding relationships with usually new and different players.
Unfortunately for many, inertia is more powerful than need and the bright new businesses on the block are rarely transformed older businesses, but start-ups with new capital, new teams and new ideas. Having done both, I can definitely see the lure of a clean slate with no baggage and no resistance. In my experience, I encountered just as many who failed because of moving too soon as I know dinosaurs waiting for the grave. It is not easy to get this right, but it is not optional either.
At the time, I was building my first eCommerce, I paid weekly visits to Blockbuster video, but within a couple of years my children were finding their own moves online.
I used to enjoy a few hours in a giant bookshop once in a while as I had done since childhood, but before long I was busy building an online bookshop , soon afterwards the big stores were closing like the collapse of a house of cards. These transformations were no-brainers, so was/is education. Sooner or later Universities will transform or die, the court service as we knew it is all but gone, Google has the health service firmly in their sites with their Deep Mind business, bank branches have closed everywhere, post offices are only there because they refuse to die, but the next generation who have never stood inside a post-office will see the end of them. This list is never ending.
Much more chillingly urgent and pressing is the sudden manifestation of the power of social media to corrupt news and influence politics and the dilution of political influence across national borders. Government are desperately grasping for excuses to justify their existence and survive beside bigger and more wealthy corporations while ignoring the demand being made by the electorate. Politics too must be transformed beyond recognition and soon if we are to avoid catastrophe. The next twenty years will bring a revolution bigger than even the industrial revolution and it may not all be pleasant and rewarding, but it will be an era of tumultuous importance for the world at large.
The question you have to ask yourself is whether your business is going to be a part of the future or another statistic?
Then you need to get the timing right and position your business right. Your strategy needs to put you in the right place at the right time with the right capabilities and the right options open to you. Then you will survive the unknowns and the unexpected that are surely waiting for us all. If you sit back and wait, if you join the uneducated yobs who think they can close borders and bury their heads in the sand you will surely perish.
The latest bright idea from the big five consultancies revolves around using Scrum style methods to
“inspect and adapt” They have read the old chaos reporrts and they have absorbed the complaints about all this wasted money as “Projects Failed” and they concluded that the answer is to give these people a sense of being in charge and an illusion of progress with no danger of failure since success has never been defined anyhow. What a winning combination for a consultant? The client would literally have to accuse himself of ignorance in order to complain about your performance and after all, the ego being what it is, he will be happy enough to celebrate small wins. In truth, it takes no time at all to start seeing small wins as big wins, after all everything is relative.
Don’t misinterpret what I am saying, there is nothing wrong with Scrum used as it was designed, i.e. to deliver a product in a cosy departmental environment and the notion of a product beginning life as an MVP[i] and developing in accordance with customer need is an attractive idea. The problem with this thinking is that unless you are a software engineer and you have worked with scrum for a while you have no idea what any of this really means and no insight into just how far off the mark this thinking usually is and you are leading your client into a quagmire. The blind leading the blind.
1. Launching a product is not digital transformation, it’s a product, however clever it might be.
2. Scrum teams are dominated by techies, don’ believe the stories you hear about the role of Product Owners, they rarely exist, are even less likely to be trained, the training is by techies and when they do exist, they have little or no influence and certainly it is rare that they have the product management background to be capable of launching a winning product let alone a digital transformation.
3. You can’t, I mean You Can not, design an innovative product by asking the customer what he wants. The customer has no idea what he wants or what the other millions you need to impress will want either. Innovative products require innovators with vision and Cahones, People like Bill Gates and Steve Jobs. Can you imagine in your wildest dreams Bill gates asking Mrs Jones what she would like a PC to do? No you can’t because you know, as did he, that she couldn’t imagine herself using a PC, but now she never puts it down. That is innovation. Innovation it is like class, you can’t buy it.
4. Scrum teams take little responsibility. There is no real definition of done and the maintenance of the released functionality gets tangled up in the production of the new, to the point where production gets slower and slower and bugs are more and more and the build of technical debt weighs more and more heavily, the product becomes less and less usable and the never ending project grinds along ever more slowly, each new idea becomes more tricky to approach and the enthusiasm dips lower and lower as these techies remember the shortcuts they took and don’t want to dig up again. For the business, there is no visibility of where the problems really are happening and it simply manifests as a dull lack of progress and lack of enthusiasm. For the techies there’s an easy solution, they move to a new job in a new company where they are saviours cleaning up the mess left behind by those low skilled programmers who left recently and they are back in business. For you there is an impregnable mess with just a sense of “that didn’t go well, but I don’t really know why”. Where do we go now? Let me put your mind at rest, Consultants like me are already cooking up a nice little earner fixing this mess when the fruit is ripe. Just a little bit longer though.
Here is what you have to do to avoid the problems
1. Take responsibility, but admit to being human and admit that this is hard and we are all in it together equally and we will make some mistakes.
2. Develop a strategy and then rework it so there are plenty of options and plenty of outs and you have minimized the risk of wasted effort and rework, but you accept that some is inevitable. Tools and models for strategy development are beyond the scope of this article, but there is an abundance of advice and help to be found.
3. Once the business model and high-level business architecture is understood, or at least a course of “plan, do, check, adjust” that will get you there,Hire the best solution architect you can find to work with the tech team and come up with an architecture that will support changes of direction and innovation and will provide flexibility without being overly punitive and will fit their skills and strengths and then get them agree some sound architectural principals and some solid QA procedures to keep the architecture on track.
That not so small piece of work will ensure you avoid the cul-de-sac traps and make everything you do quicker and easier for the foreseeable future as long as you remain vigilant.
4. Plan out the new future vision and plan the validations and tests along the way that will guide your direction and validate what you have done, bearing in mind that sometimes your decision will be wrong and you will need to change tack. Make this strategy as flexible as you can without losing focus altogether. Then plan in detail for the next step only in the journey and plan how you will engage the customer and when and how you will react to feedback.
5. Now plan your technical roadmap, so that the pieces of the technical jigsaw can be planned to support the products, functional and cultural changes and stay synchronized. Make sure that this technical plan is layered so that the bulk of your technology is supported by reliable and trusted platforms and protocols that are well known and trusted and the innovation needs only effect the very top layer. TOGAF has a very good way of describing this, though I am not necessarily recommending you take on board all the majesty of TOGAF, which could prove an even bigger undertaking in it’s own right.
6. However long it takes, hold session after session if needed with the technical/solution Architect, project leadership, lead developers and Business Architect or equivalent and make sure that they understand what you need by way of regular feedback and metrics and don’t stop till they satisfy you that they will provide them. Don’t spend lots of time on expensive dashboards, just look at the risks that worry you, discuss with the team the things that might signal a problem and agree how these things/the triggers can be monitored and spotted early.
E.G. The big problem with fashionable Scrum/ DevOps environments is that nobody can see where fixing and supporting last week’s poor quality release and developing this week’s starts and ends and therefore nobody realises just how much their weak QA is costing everyone emotionally and financially. To stop this, you could separate the bugs from the new build like we used to do and sanction those who repeatedly throw rubbish over the wall. You would of course be treading on a few religious burial grounds along the way, but this is becoming part of the territory in technology.
7. From before you embark till the end of time, create and manage a detailed communications strategy and communications plan. Everybody is important but they need different messages in different language. Remember, your communications plan is providing communications between the technical team and Business stakeholders they never met just the same as it is communicating between the programme and the stakeholder groups.
You absolutely must believe in what you are doing and be able and willing to share the future vision, the opportunity, the drivers, the risks with others and bring them on-board.
Of all the things you do this one is by far the most important and it is difficult because it nails you to the outcomes, but if you do it right it will gain you support and compassion when things go a little south.
8. Test early and test often and keep testing the customer and listening to and observing her reactions. Walk in her shoes and define products for yourself.
[i] MVP means Minimum Viable Product. Some describe it as the least you can do to make a product that delivers something. Experienced product Managers will more likely define it as the minimum that conveys an advantage to the customer and engages her.