Systems Engineering: An insurance policy against risk
Systems engineering is the business of avoiding future problems, but it requires up-front planning and continuous verification of the plan to stay on track (I know none of you readers have ever been associated with a runaway project –a project that’s out of control, over budget, and behind schedule). When you look to the causes, you can see the domino effect… it often traces back to some poor systems engineering and system architecture decisions made early in the lifecycle. Which made me wonder why people who had cost us so much money were still here. The answer: the distance between the decision and the consequence made it difficult to make the connection to the cause (and contributes to insane design behavior in programs–see blog on that topic).
As Simon Ramo (that’s the R in TRW) said, “all the really bad mistakes are made the very first day of the project”. I would suggest they are actually made before the first day. Many of you may work in organizations that bid for business. You may have been involved in a Request for Proposal (RFP) response and realized that all the important system architecture decisions were made before you’ve even won the business.
The problem is that you often only have a nominal amount of money to do the systems engineering and architecture trade studies during the compressed response cycle. Because you don’t get the resource commitment up-front to do it right, many “seat of the pants” decisions are made that set you up for a project runaway before the project even starts. Given that you don’t win everything you bid for, you also have a “catch-22” in that no real systems engineering money is allocated until you’ve won the business, which of course by then is too late.
In the past, to help resolve this we did management presentations to try and get the systems engineering resources we needed early enough in the project lifecycle to make a difference, but we were always derailed by questions surrounding “what’s the cost/benefit of systems engineering?” Put another way, what is the benefit of systems engineering or “how many engineers and pencils will you be able to do without if we give you this money for up front systems engineering?”
These types of questions and this type of thinking always frustrated me (and still does). Like insurance, systems engineering is in the business of helping you avoid future problems rather than saving the development money you are currently spending. Systems engineering is an insurance policy against future risk.
The value of a cross-domain integrated product architecture, integrated requirements, etc., that systems engineering produces is in the future because of the problems/costs it avoids versus the money it saves today. But organizations with billions in recalls and groundings today (take your pick among the headlines) would agree it would have saved lots of money in current spending if they understood the cross-domain impacts and issues earlier in the product development process
To help explain this, I wrote a case study that I experienced early in my career that I still share with management teams. It’s the story of a ‘simple’ humidifier, titled “Allegory of the Humidifier: A case study of Return on Investment in Systems Engineering.” It’s a true story, beginning with a napkin sketch, that highlights the long term costs of short term cost-justification thinking while giving you a laugh and will tempt you to send me your “oh yeah, I can top that” story.
Feel free to share this systems engineering story with your management. Perhaps you can avoid your own humidifier story on your next project.
About the blogger:
Mark Sampson is a systems engineering evangelist working on integrating systems engineering into the product development process.
