icm2re logo. icm2:re (I Changed My Mind Reviewing Everything) is an 

ongoing web column  by Brunella Longo

This column deals with some aspects of change management processes experienced almost in any industry impacted by the digital revolution: how to select, create, gather, manage, interpret, share data and information either because of internal and usually incremental scope - such learning, educational and re-engineering processes - or because of external forces, like mergers and acquisitions, restructuring goals, new regulations or disruptive technologies.

The title - I Changed My Mind Reviewing Everything - is a tribute to authors and scientists from different disciplinary fields that have illuminated my understanding of intentional change and decision making processes during the last thirty years, explaining how we think - or how we think about the way we think. The logo is a bit of a divertissement, from the latin divertere that means turn in separate ways.

Chronological Index | Subject Index

Houston, we've had a problem

About changes and configuration management

How to cite this article?
Longo, Brunella (2018). Houston, we've had a problem. About changes and configuration management. icm2re [I Changed my Mind Reviewing Everything ISSN 2059-688X (Print)], 7.12 (December).

How to cite this article?
Longo, Brunella (2018). Houston, we've had a problem About changes and configuration management. icm2re [I Changed my Mind Reviewing Everything ISSN 2059-688X (Print)], 7.12 (December).

The awareness of complexity makes us realize that we can never escape from uncertainty and that we can never have total knowledge.
Edgar Morin

London, 22 January 2019 - An encounter with a consultant and university teacher last year has deeply disturbed me. This lady teaches her students in a sort of manichaean way that change in industry design and project management is to be avoided as it is wrong at all times.

The message she wants to deliver is that change management processes are good as long as they are used to block and prevent any error or variation to happen.

I understood this philosophy is her baseline and discovered she is not the only one to frame the notion of change as a synonym for some sort of error, usually driven by the wrong data. I must concede that I may tend to have the opposite bias in many circumstances, and to consider change as an opportunity for improvements when there is barely any.

Anyhow, once she has shaped her students' approach to the subject so that they are locked in such an allegedly safe mindset, she then introduces concepts like change requests, versions control or risk management. That is like saying that after you have worn your swimsuit you can now dance tango.

I cannot say what is the best way to teach change management at university level - especially if nobody pays for such an unqualified opinion. However, depecting change with rebellious colors is not only far from the reality of doing and staying in business in our times. It is also conceptually confusing, leading to the erroneous belief that there is only one right way to manage whatever type of change in any situation or market. All the ideas, solicitations and wishes for change and instances of change out there must be inherently wrong.

Of course this is not the case for information and communication technologies that change by use at individual, societal and organisational level.

Managing arrangements of things

People do not usually know neither think about the fact that managing change is so relevant for the production and maintenance of software that a number of industry guidelines and international standards have been agreed over the last three decades: innumerable tipologies of imperfections, flaws and defects that cause dysfunctional performance, waste of time, incidents or total failure of systems have been analysed and categorised over the years across many companies, products and methods of work in order to produce and agreed best practices that everybody can endorse and develop further in predictable, controlled and still creative ways.

But users are not to blame because the industry itself has never done too much to educate the public about these aspects of the magic given by technologies of information and communications.

If it wasn't because of the marketing pressure to buy a new smartphone or update your computer operating system to Apple Mojave or Windows 10 to troubleshoot some dysfunctional performance (such as the printer that does not print anymore, the internet connection that has stopped working, a file that suddently does not open), the majority of computer users (with the possible exception of the youngest and the computer science students) would consider their equipment pretty much eternal. But that is, at the end of the day, what good computing should be all about, no matter the life cycle of products and services or information: a seemless, transparent, non bothering pathway to walk through for the purpose of doing something that really matters to us.

Ah! if only we could design smartphone and computer apps, healthcare services or the whole of consumer electronics gadgets as they were spacecrafts!

There, in the spacecraft design space, it is less likely that all the people involved forget risks, reviews, contingency plans in case the unpredictable occurs.

There are also constant stringent measurements along the way telling people how things are doing, by way of normal functioning, sensing, reacting and interacting.

But above all, generally speaking, in aerospace and industrial project management, engineers are forced to think about systems at all times: it is impossible to document everything in formal terms, it is impossible to communicate about everything and record such interactions constantly and it is also impossible to achieve 100% testing of all parts and components at any given seconds. However, if adequate systems engineering protocols and change management processes are in place, it is likely that the correct operations take over to resolve and correct errors as soon as they occur.

In software development - and more in general in all the applications of ICT technologies - there are innumerable repetitive tasks that only certain beautiful minds - to say so - could find exciting over time. Above all, few could perform such tasks high degrees of accuracy.

At first, in the history of software, everybody wanted to be a champion of what we now call configuration management and version controls, but around mid 1980s it became clear that the future of software development and maintenance would be trough automation and modularisation. Incorporating change into the creative process in controlled ways is what has made the industry appearing similar to others - without totally disregarding its nature of art. And yet talking about computer science is an academic convention, like (if this exists) talking about wine science.

It is not really possible to increase the resilience and the reliability of systems made by human beings as we would do with things or automated components. Of course human beings can be hugely influenced and manipulated. An entire generation of neuroscientists is on the mission to discover how can you eat more fruit and vegetables and give up meat without any sense of loss for salami and roast beef.

However, as the proverb says, so far it looks like even in neuroscientific terms you can lead a horse to water but you cannot make him drink without some forme of societal constraint - that is why we should possibly extend human rights into the field of neuroscience research.

Humans forget or disregard documentation, unexplicabily refuse to talk with each other or lie with the most irrationale and childish justifications - and are likely to happily chat about the football or the weather even when they should instead concentrate in learning, testing or auditing something new really important for their business.

Assuming that is achievable, do we want to exchange ourselves for an algorithm? If not, the answer is unlikely to come from a simplistic neuroscientific formula. Instead more complex thinking is needed.

How can we seriously implement and manage configuration management processes in services and in the creative sector without attempting to be each time uniquely and creatively systematic, causing inevitable scope creeps and new requests for change, is something that has been puzzling engineers and project managers for long time.

Today, the new challenge for systems engineers consist in integrating and embedding more and more human controls into machines behaviours and viceversa, in a sort of progressive symbiosis. But to somebody this sounds nothing really new: at the beginning of the software engineering history, in the late 1960s, there was the same tension toward a more predictable, structured and therefore manageable activity, following a glorious pioneering decade of tumultuous software writing and coding along creative though disparate technical directions.

More and more automation and integration of systems are possible if we consider the perspective of horizontal innovations or cross-fertilisation across sectors. However, systems engineering outside very controlled science-led environments (again, aerospace, nuclear or defence) is by its same nature an exercise in change management and configuration management at scale, not only interdisciplinary but also constantly opened to scope creeps, more a combination of different arts and techniques than an exact science.

That is where I found myself comfortable with the hat of a systems engineer, even if I did not go to university to learn about a quite impossible discipline.

To our scant consolation, stories of systems' failure and human errors do exist even from sectors heavily structured and hyper-controlled that gave birth to systems engineering, such space missions. So let's not worry about change and look at it with optimism and fundamental happiness. We will always be able to talk about creeps and problems as details of the past, if we survive the challenge of complex thinking.