MBSE

Adopting MBSE Part III: Developing a Roadmap to Successfully Adopting MBSE Within Your Organization

By |

This is Part 3 of a blog series covering a whitepaper titled,The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit these links for the rest of this series: Part I, Part II, and Part IV.

Developing a roadmap to successfully adopting MBSE within your organization

In this section, we provide a general approach or roadmap to be used in your company’s journey in successfully adopting MBSE within your organization. We say “journey” because that is what it is. Transforming an organization doesn’t happen overnight. There are a lot of pieces of the puzzle to address so it is important to take small steps and not try to do everything at once. Success includes addressing the key factors of success discussed earlier and define a roadmap. This journey could take several years depending on the size of your organization.

As stated earlier, the organization should form a dedicated MBSE Implementation Project Team with membership from each of the key organizational elements that have a stake and role in the adoption of MBSE within the organization. A general roadmap the project team can follow is shown in Figure 1:

Figure 1: Roadmap to Successful Adoption of MBSE

RELATED POST: The Real Intent of Model-Based Systems Engineering

01: Get Management Buy-In

As discussed earlier, 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 to adopt MBSE and move 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 doing 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 (Goldilocks principle discussed earlier).

02: Understand the Need to Move Toward a Data-Centric Practice of SE

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 it… 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.

The more effective the 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 how the change will benefit them. Changing culture is often met with opposition and existing stovepipes/silos often resist change.

To combat this opposition, determine which stakeholders are for and against the change and why. For each individual or group, identify their concerns and devise a strategy to get the change adversaries to become change advocates. Start with those stakeholders that have the most influence and convince them by addressing their concerns. The aid of other stakeholders may need to be obtained to help influence those that oppose the 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

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!

People at all levels must 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.

RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software

03: Access the Organization’s Current Practice of SE

To do this, they need to first assess the organization’s current state of practice of SE in terms of the ten areas of capability associated with data-centricity discussed previously. Table 1 shows an example of what the results may look like for organizations that are firmly rooted in a document-centric practice of SE. Sadly, this is the state of many of today’s organizations!

 

Visit these links for the rest of this series: Part I, Part II, and Part IV.

To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE

Lou Wheatcraft
Latest posts by Lou Wheatcraft (see all)