A different spin on complexity management

Quality and Systems understanding against fear of complexity

This article is intended to inspire anybody engaged in systems- or product development to immediately face existing complexity. By focusing on the understanding of relationships and guiding parameters as early as possible and by checking those continuously through the project. I call the described practical approach QiD "Quality in Design".

I am proposing; the quality of knowledge about relationships in a system is the guiding principle for developmental work in complex systems.

QiD is defined as follows: Quality in systems development is achieved, if the knowledge about the technical connections of a systems solution to be developed is verified (and therefore true), visible (meaning documented), and usable for all domains or sub-disciplines (e.g. understandable).

The pursuit of this kind of quality should be the focus. No special organizational or even theoretical preparation is needed for that.

On the breakfast table and the important view from the outside

40 years of working in the development of technical solutions couldn't possibly pass without a trace. A wonder, my family is still willing to spend their morning sitting and discussing together. And in retrospect I guess I should apologize for all those seemingly innocent breakfasts, where i suddenly spread my thoughts to them. And yet i was lucky: first, our hunger, and the old rule about refraining from speeches with a filled mouth; every sweeping monologue was thus prevented. And secondly my thematic distance, since if no-one else on the table is interested in detail, it's hard to lose ourselves in there. The perspective of the observer could always be kept intact. Those rounds of feedback with all five of us played a significant role in the formation of this article.

Scope, premise, sources and credit

Demarcation: I am not going to delve into variance-induced product complexity or configuration management within this article. I am also not going to concern myself the well-established field of systems engineering or the diverse approaches of model-based systems engineering. How to shape or structure a system and how to describe and specify its interfaces shall merely be part of the backdrop. The focus is on "managing" rather than on "describing technical complexity". 

Premise: The guiding philosophy of the project, either "agile" or "classic", is independent of the described approach. The same is true for the extent and type of technical disciplines of a solution to be developed, such as hardware, electronics, software ...

Sources: As far as external sources go, I would like to point towards the book "The Art of interconnected Thinking, Tools and concepts for a new approach to tackling complexity" (Munich 1999) by Frederic Vester, from which I was able to receive a number of impulses and the symbolic which served as the prototype for the illustrations in this article. 

I am also thanking my son Lukas, who as a Systems and Software Designer helped me through his critique to make sure my approach would be accurate and relevant for the "new technologies", as well as my daughter Mirjam, for the illustrations.

I am eagerly anticipating your feedback.

(thomas.hannen@bluewin.ch)

Step 1: Straight on is sometimes wrong!

Let us leave the feared notion that without organizational parameters, rules, mindset-change etc. complexity management might be impossible aside for the moment. Using additional software and new processes to tackle complexity does not help in reducing our fear of it. It is rather distracting us from doing the first important steps.

As first step it is not important to begin partitioning an envisioned systems solution into its technical disciplines or domains, to immediately give it an architecture, or to start talking about interfaces and to commence the specified work in the separate domains.

Even if we as technicians are at home and feel safe there. But we would be running away from complexity, as something important is missing.

The road to systems understanding winds itself around the system.

It is important to acquire an understanding about relationships as soon as possible. First between the solution and the environment in which we would like to deploy it. To gain an understanding about how this environment, which existed prior to and without our solution, might react to it. This is to get up close to our problem, to be able to understand and formulate requirements for our envisioned solution.

Given that a solution in its entirety is always going to behave differently than its perfectly developed components it becomes important to factor in the external interactions to its environment.

Because new beginnings are magical...

If we are to engage in this sort of environmental analysis in the interdisciplinary team, whether in form of a workshop or online, using already existing software, the perceived barrier to working on the knowledge about connections is already overcome. We merely need to stay on the external observatory plane. And suddenly it’s all fast and easy: What exists in terms of environment, users, use-cases? Which relationships, which requirements are directly needed for an envisioned solution through these artifacts? What kind of relationships already exists in between elements of the environment? Which broader use cases, modes of operation and indirect requirements result thereof?

Each connection which we recognize and describe, whether inside, outside or intersecting one of the systems boundaries has a clarifying, almost romantic nature to it. We are starting to understand the complexity of the system together.

If they haven't surfaced by now, the search for the systems parameters follows. The behaviour of the system solution in regards to the environment is directed along, and can be optimized later using these parameters.

The requirements for a solution are created based on these connections.

Step 2: Enjoy your stay on top

We are now in possession of documented knowledge. We understand the connections between the topmost systems layer and the systems context. We circled our problem and then carefully approached our solution, being careful to involve all relevant disciplines. And we formed a network of relationships between the elements of our system context.

Diverse system layers with lateral connections in between formed. All within a common language. Recognized complexity.

And: lack of knowledge; We can gather the overview over what knowledge we are not in possession of from our whiteboards or visualizing programs. Which connections are validated? Which aren’t? We know, unhandled holes in our knowledge result in dangerous ignorance. What risks are we then creating by not investigating in the areas where knowledge is lacking? How much hypothesis is allowed, and until when?

The ratio of knowledge to lack thereof is only indicative of quality or maturity of decisions if kept transparent. If this transparency is given the concrete developmental tasks appear. The further path emerges.

Many approaches would immediately turn to systems development (SE/MBSE) at this point. We will hold out even longer, to prevent the acquired systems overview from ending up as a photographic protocol, and our whiteboard from being wiped out and rewritten all too soon. We are not done with the introduction to complexity management. The list of stakeholder requirements is not enough for us. We need to work on them.

Step 3: Downhill is always easier. With clarity into systems engineering

Let us therefore walk back to the whiteboard and focus the connections. From the relationships between the requirements to our solution and the top-layer system parameters the first conflicts of interest (usually) emerge within our task. Stakeholder requirements are rarely specific and system parameters have associated areas, ranges. If we combine different system states along those ranges, we receive systems scenarios, which allow us to begin reasonable reductions of the solution space. To avoid conflicts of interest as soon as possible.

This way we can specify our system in a more concrete manner and describe the boundaries of our goal system. We are starting the work on the functional architecture, a first physical architecture, and the interface descriptions between the primary components.

In this next, lower systems layer we will repeat or search for lateral connections, use cases and system states, in the same way as we did with the systems environment on layer above. With the same goal of describing the critical systems parameters. Those again help us to uncover conflicts of interest, reducing the scope of solutions and to complete the system's specification.

During all of this, all these individual systems artifacts are always documented with the goal of distinguishing clearly between knowledge and risk, hypothesis and truths. And through this the next concrete design steps for the project manifest.

Step 4: QiD System-reviews as a companion on the further path

Depending on the intensity with which we work on the knowledge gaps and the relevance that the results from our different work packages or sprints have for the whole of the system, the interdisciplinary team should find together in "QiD System Reviews" and work on its quality of systems.

The QiD Systems Reviews are based on the connections described above in a kind of data model. Model in the sense of documented connections between artifacts and requirements, components, functions, parameters, risks etc., assigned to their elements and components from the environment and the system.

These connections enable us to go back from the detail plane, or the sub-systems, back to the integrated or systems plane at any time. Giving us the chance to understand what the effects of a change in a single component are in regard to the system as a whole.

In the further course of the project the system integration, test management as well as the technical risk management can be conducted on the base on these documented connections in model form, by adding those and other useful viewpoints to the model.

I cannot imagine successful development of complex systems without this kind of planned and sustainable work on the quality of the technical connections, first quality of knowledge, then quality of the solutions. I would even go so far as to claim it is endangering your success to start working without an approach for sustainable systems understanding. QiD is there to mitigate this danger.

This means in conclusion:

Using QiD, a complex development task is aided in such a way, that it enables an interdisciplinary team to:

- create a common understanding of the system, to gain clarity in the formulation of goals as soon as possible. Using this, a solution can be optimized, either during the current project or during a successor.

- describe secured knowledge about the technical connections as a scaling knowledge base for the next generation of systems.

- making the technical challenges visible in the form of risks, documented holes of knowledge or hypothesis, to aid in agile project management using the important tasks and technical questions. The crux is to be handled first anyhow.

- be in possession of the entire overview of the technical connections of the system in every project- or concretion phase, in order to be able to evaluate the impact of changes, in sub-disciplines or subsystems, on the system as a whole.

- facilitate technical risk management, appropriate for the encountered complexity, from the outset and over all disciplines.

QiD is new. New things necessitate new efforts.

An expected implementation of a systems solution, to be delivered as soon as possible, suddenly faces additional efforts needed for complexity management. But there is rarely any room in the project timetable to work on manageable complexity using abstraction and integration. It is much more often silently implied.

It is much easier to assign costs and efforts to the four project disciplines requirements engineering, technical risk management, task management and knowledge management. The compliance criteria are obvious there as well. Since the QiD approach has distinct interfaces to those four disciplines, the efforts only need to be distributed in a smart way.

Costs measured in time and resources: the initial effort of documenting (for example the whiteboard-sessions in a kind of software) and the willingness of the team to regularly spend some time on system connections in QiD reviews are to be considered as well. Additionally, a single person in the development team should be responsible for the ongoing documentation and organization of the reviews.

Effort in the extended use of software: Most companies are already using software solutions supporting the four mentioned project disciplines.

QiD artifact types like system layers, technical connections, knowledge, and lack thereof, work packages, requirements, etc. can also be described in the form of system elements, functions, features, issues, tasks, product characteristics, failure paths and risks. So far common

FMEA-, requirements management- or task management software solutions have been adequate for the integrated documentation of the artifact.