Adopting MBSE: Challenging the Status Quo

This blog contains excerpts from a whitepaper titled, The Comprehensive Guide to Successfully Adopting MBSE, written by Lou Wheatcraft.

Adopting MBSE: Challenging the Status Quo in Product Development

For product development teams to successfully implement a practice such as model-based systems engineering (MBSE), it requires the willingness of an organization to perhaps change processes and even tooling. Often, companies choose to stay with the status quo, but at what cost? Here’s a look at how adopting MBSE might help your teams, and the cost of not adopting MBSE.

Understand the Need to Move for Change

What is the Risk of Staying with the Status Quo?

For the MBSE Implementation Project Team to be successful, management must recognize the need to change. How can management be convinced? Three words – RETURN ON INVESTMENT (ROI)!

Think about these questions:

What has been the impact of the current, poorly executed product development efforts?
What is the overhead associated with the current document-based approach?
What are the current quality issues facing the organization that is catering it to profits: Failures, recalls, returns, warranty costs, lawsuits, negative reviews on social media, decreasing market share?

The ROI argument usually works with management especially when they can be convinced that by investing in a data-centric practice of SE tailored to the organization’s needs, the overall product development process, product quality, time to market, and profitability can be improved as discussed previously.

What is the ROI of Adopting MBSE?

To entice anyone — especially an entire organization — to make a change, proving ROI on the resource investment is key. Here are some key points to consider:

The more effective the Systems Engineer (SE) processes, the less rework and fewer cost and schedule overruns.
By moving to a data-centric practice of SE, the probability of achieving a competitive advantage can be improved by removing obstacles to being able to deliver products on time, on budget, and that meet or exceed customer and quality expectations.
From a cultural perspective, the personnel responsible for product development and will be most affected by the change must be shown, and how the change will benefit them.

Visit our interactive content page for ROI Calculators and more!

Combating Opposition to Change

A good process is not one that is something people have to do in addition to their job, rather it is one that helps people do their job more effectively. – LOU WHEATCRAFT

Get Team Buy-In

To get buy in from the product development teams, the MBSE Implementation Project Team must:

Understand what problems the product development teams are having and show them how moving to a more data-centric practice of SE will address those problems and make their job easier than the current document-centric approach. If the change results in more work or makes communication harder, the battle will be lost. For example, the lead engineer or project manager may already be over their head and working 50–60-hour weeks. Requiring them to learn how to use a new tool or set of tools and implement a new process may be too much of a load for them to bear! However, if they are provided with a dedicated person that has the training, knowledge, and experience in the new processes and tools to help implement the changes and train other team members, they will be much more receptive. They will also be much more receptive if this results in them having to work fewer hours and having fewer crises to deal with each day!
Be convinced of the utility of the changes, how the changes result in a better product and result in less rework for them. Frequently the reason project team members are working long hours is because they are always fighting fires, going from one crisis to another, which resulted from the lack of the proper SE tools, processes, data, and information in the first place! The culture needs to be changed from one of firefighting to one of fire prevention. As time passes, they will become advocates for the changes that have been made and welcome further change.

The MBSE Implementation Project Team’s mission statement will be something like: “Improve our product development processes by adopting MBSE within the organization by moving from a document-centric to a data-centric practice of systems engineering.” Along with this mission statement, they will need to define a set of specific goals and objectives along with measures of success. Once defined, they will need to get agreement from management on these goals, objectives, and measures.

Get Management Buy-In

Project success is dependent on having a high-level, C-suite project champion and getting management buy in. A major challenge for the project will be convincing management and other key stakeholders that it is time for adopting MBSE and moving from a document-centric to a data-centric practice of SE and knocking down the walls of resistance. Some common reasons for them not wanting to move to a data-centric practice of SE include:

“We have been doing product development using our current processes for years, why should we change?”
“Implementing SE from a data-centric perspective may work for others, but not for us.”
“This all seems very complicated, we don’t have the knowledge, experience, or tools.”
“Our current SE work products, like requirements, are managed in an RMT. FFBDs, and other diagrams we are currently using are models, so aren’t we already adopting MBSE?”

“It is too expensive to procure the needed SE toolset, maintain the tools, and train our people to use those tools.”
“We don’t have the budget to incorporate SE from a data-centric perspective at this time.”
“The expense and associated process to get new SE toolset installed on organizational computers is too great.”
“We would have to make signification IT infrastructure upgrades to accommodate the additional volume of data and performance requirements of the new SE tools.”
“We deal with the development of classified systems; controlling access and maintaining security will be too difficult.”

Sound familiar? Often the pushback can be attributed to a lack of understanding the risks associated with the current state of the organization, understanding the benefits of moving toward a more data-centric practice of SE, and what level of SE capability is appropriate for the organization.

Adopting MBSE: The Road to Success

To inspire a shift from a document-centric to a data-centric practice of SE in your organization, it’s vital to show both teams and management the value and expected ROI in doing so. Moving away from a current way of doing things isn’t always an easy road, but the risks of staying with the status quo are often great—and the rewards for changing processes and culture are often even greater.

An organization will be successful in practicing SE from a data-centric perspective when it is considered to be the “gold standard” for system development within the organization. However, the road to success is long — it takes very strong, unwavering leadership and experience to get this done right. It is human nature to try to push back and say that it isn’t possible, but it is.

Author
Recent Posts

Jama Software

Subject matter experts from Jama Software provide guidance and best practices on requirements management, test management, compliance and regulation, risk management, and complex product and software development.

Adopting MBSE: Challenging the Status Quo