By Jorg Largent

Are we being sufficiently deliberate and disciplined in our approach to advocating the systems engineering process? Within the community of systems engineering professionals there is widespread agreement as to the essence and value of the systems engineering process. Our disagreements, while passionate at times, are mostly disagreements of style rather than substance. Outside the community, however, the audience changes — oftentimes skeptical or unsure, not fully appreciative of how the systems engineering process is beneficial to them or to their goals. With this in mind, one consideration is that those within the profession need to tailor their advocacy to helping others by tailoring their advocacy to match the audience. Or, to use a comment from within the Intelligent Transportation and Transit Systems (ITTS) working group in late 2008: “Help SE on the inside translate SE lingo to customer lingo.” Tailoring would then, at least in part, consist of:

1. Translating the lingo and
2. Showing the value of the systems engineering process from the perspective of the listener.

It would appear that there are three general audiences, each with unique needs based on their unique perspectives, needs that will determine the tailoring:

1. The executive,
2. The project leader or program manager, and
3. The implementers.

Using broad terms, these three audiences can be defined as follows:

1. The executive is responsible for the overall health and productivity of the organization. The executive is responsible for ensuring that the organization has the wherewithal to successfully accomplish the projects being pursued by the organization. And while the “profit motive” is different in the commercial world than it is in the non-commercial world, the executive is responsible for returning desired value to the stockholders or stakeholders, as the case may be.
2. The project leader or program manager is responsible for the execution of a given project and is the “designated worrier” for performance, cost, and schedule, although there are times when performance is subordinate to cost and schedule.
3. The implementers can be identified most easily with requirements development, requirements management and the requirements “V.” It is in this arena that the engineers of varying levels of specialization are most fully engaged. However, it should be noted that the term “implementers” is much broader than the focus of engineers and the requirements “V” because the term “implementers” also includes maintainers and operators, to name but two.

Assuming that these definitions are adequate for further discussion, the question then becomes “how?” How should an advocacy be tailored to meet the needs of these respective audiences? An advocacy for the systems engineering process should be in the language of the audience. An advocacy for the systems engineering process complement the values of the audience. This second point can get rather dicey. However, general values as broad as the terms above can be used as a basis for an equally broad look at the value systems a systems engineering process advocate might face.

1. The executive needs to see that following the systems engineering process contributes to the overall health and productivity of the organization. The executive needs to see that taking advantage of the systems engineering process will result in increased or surer profits for the owners or stakeholders of the organization, however it might be that “profit” is defined by the owners and stakeholders.
2. The challenge facing the project leader or program manager might be summed up as “herding cats” – balancing cost and schedule, along with balancing near-term goals and tasks, against the long-term objectives and goals of the project.
3. The implementers represent the widest spectrum of possible audiences for the systems engineering advocate. Even within the sub-spectrum of engineering there is a sufficiently wide variety to illustrate the potentially daunting nature of the communications challenge. While the primary focus on implementers is on engineers, there are more professions and functions than just engineering, as noted above. And while the requirements “V” discussed above is a clever tool to visualize the implementation of applied physics, the values of other professions a need to be considered, and those professions need to understand the process so that they can appreciate how the systems engineering process values their inputs and products.

Starting the Transition from Broad Generalities to Application: Complications

The transition from the generalities above to application, as with the transition from sophomore physics to upper division applications, is complicated by the challenges of the real world.

Perhaps the first challenge faced by the systems engineering advocate is to prove a negative. There are no identical, side-byside projects in which the only difference is the application of the systems engineering process. The on-line INCOSE “Systems Engineering Handbook,” (v. 3.1), Figures 2-3 “Committed Life Cycle Cost against Time” and 2-5 “Cost and schedule overruns correlated with systems engineering effort,” illustrates the value and benefit of the systems engineering process. But the illustration can be viewed with skepticism by those who are shy of the necessary investment and paradigm shift.

An added, and complicating, dimension to the challenge facing the systems engineering advocate is the fact that the roles and even the players themselves can change, a significant consideration regarding the project manager and the implementers over the life cycle of the project. Maintainability, as used in some airplane systems, can be used as an illustration. In the early stages of a project the focus is in the definition of and decomposition of the maintainability requirements into the design of the system. Later, “tech order verification and validation,” to use some Air Force terminology, occurs, which is followed by the operations phase of the life cycle. At this latter stage of the life cycle, “maintainability” has become routine and anticipated activities are being accomplished by the maintainers.

The Metrics/Value Proposition Sub-Group of the Intelligent Transit and Transportation Systems Working Group, in its October 13, 2009 meeting, commented on some of the challenges. Linda Martinez of SYSTRA Engineering commented that a problem to be overcome was that some people assumed that they already do systems engineering when in fact they do not, at least not completely. She considered that there was a need to sell to a whole organisation including specialists in other engineering fields and in non-engineering fields, such as quality, management, planning, and architecture.

In a similar vein, the “systems engineering” answer with which most systems engineering advocates would be comfortable is not always the correct answer under all circumstances. If the organization gains the most profit from inefficiency and if the customer (or customers) is the most satisfied when dealing with inefficiencies, then an off-nominal approximation of the systems engineering process (a de jure or du jour variant) might be sufficient.

Real-time pressures at critical junctures can result in decisions based on expediency. Performance, often being of particular interest during the initial selling of a project and during audits towards the end of a project, is sometimes sacrificed for cost and schedule. The analysis of new risks, as they arise in the heat of battle, can be minimalized.

A metric of success, particularly in communicating at the executive level, is the investment – time and money – an organization makes in the systems engineering process. However, an executive who subscribes to the value of the systems engineering process and is willing to invest in the necessary training and paradigm shift may have second thoughts if there is a risk of competitors poaching employees once the successful paradigm shift has occurred.

Another metric of success is codification. This is particularly the case as organizations become larger and as projects become more elaborate and complex. Codification too, however, has some risks. A well-written procedure is worthless if it is not followed (a point which couples back into whether or not an organization is willing to invest in training). As with almost anything, codification is vulnerable to the common mistake of thinking that if a little bit of something is a good thing, then a lot is better. Indeed there may well be a tipping point at which an organization’s procedures pass through necessary and sufficient, and continue the “more is better” growth until codification becomes calcification. Codification carries the risk of “following procedures” replacing the original mission or goals of an organization. Carly Fiorina, a former CEO of Hewlett-Packard, illustrated the point at The Leadership Summit August 7-9, 2007, hosted by Willow Creek Association.

The discussion above is not comprehensive. Rather it is intended to provide a snapshot of one of the challenges faced by those of us in the systems engineering profession. For another perspective, see the article above from the first October 2009 speaker meeting. Comments and differing perspectives are welcome. Please send your comments to Jorg Largent, This e-mail address is being protected from spambots. You need JavaScript enabled to view it .