Part I of this series of posts speaks to the first two of the five steps to improving systems engineering: shape your process to converge on a design solution; and maintain a systems perspective throughout your design process.
Part II of this series speaks to the third step: shape your process to converge on a design solution.
In the previous installment in this series (Part II), we explored the critical problem of producing a coherent and consistent design in the face of dangers arising from fragmentation of the design team across engineering disciplines and domains. Through connected engineering, we saw a path to a design that comes with a reasonable assurance that all of its engineering challenges have been addressed and that no untoward surprises await as the result of a fragmented approach. This connectivity is the responsibility of systems engineering and must be accounted for in your model, your environment, and your approaches. In this post, we close the series with the final two steps—making our design process agile and responsive, and accounting for the entire operational environment in which our design will “live.”
STEP 4. Make your practice agile and responsive.
Customer demands are dynamic because our customers serve dynamic missions in dynamic environments. Their problems are often only partially known to themselves at the outset and may change during the design cycle. Some solutions may even create additional problems. Your design must be able to accept change and reflect its impacts in real time.
Agility in solution is critical to developing real solutions for real problems. Even if the definition of the original problem remains stable throughout the life of the design process, the appearance of implementation issues requires design responses. If the understanding of the problem changes in response to additional information or stakeholder input, the need for such responses is magnified.
The risk of not being responsive to developing or changing requirements is particularly critical in an environment where the customer’s requirements are dynamic. Here, requirements that were initially anticipated accurately given the situation at the time of their development, may have simply changed in response to external factors in the customer’s environment or emerging design issues.
As customer needs change, so do their requirements. These new or altered requirements must be captured and tracked into the design for inclusion in the solution. Where this is done separately, every new or changed requirement must be manually reflected into each of the tools/models being used in the design. When done in isolation from the greater design team and involved disciplines, the challenges are magnified, creating misalignment or requiring serialization of the design effort. This slows the process and raises the risk that these requirements will be lost or mistranslated.
Whether the challenges are due to changing or developing requirements, the design process must be agile enough to account for changes in design features or directions. The system must answer the needs of the stakeholders at the time of delivery, and increasingly this requires agility in real time in the design process. The disciplined approach of relating requirements to behavior and behavior to implementation in a logical way allows for agile responses to emergent issues.
This happens most effectively when the system design is created in a single model based on a proven systems metamodel that recognizes and enforces the relationships of requirements to behavior and behavior to the implementation architecture. This ensures that any changes made to the model at any point in the design process are captured and reflected throughout the model in proper relationship to the elements involved. In this way the design team can move with agility, speed, and confidence without the risk that something will be overlooked or misapplied in the process of making changes to the design.
STEP 5. Be sure that your process accounts for the entire environment within which the system will function.
The failure to consider the system in which the system solution will live often results in unintended consequences. But unintended consequences are not the only cost of neglecting this perspective.
The days of true “clean sheet” or “unprecedented” design are numbered. Systems do not exist in a vacuum. Any process or product has impacts on and is impacted by, the world around it. We cannot afford to abandon the surrounding systems in an attempt to construct a slice of our world from scratch. Technology now changes so rapidly that innovation and change in any one area must be accommodated within the context of the surrounding system environment—its “context” system. The linkages to legacy systems and technologies are a very real part of almost all system designs.
This is true, for example, in the area of process design and improvement. It is most often not realistic to think that your customer can improve their processes in ways that require them to alter their entire business enterprise. The redesign of existing processes or the introduction of new ones must take into account the surrounding processes and technology. Businesses must be cognizant of the requirements levied on any design by their operating environment.
That requires your model to present an accurate mapping of the system boundary and a complete accounting for the system interfaces. Anything less will result in mismatches and disconnects that will greatly reduce the value of the system solution. In addition, such issues will have to be dealt with in a rework posture incurring what are most often substantial non-budgeted costs.
The key to avoiding these risks and costs is a disciplined approach yielding a complete and accurate model. The mapping of the model should include the relevant portions of the system environment which form the system boundaries and the interfaces that provide the “fit” for the system into that environment. Just as speed and agility in the design process rest on a single design model that integrates all aspects of the design within the framework of a proven systems metamodel, the comprehensive understanding and modeling of the system design set in its context is virtually impossible without the metamodel to provide the structure and discipline needed to manage the complexities of such a task.
In this series, we have discussed five steps that can be taken to improve any systems engineering process:
- Adopt a convergent process.
- Maintain the systems perspective.
- Minimize the risk arising from fragmentation.
- Make the process agile and responsive.
- Account for the entire context environment.
In a sense, these steps are fundamental, but like many fundamental concepts, they are often honored only in the breach and not in the observance. A renewed intentionality about these five steps will make any systems engineering practice more efficient and effective using the strategies we have discussed.
