“Model-based systems engineering will make us faster, better, and cheaper.”
“What hard number return on investment (ROI) we can expect from adopting MBSE?”
The first is a statement of the sense we get when hearing advocates talk about the benefits of MBSE. The second, a question we hear from organizations looking for the clear monetary justification before making an investment. Though well intentioned, both take us off track. Far too often we take the wrong approach when selling – and assessing – model-based systems engineering.
Positioning MBSE as making an organization faster, better, and cheaper is an appealing approach. In changing the way we capture, represent, and communicate information in the engineering of a system, we can project benefits in speed, quality, and cost simply through improved understanding and increased fidelity of engineering analysis. However, arguing all three at once is generally interpreted as conflicting with the so-called iron triangle of project management which asserts we cannot simultaneously improve schedule, capability, and cost. Whether or not it is true that MBSE can make your team faster, better, and cheaper on an effort (and it is true under certain conditions), making this argument as a bald assertion is simply not credible. It sounds like a silver bullet, and we are well-conditioned to reject silver bullets.
If we change perspectives and look at assessing the value of MBSE, asking for the ROI is a reasonable request. Adopting MBSE requires investment in tools, training, and mentoring if a team is to maximize the benefits of model-based approaches, and when looking at investments, it is fair to inquire about the return. Unfortunately, while we can make well-reasoned subjective arguments, the objective data simply doesn’t exist to defend a specific ROI, regardless of the number offered. Moreover, we shouldn’t expect it, and we can’t afford to wait.
For over 50 years, we have looked for the hard ROI business 
case for systems engineering. The fundamental financial argument for systems engineering is cost avoidance – what is the cost of an error never encountered? It is only in the last five years that we have seen two strong studies that establish the business case for systems engineering in an objective, defensible manner: The Guide to Lean Enablers for Managing Engineering Programs published by MIT, PMI, and INCOSE and The Business Case for Systems Engineering published by the Software Engineering Institute at Carnegie Mellon and NDIA. Both documents make the business case but neither attempts to argue a specific ROI.
Though we would like to believe that comparing MBSE to traditional, document-centric practices may prove easier and therefore allow a monetary calculation, there simply isn’t sufficient data to support this. Beyond a few narrow areas (specification production and change impact analysis to name two), there are too few data points and too many variables. The size and complexity of projects vary as does the experience of the team and capabilities of the organization. Perhaps even more important are the differing objectives in adopting MBSE. In the same way that systems engineering should always be tailored, MBSE should be tailored as well. Whether one is prioritizing quality, time to market, risk reduction, responsiveness to changing requirements, variant management, cost, or a number of other business concerns – all of these will fundamentally influence the implementation of MBSE and any corresponding statistics. Given this, we cannot expect the data necessary to support hard, broadly applicable ROI numbers and should be skeptical of any numbers offered.
So as we look to make the case for model-based systems engineering and assessing the benefits, what approaches should we use?
Identify – and address – pain. Psychologists (and salespeople) will tell us that eliminating pain is a far stronger motivator than pursuing benefits. Understand where known challenges exist – on past programs completed or on programs ongoing within the organization – and focus on the negative business impact of these issues. With the pain and corresponding impact identified, frame how MBSE will effectively mitigate or eliminate altogether the problem and paint the positive business implications that follow.
Focus on specifics. Rather than making broad, amorphous claims on a number of fronts, focus on specifics. A good MBSE implementation plan focuses on one primary dimension, be that quality, speed, or any number of other business objectives. Because of secondary and tertiary effects, we will certainly see positive impacts in other areas as well, but treat these as bonuses. A classic story in selling MBSE tells of how a team sold MBSE purely on the cost of change impact analysis through the life of the program. Based upon the size and complexity of the program, they were able to estimate the number of change requests. Running a focused MBSE pilot program, they developed an estimated cost to conduct the change impact analysis for a given change. Rather than arguing all the potential benefits of MBSE, the team simply presented the projected cost savings in this one area (which far exceeded the requested investment in MBSE). As you can imagine, it was a compelling business case.
Emphasize the lifecycle. Although our focus should be on lifecycle cost and performance, too often we drift back and talk only about the design phase. Emphasize the lifecycle instead, remembering that the decisions made during early design commit over 80% of the lifecycle cost. Improving the quality of systems engineering therefore simultaneously improves quality, cost, and schedule when looking from a lifecycle perspective. In addition, while a single source of truth may be valuable during the design phase, it becomes critical during through-life management of a system. Whether it is ongoing maintenance or upgrading the capability of a fielded system, good knowledge management as promised by a quality MBSE approach has a high payoff throughout the lifecycle.
Argue by analogy. Sometimes a simple analogy helps anchor an argument. No one today would favor manual drafting over computer-aided design (CAD) software. No one would attempt modern integrated circuit design by hand. (It’s simply not possible.) Why attempt systems engineering without the right tools to help augment the systems engineer, capture our data, present our representations, and perform analyses in the most effective manner? If the response is that all you need is Microsoft Word to write documents, take a step back. At that point, the problem isn’t selling MBSE. The problem is the understanding of systems engineering itself.
Move the conversation from cost to value. If I visit a car dealer and the salesperson comes out as I am looking at a convertible, she doesn’t immediately point out the cost. Instead, she asks me to sit in the car and visualize driving down the road on a sunny day with the top down. In doing so, she is focusing my attention on value. We might consider this to be manipulative, but our long-term satisfaction is not governed by the cost paid. Instead, it is the value received. Too often as engineers we focus on reducing cost. In this case, we should take a lesson from our colleagues in sales and highlight value instead.
Sell technologies only to technologists. As engineers, we are often fascinated with the way things work, and we obsess on the details. As the old joke goes, ask an engineer what time it is, and he will tell you how the watch is made. When evaluating investment in MBSE, the wise manager or executive understands that they are assessing an organizational change initiative. To them, it doesn’t matter what the underlying technology is nor do they care about the specific capabilities. Instead, they care about the benefits, the risks, and how those risks will be mitigated. As systems engineer Dave Walden once counseled during a presentation, “Remember the three be’s – be bright (know what you are talking about), be brief (recognize the value of everyone’s time), and be gone. If they want to know more of the details, they will ask.”
Apply the ABC’s of Selling. In Glenngarry Glen Ross, Alec Baldwin emphasizes the ABC’s of selling – always be closing. Those are the old ABC’s. In today’s world of information where we are always selling ideas, Daniel Pink (To Sell is Human) identifies the new ABC’s of selling – attunement, buoyancy, and clarity. Be attuned to the needs and perspectives of the individual to whom you are selling and clearly demonstrate the benefits from their perspective. Be buoyant and uplifting – people are more likely to follow your lead. And be clear, always speaking in concepts and language that aligns with making it as easy as possible for your audience to understand your ideas and messages.
As we seek to highlight the benefits of adopting model-based approaches, we are selling ideas. We should take a lesson from our colleagues in sales and recognize the most effective way to frame this change – addressing pains, identifying specifics, emphasizing the lifecycle, and focusing on value. At the same time, we should be cautious to under-promise and over-deliver to maximize the likelihood of success for ourselves, our project, and our practice. That is truly the best way to sell MBSE.
