An increasing number of IT disputes occur within the context of digital transformation. What are the implications of this for those who seek redress?
In a previous article, I addressed a definition of digital transformation and identified some of the factors that may give rise to disputes.[1] An awareness of that may usefully inform those considering the initiation of a transformation programme and how best to ensure success. This article assumes that you are concerned about a programme that has gone awry and that you seek redress.
Initial Assessment
One of the differences between digital disputes and more generic IT issues is that digital are associated with broadly based change, resulting in greater complexity. There are many interacting strands contributing to the outcomes seen. It is rare to find that one party is wholly responsible for all. Strands may include amongst others:[2]
- Multiple suppliers and dependencies between them;
- Governance and leadership of people;
- Architecture and technical interactions;
- Deployment mode and data migration;
- Changes to business models and operations;
- Commercial Off-the-Shelf software and customisation;
- Changes to requirements of the solution;
- Delay, poor quality delivery.
It can be a challenge to tease apart the root causes from the symptoms and effects. This is necessary to develop a convincing explanation of the outcomes seen, the attribution and damage. The legal team will want to advise the client on the strength of the case and later to develop pleadings. This is likely to draw upon a combination of operational advice and legal opinion. The client must decide whether it is worth pursuing.
Whilst a client may be indignant that they have been wronged and clear that the other party was to blame, there will remain a risk that the court will place a different weight on the factors before it. This risk cannot be eliminated by taking independent advice, but it can be reduced.
At this stage in a digital case the factors to be considered include many that are traditionally found in IT disputes, such as the levels of defects seen and the quality of delivery. They also extend beyond these into aspects of the business and the way it is changing itself.[3] These are at the core of the approach to transformation. A perspective that is frequently adopted is termed “systems thinking” as this considers the ways in which one stream of activity interacts with another.[4] This can be challenging for the courts, where a direct cause-effect is more comfortable ground. It may be that some elements needed to establish context and understanding of what was going on influence attribution more than directly pleaded loss.
Experimentation v Determination
If one is undertaking a familiar transaction, the steps and output should be predictable. Contracts can then be written with precision to manage risk. One would hope that requirements, plans and costs have been thoroughly prepared to reflect the scope and that there are few risks to delivery.
The more transformative a programme is, the less will be pre-determined. This is the land of experimentation. One may still contract for support and for the delivery of inputs in the hope of a good outcome and learning that should influence later development. Aspects such as customer reaction are harder to predict. Once the initial phase has been completed, the parties can refine the approach before designing the next. The contract and approach taken can be largely traditional, as can the expectations of delivery to the standards of a competent professional. For the disputant and their legal team, this becomes reassuringly familiar.
Replacing Legacy Systems
The replacement of a previous system is not necessarily transformative. The architecture, data model and other aspects may differ without substantially changing what is done. It is more up-to-date and, one would hope, effective. Someone who talks of “transformation” in such a circumstance may complicate a situation without capturing benefit but is unlikely to do serious harm.
Some programmes to replace legacy systems are fundamentally transformative. These are likely to be associated with several of:
- Channel shift – e.g. using web-based tools to replace significant parts of what was done face-to-face by web interactions.
- Automation – the widespread replacement of people by machines, including AI and computer assisted decision support. Widespread change to processes and staff responsibilities commonly follow.
- Establishing new competence – Transformation is often seen as a journey. It is not a single change that once made, establishes a new immutable state. The expectation is more that there will be an ongoing programme of development and extension to new market areas and operations. It will need matched skills, knowledge, tools, abilities, and behaviours to deliver this.
- Product architecture – the elements, supply, channel, and arrangement of them to deliver customer value. This is closely related to operating model design.
- Service architecture – the combination of a set of discrete services, as opposed to monolithic design.
Transformation is frequently undertaken in the hope of delivering competitive success. Modern customers are intolerant of poorly designed interfaces, processes, and services. Those who assemble and refine offerings that deliver substantial value retain a loyal and profitable following. Those who take too long find the market has been captured by others who are difficult to displace.[5]
Where there is fundamental change, people will be asked to change what they do and the way that they do it. The way they react can support the change or resist it. Some fears may be well-founded. The organisation’s leaders must determine how to deal with such resistance: what to accommodate and what to overcome. This takes substantial and sustained effort in a coordinated manner.[6]
Operational people may not be used to being asked to imagine new and different ways of working. They may have been performing the same process for years. Unless carefully facilitated, they are likely to state requirements in a way that replicates what the system currently does rather than thinking anew. The use of tools such as process mining and task mining may help to develop insight into the current state. Data on the number of repetitions of a manual task may expose the shortfalls and bottlenecks of current operations. Pilots in which the users can touch and try a simplified version of what is proposed may help to win people over and identify hidden requirements and value. Such approaches are favoured in the design of user experience.[7]
Flexibility demands the initial organisational, data, product and technical architecture must have some areas of stability and others that can easily be changed.[8] It can be very time-consuming and expensive to replace faulty foundations when an edifice has been constructed upon them. Where there are many moving parts, the intellectual and design demands of the associated architecture are challenging. Issues may emerge long after initial implementation. Some changes, particularly associated with deployment to the business or security, can have implications that are far from obvious at the time.
Telling the story of the programme effectively in a way that clarifies cause, attribution and consequence in a way that the court understands is likely to be influential. Much will be familiar to traditional IT programmes: some will not. The chain of causation will rarely be direct, but insight helps to develop understanding. Developing operational insight to complement the legal assessment can usefully inform a client’s decision of whether to proceed with a claim.
[1] https://www.scl.org/12443-digital-transformation-and-disputes/
[2] https://www.scl.org/12443-digital-transformation-and-disputes/
[3] https://oareborough.com/Insights/business-models-a-compelling-story/; https://oareborough.com/Insights/inside-change/
[4] See for example The Fifth Discipline, Peter M. Senge, Doubleday / Currency 1990
[5] https://oareborough.com/Insights/stealing-a-march-using-innovation-to-beat-the-competition/
[6] https://oareborough.com/Insights/inside-change/
[7] Design Thinking, Nigel Cross, Berg, 2011
[8] Designed for Digital: How to architect your business for sustained success, Jeanne Ross, Cynthia Beath, Martin Mocker, MIT Press, 2019
