MBSE

Adopting MBSE Part IV: Use a Pilot Project

By |

This is Part 4 of a blog series covering a whitepaper titled, The Comprehensive Guide to Successfully Adopting Model-Based Systems Engineering MBSE. Visit Part I, Part II, and Part III.

04: Determine the Future State the Organization Needs to Be At

The descriptions made previously for each of the ten areas of capability represent the level of capabilities an organization should be at for a complete transformation from a document-centric to data-centric practice of SE. However, for each area, there is a range of capability levels, it is not just an either-or determination.

It is important for the enterprise to decide how, and to what extent, they are going to address each of the ten areas resulting in reaching the future state that is best for their organization. This decision must be based on the needs of the enterprise while being scaled to the level of rigor that allows the system development life cycle process activities to be performed by the projects with an acceptable level of risk and that will result in the needed outcomes.

It is important to realize that this journey towards practicing SE from a data-centric perspective can be made in a series of small steps. The enterprise doesn’t have to jump to a completely data-centric practice of SE at the beginning of their journey.

Some organizations may want to start with an electronic (vs. hard copy documents) requirement capability which supports allocation and traceability as well as can manage requirements (and other work products) across all system lifecycle process activities. This will help link requirements to the stakeholder needs from which they were transformed, to design outputs, and to verification and validation work products. The project can identify measures to track system development activities and identify and manage risks. The managers can then add the capability to use non-language-based diagrams as single entities without the underlying data, e.g., functional flow diagrams or context diagrams, and link the requirements to those diagrams. From there, the capability for analytical modeling can be added where the various diagrams, requirements, and other work products are visualizations of underlying sets of data (only if there is some benefit to be gained from doing so.)

The future state for each of the ten areas of data-centric capability can be expressed as a range of capability levels (CL) (e.g., 0 – 3). The MBSE Implementation Project team can define what capabilities are in terms of each of these levels. For each of the ten areas of capability, the level defined represents a goal which the project team will strive to meet along with any specific measurable objectives for each goal.

RELATED POST: MBSE Is Not SYSML

05: Identify the Gaps

Once the organization has assessed the current state of their practice of SE, they will need to address each of the ten areas in terms of what level of capability is best for the organization.

From an IT infrastructure requirements perspective, it is best for the projects to communicate the end state envisioned, so their IT department can provide the IT infrastructure and PM and SE toolsets that are scalable to be able to handle the needs of the organization for the envisioned end state.

Central to successfully implementing the levels of data-centric capabilities the organization needs to be at involves the selection of the SE tools that will be used. What capabilities are needed from an SE toolset depends on the product line, its complexity, green-field vs brown-field products, issues the organization is having and wants to address, and the workforce knowledge and experience.

Organizations need to understand what data and information best meets their needs and which set of SE tools they need to work with and manage this data. SE tools are like any other software application…one size does not fit all. The SE toolset that is best for an organization is the toolset that meets the organization’s requirements management, systems engineering, and modeling needs. Consider the outcomes needed as a result of using SE tools and the ROI resulting from these outcomes.

Table 2 shows the ten areas of capability, the present state (P) and future state (F) in terms of capability level as defined by the MBSE implementation project team. The difference between the present state and future state represents a “gap” which the project team will fill as part of their project.

 

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

06: Develop Action Plans

For each of the ten areas, the MBSE Implementation Project Team will develop an action plan. Each action plan represents a sub-project that will have its own mission statement, goals, objectives, measures of success, needs, requirements, budget, schedule, and stakeholders. Actions that will need to be addressed for each area include: 

  • Developing enterprise, business management, and business operations level policies, processes, and procedures needed to implement SE from a data-centric perspective.
  • Providing requirements to the IT department concerning the IT infrastructure needed, so these capabilities can be realized.
  • Selecting and procuring PM and SE toolsets that support the level of data-centricity decided on.
  • Training their managers and systems engineers in the use of the PM and SE toolsets and processes from a data-centric perspective. 

07: Implement the Action Plans

The project team will also need to assign a priority to each area of capability.It is important to realize that this journey towards practicing SE from a data-centric perspective can be made in a series of small steps. 

Successfully providing the capability to practice SE from a data-centric perspective requires three key things to be addressed: people, process, and tools. All three are highly dependent. One of the first areas that should be addressed is the selection of the SE tools that will be used by all the product development teams. Tool selection will be influenced by the data governance policies, data and information management procedures, product line, culture, and work force. The product development process will need to be updated to reflect the levels of data-centricity decided on as well as the SE tools selected. The product development teams will then need to be trained in the processes and SE tools.

Use a Pilot Project

There is an old saying “The devil is in the details.” To bring the people, process, and tools together, the MBSE Implementation Project Team should choose a pilot project. A pilot project can be used to demonstrate the benefits and ROI of adopting MBSE and moving towards a data-centric practice of SE. It will allow the organization to gain an understanding of what works (provides value, ROI), what doesn’t, what is liked, what isn’t liked, and tailor the processes to best fit the needs of the organization. 

This pilot project can develop an example PMP, SEMP, and IMP that can be used as a template for other projects. A project ontology and schema can be developed that can also be reused by other projects. If the product that is the focus of the pilot project is highly regulated, the pilot project can import standards and regulations into the SE toolset, enabling their reuse for future projects. Armed with the lessons learned from the pilot project, the organization can fine tune their various processes, policies, and work instructions to help the organization move closer to achieving their mission, goals, and objectives to practice SE from a data-centric perspective. 

Several key steps include: 

  1. Develop a practical process that implements the chosen SCL. The process needs to fit the product line, domain, and culture of the organization. The implementation needs to be tailored to the project. Don’t try to follow a process developed by a tool vendor for some other organization or product line. 
  2. Invest in training in the proposed chosen processes and SE tools. 
  3. Pick a pilot project to apply the process and assign the grass roots data-centric SE advocates to that project. 
  4. Define and use measures so metrics can help document the ROI can be clearly communicated concerning the agreed-to level of data-centricity. 
  5. Show management how measures and metrics maintained within the PM and SE tools will help them better track the health and status of the project, enabling them to be better project managers and systems engineers. 
  6. Encourage team members to be actively involved in organizations like INCOSE and join working groups whose members can aid the implementation process.
  7. Invest in an outside consultant who has a proven track record in implementing SE capabilities consistent with the chosen level of data-centricity and chosen SE toolset. Often tool vendors will be able to provide that person or persons who can work with both the MBSE Implementation Project Team as well as the product development pilot project team members. The tool vendor will be able to help integrate their tool into the organization’s IT infrastructure as well as help the pilot project team members tailor the tool to their needs and be readily available to assist when issues come up. 

Once the pilot project is completed successfully (an assumption), the project can be used as an example for future projects. The core grass roots folks can be spread out among other projects and mentor other project managers and systems engineers and train them and their teams in the concept of practicing SE from a data-centric perspective and in the use of the chosen SE toolset. 

In many of the cases where adoption has been successful, there has been both advocacy at the top as well as a strong grass roots support that has gradually gained acceptance across the organization, but typically only after one team has proven success. 

Parting Thoughts

Success is possible if the organization addresses the key factors of success discussed above. Of particular importance is understanding the overall puzzle in which the MBSE puzzle piece must fit as well as understanding the importance of all the pieces concerning the various areas of data-centric capabilities that make up MBSE. 

Developing the roadmap discussed as well as using a pilot project are key to success. Since one size doesn’t fit all, an organization needs to assess the data-centric capabilities that best fit its domain, product line (degree of complexity), and culture. The level of capability an organization establishes needs to be tailored to the size and complexity of systems developed by the organization, whether small, medium, or large projects. 

Based on the needs of the organization and level of SE capability they choose, they will need to choose the appropriate SE toolset, update their processes, and train their people in these tools and processes. 

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.  

Thank you for joining us for tips on successful MBSE adoption!

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)