This is the second in a series of three blog posts about systems engineering for rapid innovation in a hyper-dynamic world. The previous post introduced the subject; this post wraps up the discussion started in the last post on how to address each of the three key systems from the standpoint of rapid innovation. The next post concludes with recommendations on how the systems engineer should proceed in such an environment.
In the previous blog post, we discussed the reality of the world we live in today. It’s fast paced and ever changing. We discussed why systems engineers must adapt their mindset to this reality to be effective and relevant in today’s world. We then began looking at our world from three viewpoints: the system-of-interest, the enterprise system, and the external system. We discussed the first two in the last post. We pick that discussion back up with a focus on the third system: the external system.
External Systems – Ever Morphing and Evolving Factors
The external system—the broader context in which our system of interest operates—is ever changing and evolving. Most systems today must operate within a broader system-of-systems ecosystem consisting of a heterogenous combination of system elements, most of which were not designed for mutual interoperability. The internet-of-things and other trends towards interconnectivity have accelerated. The number of interfaces external to our system-of-interest not only continue to increase, but they also change dynamically over time. Customers may also determine novel ways to use a system that transcend its original design. This also happens over time. Our understanding of our desired future state, from our vantage point today, most certainly will not be the same as from our vantage point tomorrow (Figure 1).
Figure 1: The future state is a constantly moving target.
We must embrace and accept that the vector pointing us toward our goal will need to periodically change direction and magnitude. We must reassess our current state and our desired state regularly so that we can ensure that we are properly steering our ship toward the intended destination. Sometimes we will need to speed up; sometimes we will need to slow down. Other times we will need to speed up or slow down. If we do not reassess at all, we will undoubtedly miss our target completely. If we do not reassess until late in the project, it is more likely that we will have to make larger and more disruptive changes in magnitude and direction to get to our destination.
Some Guidance for Rapid Innovation Systems Engineering
Systems engineering that provides value in a nimble, rapid innovation environment must take a “no nonsense” perspective. The organization must be incredibly clear in purpose and objectives, willing to fail quickly, willing to try new approaches and adapt whenever necessary. It must be self-reflective and honest. It must never rest or dwell on past success, as the game tomorrow will undoubtedly be different than the game today. Results can be its only dogma.
For guidance in this perspective, we can look to some of the most innovative and disruptive companies during their early years. Viewed from a marketing lens, we can still glean a lot of insights from the marketing philosophy documents of Apple and Nike (Figure 2).
Figure 2: Marketing Philosophy Summaries for Apple and Nike
These companies knew they were playing an infinite game, and their marketing philosophy reflects that. They embraced the uncertainty and leaned into the challenge. They were self-aware and understood they needed to be both reflective and adaptive.
These marketing summaries provide great context for how to view the business and products from a market and external system perspective. As systems engineers, we also need to look for ways to accelerate smartly within the boundaries of the system-of-interest development project. We need to be willing to try out-of-the box or non-standard approaches in the probe-sense-respond model to see what works and is effective.
One approach that has proven successful in certain circumstances is to lean more on a “build-test-fix” methodology. Sometimes it is quicker and less costly to prototype and test a concept rather than to develop detailed models and analyze it. This is also in clear alignment with the probe-sense-respond model necessary for the design and development of complex systems.
SpaceX has used this approach effectively to accelerate past their competition and become not only a market leader but also a clear innovator. Their approach has been to utilize initial analysis only to “get close” to the right solution and then prototype and test to get to the final solution. They found this to be quicker and less costly than the alternative, legacy approach of spending much more time trying to analyze and design a system to the detailed level first. Not only is it quicker and less costly, but it is also a great way to develop a deeper understanding of the reasons why a system behaves the ways it does. This deeper understanding can lead to more expansive and useful institutional knowledge that the enterprise can continue to apply to future problems and projects.
However, there should be a healthy tension between planning and design ideation. We must be aware of a number of biases that can impair our judgment. The first is availability bias. When we begin to prototype, it is easy to fall into the trap of thinking that we just need to fix what’s wrong with that particular technology or configuration. We tend to want to just make that configuration work. We may become personally attached to the concept and want to will it to work. Sometimes we need to step back and acknowledge that if there are significant issues with the test results, a different configuration may need to be investigated and could be the better path forward.
The second bias is sunk cost. After we spend time and money on a possible configuration, we can get attached to it because we don’t want to think of all that effort as being wasted. We need to acknowledge that the effort is not in vain; it is just as valuable to know what doesn’t work. That helps guide us in the right direction. Recall that Thomas Edison “failed” approximately 10,000 times in his experiments, which ultimately led to the successful development of the light bulb. Finding out what doesn’t work is as valuable as a successful test or experiment.
With these examples in mind, we can develop a set of guidelines or rules of thumb for nimble systems engineering within the context of our three systems.
The Systems Engineer’s Credo for Rapid Innovation
- Know what type of problem you are trying to solve, and use an approach appropriate to that problem.
- Keep the end objective front and center at all times. Always understand the end goal.
- Understand the needs of your program, customers, users, and other stakeholders as well as or better than anyone else on the project team.
- Question requirements and constraints given to you. You must understand the underlying “why” and rationale.
- Do not accept requirements blindly. Assume nothing.
- If the requirements do not align with the understood usages and mission, speak up and work to resolve the discrepancies early.
- Do not waste any time designing the wrong system. That is the greatest waste of all.
- You and your team cannot do everything. Be explicit in what you are not going to do.
- Be professional, knowledgeable, and honest at all times. If one does not develop and maintain a stellar reputation, it does not matter how good your work is—you won’t be trusted.
- Communicate clearly.
- When a decision is made, take the time to document it and the rationale behind it. Revisiting the same decision multiple times later due to lack of time to document it right the first time creates more waste.
- Provide clarity to the rest of the team on the information that represents the baseline design at any time. Easily updatable summary pages like wikis are great for this.
- Identify and understand the risks. Take the acceptable ones.
- Failure along the way is to be expected. It is a critical part of accelerated learning.
- Failure is OK; just don’t fail the same way twice.
- Be willing to adapt.
- Be conscious of availability bias and sunk cost bias. Know when to let go and move on.
- Quality matters. Strive for it. Fight bureaucracy that isn’t providing value. Be an example of how to do it a better way.
- Pick and utilize tools that enhance your team’s innate capabilities. Do not accept or use tools that create additional bureaucracy or non-value-added overhead.
- In the context of MBSE, use tools and their capabilities where they provide clear value. Where they do not, determine the most efficient and effective way to move forward even if it is by using another tool or technique.
- Do not model for the sake of modeling. Modeling should inform and provide clarity to the development process. Clearly understand the purpose and objectives before starting. Modeling just for the sake of modeling is waste.
- Value the development of elegant systems over elegant models.
Systems engineers today are being asked to develop increasingly complex systems-of-interest within enterprises and external environments that are also rapidly changing and dynamic. Requirements developed on day 1 may be irrelevant before the project has concluded. The “game” we’re playing is an infinite one. If we do not understand that, we will get overtaken by a competitor who does. By acknowledging these realities and adapting to them, we can still navigate today’s world with skill and finesse.
To learn more about how systems engineering can help you and your enterprise navigate a complex world, check out this page on STRATA methodology—a layered approach to success.
