Adopting MBSE Part I: Key Factors Associated with Successful MBSE Adoption
|
This is Part I 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 II, Part III, and Part IV.
Introduction
In a previous paper, we discussed key questions concerning Model-based Systems Engineering (MBSE) including what MBSE is, its true intent, why organizations should adopt MBSE, and the benefits. If you haven’t read that paper, it’s worth taking a look.
We made the point that the goal of an organization when adopting MBSE, is to move from a document-centric to a data-centric practice of Systems Engineering (SE) to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed — along with a model of all the system life cycle process activities, resulting in artifacts, and their underlying data and information.
This paper will go into more detail as to key factors associated with successfully adopting MBSE, what it means to practice SE from a data-centric perspective, and provide a methodology to define a road map tailored to your organization resulting in the successful adoption of MBSE.
RELATED POST: The Real Intent of Model-Based Systems Engineering
Key factors associated with successfully adopting MBSE
Sadly, the attempts of many organizations to successfully adopt MBSE often end in failure. The process of adopting innovative technology like MBSE and moving toward a data-centric practice of SE can be considered to be a project in its own right. There have been numerous studies and reports concerning factors of why projects fail, and factors associated with projects that succeed. When adopting MBSE, these factors must be considered. Organizations that are able to successfully adopt MBSE and move to a data-centric practice of SE address the following key factors:
01 – Getting Corporate Level Management Buy-In and Support – Success Starts at the Top!
In an earlier paper, we discussed issues associated with a document-centric approach to product development of today’s increasingly complex, software-centric products along with the benefits of adopting MBSE from a data-centric perspective to address these issues. There must be a project champion that can clearly communicate these issues and benefits at the corporate level in order to get buy-in across the organization.
A key consideration when getting this buy-in is how these issues and benefits are communicated. The adage “know your audience” is important. A common mistake when approaching higher-level management is using terminology that does not address their needs in a language they understand. When getting buy-in concerning the company adopting MBSE, you must clearly communicate to them what MBSE is and how the organization will benefit in terms of outcomes they can relate to. Giving them a demonstration of a specific tool using a lot of technical jargon can result in them quickly losing interest. They are interested intangible outcomes of a proposed solution that addresses business-related issues (problems): less overhead, decreased time to market, higher quality, decreases in post-launch issues, fewer issues associated with a product being approved for use, increased profits, rising stock prices, and a growing company. They want to understand how adopting MBSE will result in these types of outcomes.
02 – Forming a Dedicated Project Team
Rather than leaving it up to individual project teams to each attempt to adopt MBSE, a corporate level dedicated MBSE Implementation Project Team (IPT) is needed. For smaller organizations and startups this IPT might be a single person. MBSE is just one puzzle piece in the larger set of organizational puzzle pieces. To be successful, the larger, integrated puzzle must be considered to ensure the MBSE puzzle piece will fit. Other puzzle pieces include data governance policies, information management plan procedures and work instructions, information technology (IT) infrastructure (networks, internet, clouds, applications, computing devices, etc.), the product line, product development processes, procurement processes, company culture, workforce, etc. A dedicated project team can deal with possible issues in all these areas from a corporate, holistic perspective across organizational silos enabling a successful adoption of MBSE, helping to ensure the MBSE puzzle piece can be integrated within the overall corporate puzzle.
RELATED POST: Webinar: Eliminating Barriers to MBSE Adoption with Jama Software
03 – Involving Key Stakeholders
The various stakeholders involved in adopting MBSE must be included. These stakeholders must not only include the users, but other stakeholders that will be affected by the adoption of MBSE including those that will benefit, those involved in the activities required to adopt MBSE, and those from enabling and supporting organizations. Referring back to the puzzle analogy, stakeholders must be included that represent each of the above-listed puzzle pieces. Each stakeholder has expectations that must be addressed by the project team along with key drivers and constraints a successful project must consider in order to achieve a successful outcome.
04 – Defining The Problem, Opportunity, Outcomes, Needs, and Requirements at the Beginning of the Project
The project team and stakeholders at all levels of the organization must be aligned to a common understanding of the problem/opportunity that is driving the adoption of MBSE, to a common mission statement, goals, objectives, clear outcomes, needs, and requirements. Like any other project, these must be defined and agreed to from the beginning so that there is a clear roadmap to success and well-defined outcomes against which success can be measured.
05 – Understanding the “Goldilocks Principle”
The Goldilocks principle is about doing what is “just right” – not too little, not too much. When adopting MBSE and moving towards a data-centric practice of SE, the project team must understand the needs of the organization, what it means to practice SE from a data-centric perspective, and develop a practical and feasible roadmap. Delivering an MBSE capability that is too little can result in stakeholder expectations not being met, disappointment, and a failure of project teams to successfully adopt MBSE. Going overboard and implementing more than is needed can be overwhelming, turning people off to the concept and again a failure of project teams to adopt MBSE.
This last point is especially important. “Just right” must be defined from a user perspective. The users are the product development project team members who will be conducting their project based on the processes and tools provided that will enable them to adopt MBSE for their project and move to developing their products from a data-centric perspective. They have expectations concerning being able to be more productive and effective. Meaning the processes and tools provided should not be viewed as things they have to do and use in addition to their job – resulting in more work; rather processes and tools they can follow and use that are an integral part of how they do their job – resulting in less work, a higher quality product with a shorter time to market. The new processes and tools enable them to deliver winning products: those that meet the needs of their customers, within budget and schedule, with the required quality.
From a user perspective the following attributes must be addressed within the processes defined and tools selected for use:
- Full functionality; does what is needed, nor more, no less
- Intuitive; easy to learn and use
- Easy and fast to implement
- Enable collaboration between team members, no matter their geolocation
- Enable traceability of data, information, and artifacts across the system lifecycle
- Enable change impact assessment across the system lifecycle
- Reduces the time to define and manage needs and requirements
- Supports verification and validation planning and execution
- Tailorable to the organization’s product line, work instructions, and workflow
- Helps ensure compliance with standards and regulations
- Helps manage risk across the lifecycle
- Enables management to track project status across the lifecycle
Visit these links for the rest of this series: Part II, Part III, and Part IV.
To download the entire paper, visit: Whitepaper: The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE
Senior Consultant & Managing Member at Wheatland Consulting, LLC
Lou is an expert in systems engineering with a focus on needs and requirements development, management, verification, & validation. Lou provides consulting and mentoring services to clients on the importance of well-formed needs & requirements helping them implement needs & requirement development and management processes, reviewing and providing comments on their needs and requirements, and helping clients write well-formed needs & requirements. Lou is a long-time member, past chair, and current co-chair of the INCOSE Requirements Working Group (RWG), co-author of the INCOSE Guide for Writing Requirements, and co-author of the RWG Whitepaper “Integrated-data as a Foundation of Systems Engineering."
Latest posts by Lou Wheatcraft (see all)
- Adopting MBSE Part IV: Use a Pilot Project - January 20, 2022
- Adopting MBSE Part III: Developing a Roadmap to Successfully Adopting MBSE Within Your Organization - January 13, 2022
- Adopting MBSE Part II: What Does It Mean to Practice SE From a Data-Centric Perspective? - January 6, 2022