The Digital Sins – Part 4: The Missing Awareness of the General Nature of Digital Things

There are many causes of why innovative IT projects fail. Three reasons for where things frequently go wrong: a lack of understanding of complexity phenomena, the disregard for cultural aspects, and the naive, direct application of the experiences of analogue business life to the design of digital transformation.

Part 3 dealt with the peculiarities of IT that are hard for non-computer scientists to understand. As an example, I described the ugly ageing of IT, which runs counter to the intuition of most non-IT experts.

There are, however, numerous further peculiarities that are hard for non-computer scientists to accept:

• Technical sustainability does not mean long term use, but the easy replaceability of outdated technologies and standards – i.e. in economic terms: technical sustainability is defined via future opportunities (real options).
• Complexity is managed by hiding information – i.e. information hiding is a virtue in IT.
• The failure of IT innovation projects is normal – a 100% success rate in the project management of innovative projects is a warning sign: we have entered the realm of alternative facts.
• For every project there is a theoretical, practically unknown limiting frame that defines the minimum and maximum personnel and time resources: beyond these limits, failure is inevitable – i.e. even if you do everything right, you can still fail because you have either too much time or too much personnel.
• There are various methods of slowing down IT projects through acceleration – from shortest-path optimisation of the project plan (which is also notorious in other, non-IT, engineering fields) to the allocation of additional resources.
• Brilliant arguments are either the smoke that points to fire or the fuse used to start one – contrary to all clichés, many IT professionals are brilliant at arguing (and at power-political games).
• Agility is achievable only at the price of high discipline among ALL those involved – i.e. among managers, staff, and clients.
• Increasing an organisation’s IT maturity is possible only as a coordinated effort across very different areas – from technology to the definition of leadership responsibilities – and is a process in which many critical parameters do NOT develop monotonically (e.g. cost and autonomy).
• Transparency within IT departments regarding staff capabilities is very high within the teams but very low towards senior management – i.e. “those at the top” often have no understanding of your performance, while within your own team you are an open book.
• Good design of a digital solution happens in layers and anticipates that the topmost layer is the subjective appropriation by the users – i.e. a premature focus on the practical solution is dangerous, and a pro-forma involvement of users falls short.

Each of the points above would be worth a column of its own. Even though some of them are hard for laypeople to understand, I have listed them here to make one thing clear: in the IT world, substantially different rules apply than in the non-IT world. And this holds true even when we consider only “reasonable” action. When management and clients ignore these peculiarities, they obstruct digital transformation. And when colleagues from other areas discuss one or another of the listed aspects – e.g. agility or transparency – with IT professionals without taking the ontological and cultural differences into account, things quickly turn bizarre.

Psychology and Beyond Psychology

Most of the examples cited above have to do with technology and with people at the same time. Even though their cause lies in the peculiarities of information technology, phenomenologically they play out among people. And not only among people in the role of IT users, but also among people who commission, build, or operate IT.

As soon as people come into play, psychology is readily invoked. This is as justified – people behave according to patterns one must know when leading digital transformation programmes – as it carries the danger of inadmissibly reducing problems to the psychological.

Largely within the psychological domain lie, for example, the conflicts in digital innovation projects and the strategies for dealing with these conflicts. A common mistake is to try to grasp the situation solely with the tools of institutional economics. Yet the conflicts occur in concrete situations and are caused by concrete rational thinking that is shaped both by disciplinary logic and by role dramaturgy and the logic of power. The associated collective phenomena are best understood through psychological-anthropological progressive lenses, but it cannot be done without an individual-psychology perspective. That perspective is necessary.

Anyone unwilling to accept this – and I well understand that many reject the emphasis on psychological factors – does not understand why so many digital transformation initiatives fail, and is also unable to seize the chance opportunities for digital improvement that keep arising.

Unfortunately, taking psychological aspects into account is not sufficient. Reducing everything to psychological perspectives brings four dangers:

• The psychological view is reduced to users’ IT acceptance, which is doubly inadequate: first, the real issue is more than mere acceptance, namely effective use; and second, users are not the only people in play: there are clients, contractors, legal experts, and so on.
• Amid all the focus on people, mastering the technology drops out of view – the intention behind the popular claim that technology is never the problem is a noble one (it aims to point to the central role of users), but as a matter of fact the claim is fundamentally wrong.
• The cultural aspect is forgotten, resulting in unsuitable management practices: people’s behaviour is determined not only by their biology and psyche but also by their culture. This leads not only to large differences between West and East, but also to substantial differences among age cohorts, professional groups, and even individual companies.
• Objective complexity problems are ignored: communication and control are key elements in the development of complex systems and fail not only due to unwillingness or resistance and cultural differences, but often also due to their objective impossibility.

Impossible communication? That sounds odd. But I am not talking here about physical limits (which are irrelevant in this context), but about resource limits. If a project is divided among too many staff, the need for communication grows so strongly that it bursts the capacity of the project management. All methods of remedying this problem in turn give rise to new problems, until at some point an unmanageable behemoth results.

Seen from this perspective, cultural differences are not a cause of problems but merely a problem parameter. They lower the limits of parallelism. The same applies, however, to the culture within a project that has no cultural differences – in some companies more parallelism can be achieved efficiently than in others – and to the psychological constitution of those involved. Between the age cohorts in the Swiss IT scene, for instance, there are large differences in the willingness to cooperate and, accordingly, in the ability to handle complex projects.

A Practical Approach

In the practice of digital transformation, what helps is an awareness of the peculiarities of digital technologies and, above all, heuristics for how to deal with these peculiarities. This applies in particular to the role of people in digital transformation.

With these heuristics one becomes more successful. And if, building on this, one gathers experience and uses that experience to reflect on the heuristics, then over time – within natural limits, for example that 100% success is not possible – one will learn to do a truly good job of designing digital transformation.

A useful metaphor here is that of the socio-technical ecosystem. If, for a specific programme, one develops a model of the ecosystem, this helps in analysing and responding to what happens within the programme. For the specifics of cooperation between business and IT, a methodically developed enterprise architecture that is communicated intensively is also useful. Nothing here is simple.