Digital transformation is often used as a buzzword, an unquestionably ‘good thing’ for every organisation. It is certainly much discussed. Leading universities offer courses. Linkedin is replete with hiring adverts. The consultancies offer advice and support. During the pandemic, many organisations crashed the gears to reflect both radical shifts in customer behaviour and forced adaptation to internal operations.
Digital transformation has been defined many ways, most frequently and conveniently to correspond with a particular supplier’s services or products. The meaning I use here is the application of digital technology to make significant change to an organisation’s operating model, processes and customer interaction with the aim of gaining competitive advantage. The focus and scope here are fundamental and strategic. Individual steps may involve experimentation at the edges, as for example in the refinement of a screen to optimise an element of customer experience. The concept of transformation is that such steps should be part of an over-arching plan.
Business transformation has been well researched and documented.1 The elements that must be satisfactorily performed for initiatives to succeed have been established. Digital Transformation is business transformation facilitated by digital technology. The same principles apply as for business transformation, starting with strategic clarity and leadership.
—
“Disruptive technology should be framed as a marketing challenge, not a technological one.”
Clayton Christensen, The Innovator’s Dilemma
—
What is Different?
If the nature of people and transformation have not changed, the most significant difference with respect to business conditions, say in the 1980s, is the pervasive use of digital technology.
The likes of Amazon2 have revolutionised business practice. It started by selling only books. It rapidly established a platform that now sells millions of products. It applied the potential provided by technology to re-engineer processes and serve customers in ways that delivered significantly greater value at lower cost than preceding methods (high-street shops with high inventory, expensive staff and rent).
Transformational Risk
John Kotter reported that of the business transformations he reviewed in his research, 70% failed to reach their original objectives. 10% succeeded spectacularly.3 Kahneman and Tversky, the Nobel-awarded researchers in behavioural and experimental economics, have noted strong optimism bias:4 managers and others are likely to assume that their initiative will be in the minority that succeeds.
—
“To err is human but to really foul up requires a computer.”
Dan Rather
—
Within transformation, there are multiple interacting elements involved in coordinated change. I started my career as an engineer. I was trained to think in a deterministic manner in which cause-and-effect can be modelled and predicted. In a simple machine, the interactions are simple. As a mechanical engineer, I was centrally concerned with stress, strain, pressure, heat and motion. When it comes to a machine such as a gas-turbine,5 the interactions are far from simple but are soluble. Being based on the well-established laws of physics, modern computer models have reached a high level of sophistication and reliability. Such models are extensively relied upon in design, development and test, greatly reducing the cost and duration of physical prototyping and final physical test.
When it comes to designing new operating models for companies, and the IT systems to support them, there are architectural modelling systems that can be used to develop and test before building the components. These are large and sophisticated tools that support complex models. They are useful for some elements such as data entity modelling and transaction queueing. They are less so for predicting human behaviours. Models can bring considerable value to the reduction of transformation risk, but some elements must be evaluated in other ways.
Experimentation
—
“99 percent of success is built on failure.”
Charles Kettering
—
Some programmes assume that all the interactions of design, operation, data and customer behaviour have been appropriately selected in advance, without need for revision. Dispensing with modelling or research, they rely on the lawyers and others to draft the contract for specification.
Experimentation requires a high degree of maturity. Those funding it must be prepared for the likelihood that the outcome has favourable and unfavourable elements and that a series of iterations will be required. This approach is at the heart of Agile methodologies. The prerequisites for the approach are highly demanding and some should not touch it. That does not make it a bad tool: just frequently unsuitable. In skilled hands with supportive managers, it can deliver strong results.
Fixed-Price
When discussing this article with a friend, he told me that his organisation had a senior manager who had insisted on a highly specific fixed-price contract for an ill-defined approach to changing operations. Having had their advice ignored, the supplier determined to take the money and delivered to contract. The boss was unhappy with what was delivered.
Capable customers and suppliers continue to enter fixed price agreements in uncertain business situations. I have seen parties contract successfully for transformation, and one at least to come out well, even when the outcome was not as hoped for. This is however a risky situation. It is suggested that a wide range of scenarios is examined before signing.
OOTB
ERP suppliers such as SAP noted there was opportunity to deliver significant advantage by changing the software development model from that of entirely bespoke, original creation every time to “Out of the box” (OOTB) software.7 In this, for some back-office processes, a customer could implement a system far quicker and cheaper by the customer adapting their process to suit the mental-model within the system, than it would take to adapt the system to suit the customer’s approach. In disciplined areas such as finance and manufacturing, this has been highly successful. Large consulting systems integrators have thrived on bridging the customer and software supplier.
Increasingly this same OOTB approach is being seen as the salvation of the ossified. They buy OOTB software in the hope of gaining a leap over competitors so enhancing profitability. This has risks. The software will have known limitations. They will have conducted a gap-analysis, but the degree of change to the current operations and how those are to function in the future will be uncertain. Will the customer be able to deliver on their promise to change their ways of working to suit the new tools? Will the necessary updates to the base software be delivered in time?
Risk Areas
There are two areas that experience suggests are particularly high-risk. These are the deployment approach and data migration.
The deployment approach is the way in which you take the change into live operation and business use. Most of the time there is a business that must be sustained through the change. If anyone suggests “Big Bang”, ask them to read about TSB and come back with whether they still think it is a good idea.8 A change of deployment approach can have huge implications for the way the product is designed and delivered. It needs to be agreed on with a reasonable degree of precision early in the programme. This is mostly about the business and their ability to cope, not about IT, but profoundly influences many aspects of system requirements and IT programme delivery.
Data migration is detailed, technical and hard. There are two nasty stages: data cleansing and standardisation. Most data contain a degree of imperfection that a business learns to cope with. Missing fields; typographical errors; data put in the wrong place; inconsistencies (e.g., 3 differing addresses for one person). The pre-requisites for speed and efficiency include accuracy and consistency. People are quite good at coping with inconsistency. Machines are not. If your digital transformation involves reducing reliance upon manual processing, you will have to clean up your data. Expect to see this in the small print as a customer responsibility. There are now good tools to help you, but the task remains a big one.
Disputes and Good Contracts
The need to keep up with, and the desire to overtake, the competition is likely to accelerate rather than diminish. The uncertainty of requirement (in the broadest sense) within digital transformation is such that precision of functional and process requirement in advance is not consistent with assuring successful business outcomes. This can be uncomfortable territory for those charged with writing an agreement. One can agree a process for experimentation, state the milestones at least for initial phases and determine decision points but not commit to favourable outcomes. How can more be fixed when the destination and route are unknown and indeterminable in advance? Some proceed in hope that they can be in the minority that succeed first time. That is brave.
Where risks are great, so is reliance upon the quality of risk management. If both are prepared to enter an agreement to fix what can be known and to experiment to find a route through uncertainty, greatness may result. There will probably be a lot of change along the way. Most experiments will render more insight into what does not work than into what works well. If you have the pockets and the stamina to cope with setbacks, go ahead. If not, digital transformation is not for you.
Prove It!
Many IT disputes are pleaded as breach of contract. The expert witnesses like me who are asked to investigate and report on the issues will look to project plans for delay analysis and to tests and defect reports to assess delivery quality. Investigation may reasonably include a review of what happened in governance meetings. These tend to be low-level, detailed aspects of investigation. They are likely to have a place in clarifying the issues for the Court. Whilst it may be clear that a customer is unhappy, it may be less clear whether or not requirements have been satisfied.
If the parties are to enter a high-risk area such as digital transformation, it is likely that areas of the contract will be vague, as at the time of drafting the route to be taken will include many unknowns. An honest contract would state in the recitals that this is an experiment. The customer of transformation may be delighted or disappointed by the outcome, but in neither case should they be surprised.
Notes and Sources
[1] See for example John P. Kotter, Leading Change, Harvard Business School Press 1996; https://oareborough.com/Insights/inside-change/
[2] Founded 5 July 1994, Bellevue, Washington, USA
[3] A sense of Urgency, John P Kotter, Harvard Business Press 2008
[4] Daniel Kahneman, Thinking Fast and Slow, Penguin Books 2011. Amos Tversky died before the Nobel Committee made its award to Kahneman for the research insights they developed together. It does not make posthumous awards.
[5] https://en.wikipedia.org/wiki/Gas_turbine
[6] Clayton M. Christensen, The Innovator’s Dilemma, Harper Business 2011
[7] OOTB still normally requires extensive configuration and the development of custom interfaces. A relative, COTS (commercial off-the-shelf) refers to programmes such as word-processing that are typically used with next to no configuration.
[8] https://www.tsb.co.uk/news-releases/slaughter-and-may/
William Hooper acts as an expert witness in IT and Outsourcing disputes and a consultant in service delivery. He is a member of the Society of Computers and Law and a director of Oareborough Consulting. He may be reached on +44 7909 958274 or William@Oareborough.com
