Is everyone who engineers a system a systems engineer?

DAVID - This is a topic that seems to come up a lot, and generally when there is professional friction occurring at work.  Hardcore design engineers, when schedule-crunched or technically challenged, will find ways to subtlety or not-so-subtlety imply that Systems Engineering is hardly its own discipline, and organizations that treat SEs as such are burning money investing in glorified project managers.  Others in leadership take it a step further and flat-out say, everyone who is an engineer on this project/program is a "systems engineer".

BRIAN - I agree with practically everything you said, and I think it's frustrating to say the least.  First, at a very basic level, there wouldn’t be an academic discipline with many universities offering Systems Engineering degrees, up through the doctorate level, if Systems Engineering wasn’t meeting a real need.  That would mean any technically oriented person could just pick up the concepts in a week-long seminar.

DAVID - Which is ridiculous...

BRIAN - But beyond that, just the anecdotal evidence for so many projects with cost and schedule overruns provide proof that, left to their own devices, a team of engineers working on the same system aren't using high level systems thinking enough.

DAVID - Oh, wow.  What do you mean by that?

BRIAN - Okay.  One of the responsibilities of a bona fide SE is to manage emergent behavior, and to spend the time upfront to minimize the impact of technical and programmatic issues occurring later on.  Very rarely do a bunch of really smart, but narrowly focused design engineers, have the opportunity to think across all the interfaces and take the long view on the development life cycle.

DAVID - Well, isn't that what a oligarchy of chief engineer(s), program managers, and project schedulers are supposed to be doing in an Integrated Product Team environment?

BRIAN - It could seem that way on the surface, except each one of those people are focused on one piece of the whole and accountable for that.  A project or program manager is chiefly concerned about schedule and resources.  The Chief Engineer is concerned with assuring technical maturity and hitting performance requirements.  A scheduler manages the IMS and does not have to be held accountable for cost or performance.  There's no one that really has the time or energy to analyze the impacts that cut across all of those issues holistically.  Each of them will generally sub-optimize within their area of responsibility.  It should be the Systems Engineer, or Systems Engineering team that has the pulse of all of the above, and for all points of the development lifecycle, not just the very next design review or program milestone.

DAVID - Many people smarter than I have been on this line of thinking for awhile, and yet, I still find quality organizations with people in high places just not buying into this as a credible fact wholesale.  And this is despite the data about return on investment.

BRIAN - Well the studies are sure out there, and I am not sure why it's not being utilized a lot more.  Maybe decision makers are just not seeing it or not wanting to see it.  But I can point interested individuals to a bunch of really good and credible sources.  Turns out the sweet spot is around 12-14% of the program budget on real, concentrated Systems Engineering effort brings about the best return on investment, with adjustments to account for the quality and maturity of the SE team.

DAVID - So, you don't think it's simply a matter of spending that money as overhead across the organization just training up "real" engineers to do more of this upfront, system wide analysis?

BRIAN - I think that just dilutes those individuals' contributions on the things they need to care about, which are incredibly valuably in their own right.  Every Engineering discipline should be an expert in their own arena.  I wouldn't ask an Electrical Engineer to design the ergonomics of test equipment and expect the same level of thoroughness.  That's not to say that everyone could not benefit from understanding systems of systems thinking - everybody should understand how their decisions affect the whole, and it would sure help interface management and practical daily interactions at work.  But there are efficiency gains to be had with a group dedicated to the whole, and even more if the emerging Model Based System Engineering (MBSE), and the broader Model Based Engineering environment (which advocates for connecting and sharing information across many engineering models and tools to ensure consistency and appropriate traceability), gains traction across all technical industries.

DAVID - I'd like to think we'd be able to help a lot on both those fronts.

BRIAN - Yeah, and there are known deficiencies in the approach and application, but we're just getting started with MBSE and SysML, in particular, are still young and continuing to grow and adapt.  I’m a huge proponent of working with the standards agencies, such as the Object Management Group (OMG) to help improve the SysML standard and correct existing known deficiencies for the entire systems engineering community.  However, these improvements take time – they must be vetted and approved by stakeholders which include both end users and the tool vendors. They then must be codified in updates to the specifications and then finally implemented by the tool vendors.  This takes a substantial amount of time. Nymbysys can help customers address the known issues in the SysML standard now through language extensions, libraries and other customizations. We are excited to tackle those deficiencies head on and deliver on the promise of the discipline to a wide swath of companies looking to decrease their development costs, schedule slips, and performance noncompliances.