(versione italiana qua)
In this article I reflect on one of the crucial elements in achieving an efficient and effective Public Administration (PA). The term "digital transformation" is often used in this context, and while it conveys the urgency of having a PA that is fit for a digital society, it has, in my view, the drawback of drawing attention only to the moment of transition, while obscuring the steady-state situation that follows. As will become clearer below, the computerisation (the term I prefer) of the PA — as of any other organisation — is a continuous process, and one that must be approached very differently from how it has been handled so far.
Let us consider why. Twenty years ago, in 1998, the average person used neither email nor social networks, and technology had given us the mobile phone. But this was nothing other than the good old telephone — simply one we could now carry in our pocket wherever we went.
Now it is as if we were on a different planet, one made up of emails, tweets, posts, passwords, and accounts — mangling our beautiful language as we go. But this is only the surface. Beneath it, we are the same human beings we always were, and "good" and "bad" alike, we continue to do the same things. The bad actors, in particular, have perhaps understood better than the good ones how to do the same things more productively.
At the level of organisations, however, this explosion of digital technology has been enormously more revolutionary. It has made it possible to automate functions that were once the exclusive preserve of the human brain — but with the fundamental Achilles' heel of lacking the flexibility and adaptability of human beings. I have discussed these aspects in greater detail elsewhere.
What I want to emphasise here is that any software application is the automation of functions tied to the cognitive capacities of a person. Typically, an organisation acquires a computer system in order to replace, by means of an automatic system, cognitive faculties previously performed by one or more people. The functions to be automated are identified once and for all, and are then replaced by a computer system — a "cognitive machine" which is, in the digital society, the counterpart of the traditional machine in industrial society.
This replacement, like all automation, takes place in order to improve productivity — that is, to increase output, reduce costs, or both. So far, nothing objectionable: the automation of work has for centuries been the key factor ensuring a steady rise in productivity.
Having acquired a computer system means having replaced one or more people with one or more "cognitive machines." But these machines, lacking any capacity for adaptation, are unable to evolve in response to changing surrounding conditions. This is why the acquisition or development of any software application must follow a different path.
First and foremost, the mental paradigm with which we approach informatics automation must change. Every organisation knows full well that when it takes on an economist, an engineer, a lawyer, or an accountant, what that person knows how to do at the outset will not remain static over time — it will evolve, because the person will learn on the job a whole range of details relevant to the organisation itself, and will adapt their behaviour as their operational context evolves. Initially, of course, under the guidance of their manager, and then with an ever-increasing degree of autonomy.
If part of this cognitive work is transferred to computer systems, the flexibility and capacity for evolution that are specific and defining characteristics of human beings are lost. Failing to change this mental paradigm means continuing to waste money on software development.
This is not because the Italian PA is particularly incompetent. The United States is often rightly held up as a model, yet its own PA, when it comes to the implementation of computer systems, is in exactly the same situation as ours. I will return to this point later.
The approach to adopt, therefore, is to treat the acquisition of a computer system in the same way as the recruitment of a certain number of people with certain core competencies. No recruiter expects to find the "perfect candidate" every time, because that is simply not the norm. The aim is to find someone with a sufficiently strong profile to hit the ground running effectively, and to develop from there.
The same approach must be applied to computer systems. This does not mean taking whatever happens to be available, but rather making the incremental, co-constructed development of the system itself — by users and developers, by clients and suppliers — an integral part of the acquisition process. Exactly as happens with employees. Everyone who works in this field knows how complicated it is to integrate a team of 10 new staff members into a group of 100, and all the more so the greater the cognitive, as opposed to physical, component of the activities carried out within the organisation. When a business process is digitalised, essentially the same thing is happening. Why should we proceed any differently? If we do, it is because we have not understood that informatics automation is radically different from all other forms of automation and requires a different approach.
How does the process currently work? The traditional procurement workflow for services and products used by the Italian PA — though in this respect public administrations are broadly the same the world over — involves an initial phase of defining the requirements for the necessary service or product, with the drafting of detailed specifications against which companies submit bids. The best bid (on the basis of cost plus a technical evaluation component) wins, and the contractor begins to deliver what was requested. At the end, if the service or product passes the final tests, the operational phase begins.
What are the consequences of this approach? Both in the Italian PA and elsewhere in the world, development programmes involving software components are invariably those that run furthest behind schedule and most significantly over budget. Recently, the director of the Acquisitions Department of the US Department of Defense (the DoD), Will Roper, stated that the traditional procurement system used for decades to buy ships and aircraft "does not work for software," because "a software system is never finished — it is a continuous process."
The world's most innovative technology companies have long understood that this method does not work. If users only see the software at the end, it is highly likely that not only will the initially defined requirements not have been met, but that what they actually need will have changed in the meantime. From collaboration between the research community and industry, a radically different approach to software development has emerged over the past twenty or so years: the so-called "agile" approach, which is precisely the one used by leading-edge technology companies, because it enables them to develop successful products and services.
If you think about it, this is exactly what we see in the successful apps that all of us use every day. They always seem the same to us, but behind the façade there is a constant process of updating and evolution. Just like the people who, behind the façade of an organisation, provide us with its services — evolving as surrounding conditions change, or in response to decisions taken by management. In my article from almost ten years ago, cited at the outset, I wrote, with reference to the development of computer systems: "maintenance is the real implementation."
A radical paradigm shift is therefore necessary — one that, I repeat, must above all be a shift in mindset.
From a procedural standpoint, the procurement of computer systems must no longer be based on the upfront definition of all requirements. Instead, a limited set of initial objectives and use cases should be identified, on which a small joint team of developers and users will begin working, with the task of producing a first functioning core within a matter of weeks. From that point on, the process continues with this iterative — or "agile" — approach, learning constantly from successes and mistakes in the field, and adjusting course in response to evolving scenarios.
This is an epochal shift if one considers the procurement of a software system in the same way as any other product. It is the natural solution if one views it through the lens of hiring staff.
It is clear that this new procurement paradigm can never be adopted by the Italian PA unless it is compatible with the relevant legal framework. It will therefore be necessary to overhaul the entire regulatory apparatus governing the procedures by which the PA procures computer systems. This will require a strongly interdisciplinary effort, mobilising all the competencies involved in this process — legal, documentary, informatics-related, managerial, and psychological — under the guidance, naturally, of a political leadership that must take personal responsibility for resolving long-standing problems.
It is not a quick process — it will take many years — but it could be a legislative-term project aimed at leaving Italians with a better country.
--The original version (in italian) has been published by "Agenda Digitale" on 31 gennaio 2019.
Nessun commento:
Posta un commento
Sono pubblicati solo i commenti che rispettano le norme di legge, le regole della buona educazione e sono attinenti agli argomenti trattati: siamo aperti alla discussione, non alla polemica.