Systems engineering is the business of avoiding future problems, but it requires up-front planning and continuous verification of the plan. 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.
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.
To help explain this, I wrote a case study quite a while ago that I still share with management teams. Based on a true story, and beginning with a napkin sketch it highlights the long term costs of short term cost-justification thinking. It’s the story of a ‘simple’ humidifier, titled “Allegory of the Humidifier: A case study of Return on Investment in Systems Engineering.”
Feel free to share this systems engineering story with your management. Perhaps you can avoid your own humidifier story in your next project.
About the blogger: Mark Sampson is the product manager/evangelist working on integrating systems engineering into the product development process.