Product development can be a difficult undertaking. The following blog post illustrates how the Advanced Systems Engineering Pillar "System Mastery" can be used to simplify the development process. You will get a clear understanding of the four capabilities "Manage your Requirements", "Think in Systems", "Integrate, Verify, and Validate", and "Keep Costs on Minimum" all why planning a Mount Everest expedition.

The four pillars of Advanced Systems Engineering

In our previous blogposts you already got an insight into the AMeLie project. We introduced you to the four key pillars of Advanced Systems Engineering and gave you an insight into the “Context & Customer Understanding” and “Process Efficiency” pillars. In this blog post, we look at the next Pillar which is called “System Mastery”.

Img.1: To achieve great things it takes teamwork and a systematic approach

System Mastery

Problems can seem huge and overwhelming. Tasks impossible and too complex. Developing a new product, but not knowing where to start. These are all everyday challenges. But how can we master them? The four Capabilities of System Mastery give us the skills to handle these challenges. Huge problems become manageable problems. Confusion during the product development process fades away and becomes clarity.

To show you that the size of the project does not matter, we will climb Mount Everest. Don’t worry, of course you won’t have to climb at dizzying heights and be exposed to the freezing cold. We’ll look at how to plan the optimal climb using “Manage your Requirements”, “Think in Systems”, „Integrate, Verify, and Validate”, and “Keep Costs on a Minimum”.

What do I actually want to achieve – Manage your Requirements

So now we have set ourselves the goal of climbing Mount Everest. But what does that actually mean? First of all, we need to be clear about what we specifically want to achieve. Do we want to complete the expedition in a certain time? Do we want to be the fastest? Do we want to do research along the way, or do we just want to get to the top without any other specifications? All of this must be clarified at the beginning in order to know exactly what we are preparing for and what is needed to achieve our goal.

The same applies to the product development process. Right in the beginning we must figure out exactly what the customer wants. We have to consider how customer wishes are translated into product requirements and how we plan to fulfill the customer’s wishes with our product. If this is not done, delays and budget overruns can occur as the project progresses or something is developed without value for the customer.

It therefore becomes clear that we must be aware of what we want to achieve and what is needed to achieve our goals when we start a project. Since we are still somewhat inexperienced, we decide that our goal is to reach the summit of Mount Everest safely and with all our team members. To achieve this goal, we need to think about equipment, food, logistics and accommodation for safe stopovers.

How to turn a big task into a manageable task – Think in Systems

At first, our project may seem huge and overwhelming. But what’s the best way to start? A good next step is to cut the whole thing into smaller slices. If we look at our project from a Systems Engineering perspective, we can break it down into different System Levels. On System Level 1 (Overall System) we have the objective of safely reaching the summit. We now divide this objective into individual sub-systems and are thus at system level 2. Here we now have the division into categories, we have control over, e.g. equipment, supplies, logistics and accommodations. These individual sub-systems can now be divided further and further until we finally arrive at the lowest system level, the component level. There is also a System Level above System Level 1, the System of Systems level. Here we think about how our project will interact with the ecosystem involved. How can our expedition be combined with the usual daily business? Can we use the expedition to get in contact with other teams that are also planning an expedition etc.?

To illustrate the break down into sub-systems, let’s take the equipment as an example. If we want to break this down to the next level, then we can say, that we need equipment to sleep, eat, secure, navigate, etc. These sub-systems can then be further divided into the respective individual equipment components.  With our requirements in mind, we can think about which individual components we need to reach the goal of safely arriving at the top.

It becomes obvious that by dividing our project into different system levels, it becomes much more tangible and manageable. Instead of dealing with the big picture, we can work our way up step by step and go from component to sub-system to the overall system.

How to put it all together – Integrate, Verify, and Validate

We now know that we want to reach the top of Mount Everest safely and have divided our project into sub-systems. Now it’s time to procure the necessary resources. But if everything is divided into individual components, how do I make sure that everything fits together in the end? What if the backpack ends up being too small and the equipment doesn’t fit? What if one of our team members gets us shoes that he particularly likes the looks of, but are absolutely unsuitable for a Mount Everest climb?

To prevent these problems, it is important to have test cases for each system level to verify whether the respective components or sub-system can meet the requirements we set at the beginning. In our case, we can test the nice looking shoes on a smaller expedition to see if they keep us safe.

To make sure that we can integrate the different system levels, we take the individual equipment components of the different equipment sub-systems and put them into packing cubes. After that we try to integrate all of the packing cubes into the higher system level, our selected backpack. If this is not possible, we have to look at the respective components again and find an alternative solution.

In addition to meeting the requirements, we must validate whether the equipment is also suitable for us. Shoes that offer safety but lead to blisters after a few hours are not suitable despite meeting the requirements.

Through Integrate, Verify and Validate, we ensure that components and sub-systems meet the specified requirements, everything is compatible and suitable for our target project or our customer.

Do I really need the expensive stuff? – Keep costs on a Minimum

Of course, we can’t just blindly buy equipment and go over our budget. We must think about which solutions offer us the best price-performance ratio. Do I really need the expensive rope? If you want to be safe probably yes. Do I need the most expensive outdoor food? Not really there are cheaper options that also nourish you. For some components it may be important to go for a high-quality solution, for others the less expensive option is also suitable. It is important to carefully evaluate the different solution concepts while having the requirements in mind and then decide.

System Mastery – a way to climb Mount Everest

With the help of these four capabilities, you can manage complex problems and bring clarity into the development process. It is important to translate stakeholder requirements into system requirements and to have precise guidelines to work towards. We can slice a big task into smaller tasks that are manageable by breaking down the whole system into sub-systems and components. Through Integrate, Verify and Validate we ensure that we are on the right track throughout the development process and through cost-benefit analysis we ensure that the budget is not unnecessarily exceeded.

Now nothing is holding us back anymore and we can head for the summit!