This is the third and final post of three blog posts about systems engineering for rapid innovation in a hyper-dynamic world. The first post introduced the subject; the second post discussed how to address each of the three systems—the system-of-interest, the enterprise system, and the external system—from the standpoint of rapid innovation. We conclude here with recommendations on how the systems engineer can proceed in such an environment.
Some Sample Strategies
In my role as a consultant and trainer, I hear a common theme from practicing systems engineers: they feel internal and external pressure to just jump in and move forward fast from day one. Teams often do not feel like they have the time to review, assess, and question the requirements given to them. They may be placed on a project that has integrated product teams, including detailed designers who are also being pressured to start work on day one.
What is the systems engineer to do? How do they ensure they are moving down a path to build the right system (i.e. a question of validation) while engaging detailed engineers and subject matter experts (SMEs) concurrently on day one?
First of all, I would suggest that this dilemma reflects a lack of engaged and competent leadership (i.e. a lack of courageous leadership), but as a systems engineer, you may have no say or control over this other than to be a thoughtful and wise voice that speaks up.
I personally have felt these same pressures working on cutting edge and novel systems at past companies. All I can tell you is how I attempted to address these situations. If you are absolutely pressured to “move” by management in an unwise direction, you may have to do your best to work within the system early on.
I’ve been on projects where I was told to let the SMEs know what they should start designing on day one before we even had resolved conflicting requirements. However, if you are reusing any technology or components, it is important at the outset to have the experts start some investigations. This will be time well spent. And, if at all possible, it is valuable to have a small systems engineering team working on the side to properly derive a consistent set of requirements aligned with customer needs.
Example 1: Gathering Buy-In
In one example, I was given a combination of incomplete, over-specified, and conflicting requirements on a project that had a super-aggressive schedule and budget. The way I dealt with this was: I spent a considerable amount of time working through the conflicts on the side while the rest of the team did some initial configuration trade studies. After I gathered all of my stakeholder inputs, I was able to present them back to the internal decision-makers and our business development team (that acted as a proxy for the outside customers), and show them that they were asking for an impossible solution. But rather than just pointing out the problem, I presented them with a possible solution, showing where we would have to manage scope and then address tackling additional mission scenarios and capability desirements through a series of future block upgrades.
At that point, I had the data and ammunition to address my management and show them where changes in the project direction should be made. In this case, there was buy-in to my recommendations on clear and reasonable scope definition as well as to the layout of a program to address additional desired capabilities through block upgrades at prescribed intervals. Working through this early, rather than just throwing my hands up and getting on board with the status quo, allowed the team to avoid surfacing these issues late, during integration and test, where fixing the issues would either be costly or impossible.
Example 2: Developing Mini-Specs
We did some other things on that project to move more quickly and engage the rest of our design team early. We developed what we referred to as “mini-specs.” Our systems engineering team identified the six most critical performance parameters based on our understanding of the system dynamics and utilization of an existing system analytical model. We then focused on developing allocations for those parameters to the subsystem level. I then had the teams collectively work to identify the 20 most critical requirements for designing each subsystem. We focused only on getting those close to right first so that the subsystems could move forward.
Did this introduce some risk? Absolutely. Since we didn’t have a complete system architectural model nor did we do a complete flow-down, there absolutely was risk introduced. However, it presented a clear compromise to the alternative of letting the subsystems design something in a vacuum. Our systems engineering team continued to work in the background to derive the proper traceability between our requirements at various levels and fill in our architectural model. As we filled in more and realized the allocations to subsystems that needed to change, we brought the subsystem engineers to the table and explained to them the need for the change.
Example 3: The Systems Engineering Dashboard
Another key concept that we introduced was the systems engineering dashboard for the project. This was a wiki page that included hyperlinks to all existing artifacts that represented sources of truth for various pieces of information. This became invaluable to the team, as often, designs were being developed on whiteboards in real time. As we captured details, we would have some artifact representing key decisions, system features, and attributes. At first, it might simply be a picture of the whiteboard uploaded to a repository. However, that was better than allowing the decision to fade differently into the minds of each member of the design team.
These are just a few examples—by no means a complete treatment. However, I hope they provide some context and inspire you to think about other ways to approach rapid innovation.
Summary
Systems engineering for rapid innovation is not just about moving fast. That is a fool’s errand, to be sure. In some cases, what I’ve described is analogous to a governor on a car: good systems engineering is limiting the speed of the team to something reasonable at a given time within the broader context. More important than pure speed is velocity: speed paired with direction. Good systems engineers help point the team in the right direction at the right speed.
Embrace the challenges. Be willing to probe-sense-respond not just with respect to the refinement of the definition of your system-of-interest but more broadly to your enterprise and development environment. Understanding your enablers and constraints in the larger context, while acknowledging that the enterprise continues to change and evolve, is crucial. Be willing to leverage your past understanding and knowledge, but also be willing to accept new feedback information and adapt. Try new approaches. Conduct mini experiments with variations to your systems engineering processes. If they work, keep them and incorporate them into your repertoire. If they do not, note why, and then move on and try something else.
Remember: there is no defined endpoint. There are only the states of ahead and behind.
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.
