Posted by j.laird on 18 January 2021 - 9:30am

Herman Bruyninckx via Wikimedia Commons

By SSI Fellow Dr Edward Fisher, Firmware Development Group, RADAR Electronics, Leonardo MW Ltd.

As projects grow, the complexity of their implementation also grows. In this blog, I will examine best practices and methods that will allow you to handle complexity in both the technical and managerial domains of your project. More specifically, I will overview a technique called “Systems Engineering”. This can be used to provide an architecture for the management of a project. This technique directly helps when the project would otherwise become far too complex for an individual to manage alone. Sadly, this is a topic that is often poorly discussed during PhD programs (if at all), yet it is crucial for both academic and industrial careers.

To start, you may have questions such as: How can I manage multiple collaborators? How do I keep a project coherent when different technical disciplines need to communicate? How can I ensure that the outcome is fit for purpose? How to keep track as the volume of technical detail becomes unmanageable? Perhaps, like I was, you are wondering what methods teams in industry use to create something truly complex. Many of you incorporate reading as part of your day job, however we can each envisage scenarios in which we must manage a project but the volume of technical documentation, factors involved, work to be done, and prior technical knowledge will quickly outstrip us.

If this is the case with your project, a proposal you are aiming for, or the likely direction your career is going, the following “Systems Engineering” structure may provide a suitable method for managing project complexity while ensuring verified project outcomes.

Systems Engineering: An Introduction

Systems engineering, at its heart, treats the system holistically. Rather than caring about implementation details, the project’s technical overseers (called systems engineers in industry) care more that the system can provide each of the functions it aimed to deliver. They view the project in an “implementation agnostic” manner and often from what others would call a “top-down” view. Top-down is however perhaps the wrong phrase to use here, as systems engineering makes direct efforts to look down each technical path that may be required, quantify the important factors and create a hierarchical list of functional requirements before any top-down implementation is started.

Tip 1: The Best System

While academia often focuses on high-performance, a crucial point to manage complexity is to identify the level that meets the project’s requirements, but “only just”. In other words, we must prevent the system from being over- or under-engineered, and instead be “just right”. This can be achieved by viewing your project not in terms of performance but in terms of performance-to-cost ratio. Here cost is not just financial, but also time and human resources. 

From an engineer’s perspective, performance may be the top speed of a car, while a scientist’s perspective would be the number of experimental data points and their levels of error. The point here is that too high a demand on the outcome of your project may in fact make it less likely to succeed. Perhaps obtaining such low-error measurements requires equipment that is too costly for the project’s finances. Or perhaps, designing a car to run at such a speed would require an extra six months. Either way, there is a point at which performance-to-cost ratio is manifest as the “best” achievable outcome, that the project can support, given its available time, financial and human resources.

Tip 2: Complexity as a Cost

As part of defining the “best system” that the project is able to support, we must also allow the complexity of implementation to be a cost factor. Superficially, complexity would manifest as being creeping project timescales or requiring increased human resources. However, complexity also acts in a non-linear manner as it often presents us with new work that must be done. This can present us with four particular issues:

1. New work, even if it is of the same type already being undertaken, requires time. As this wasn’t budgeted for, it forces the project to be late by default. Likewise, it may be difficult to quantify how much extra time is needed, or it may need work already performed to be amended, or worse, scrapped.
2. Even if it is a standard technical discipline, the new work that is required may not be within the skill set of the current staff members. If time cannot be allocated to allow for a learning curve, then new staff would be required to bring that technical discipline into the overall skills mixture.
3. If a new technical discipline is needed, the communications between the disparate technical disciplines needs to be managed. While a new engineer may be able to aid the situation, the reason for their inclusion would necessitate them being involved at the overall system-level so that they can provide ideas and consider the ideas of others. What must be avoided is a lack of communication over the traditional discipline barriers which prevents a solution or is a new source of creeping timescales.
4. The complexity of a design can be viewed as the number of interactions between disparate units. Therefore, increasing the complexity is akin to quickly increasing the number of interactions that need to be understood and tracked.

To avoid these issues, systems engineering spends significant time early in the project timeline. While the overall concept could be the top-level, systems engineering advocates that the feasibility of each technical branch is assessed. We aim to identify that “to obtain performance a, b and c, we will also need to work on x, y and z”. If you view this as a tree search you will get the idea that most unknowns are discovered, quantified and provided for during the project’s definition phase. 

Tip 3: Technical Depth vs Technical Breadth:

Considering a system from a holistic or top-down view, complexity manifests itself in two knowledge dimensions, technical depth and technical breadth. Here, diversity within the team pays off significantly.

1. As academic researchers, it is likely you have a high degree of technical specialism. This is highly suited for issues that are complex by the nature of the number of factors involved, the need for educated analysis or experience in the implementation of something niche and specific. This could be viewed as “problem complexity”.
2. However, to handle increasing overall project complexity, a range of different technical disciplines may be needed. This could be viewed as “system complexity”. To be able to manage effectively, a project lead needs to have a handle on some elements of each of the required technical domains, but only to the level needed to understand or to facilitate communications between technical specialists.

To manage a complex project, try to learn the language, common issues and technologies of each of the technical disciplines that may be needed. You may not be an expert in any but your own field, but know enough that you would be able to identify an incompatibility between the work of two different technical specialists. Perhaps a software engineer is talking to a physicist about code that needs to run in real-time. For the signal processing needed, perhaps real-time is simply not going to be possible without significantly less code. But perhaps a modest decrease in operating speed would be a suitable compromise. View yourself as knowing enough that you would be able to identify the areas of compromise, or at least be able to suggest it as an idea.

This is the first part of this blog post, see part two here.