Adopting MBSE Successfully

Guest Blog by Lou Wheatcraft of Wheatland Consulting, LLC

In my previous paper, “MBSE: Moving to a Data-Centric Practice of Systems Engineering,” key questions concerning Model-Based Systems Engineering (MBSE) were addressed, including just what MBSE is, the true intent of MBSE, why organizations should adopt MBSE, and the benefits of adopting MBSE.

The point made was when adopting MBSE, the goal of an organization is to move from a document-centric to a data-centric practice of systems engineering and realize the real intent of MBSE. From this perspective, the true intent of MBSE is to develop, maintain, and manage a data and information model of the system being developed, along with a model of all the system lifecycle process activities, resulting artifacts, work products, and their underlying data and information.

This paper goes into more detail about key factors associated with successfully adopting MBSE within your organization, what it means to practice systems engineering from a data-centric perspective, and provides a methodology to define a roadmap tailored to your organization, resulting in the successful adoption of MBSE.

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 systems engineering can be considered a project itself. There have been numerous studies and reports concerning factors why projects fail and factors associated with projects that succeed. When adopting MBSE, these factors must be considered. Organizations that can successfully adopt MBSE and move to a data-centric practice of systems engineering address the following key factors:

1. Getting Corporate-level management buy-in and support: Success starts at the top! Previously, I discussed issues associated with a document-centric approach to product development of today’s increasingly complex, software-intensive systems, 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 to get buy-in across the organization.

A key consideration when getting this buy-in is how these issues and benefits are communicated. The old saying, “Know your audience,” is important. A common mistake when approaching higher-level management is using terminology that doesn’t address the needs of higher-level management 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 in tangible outcomes of a proposed solution that addresses business-related issues: less overhead, decreased time to market, higher quality, decrease 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.

2. Forming a dedicated project: 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. 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 plans, procedures, 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 and helping to ensure the MBSE puzzle piece can be integrated within the overall corporate puzzle.

3. 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 people that will benefit from those involved in the activities required to adopt MBSE and those from enabling and supporting organizations. Referring to the puzzle analogy, stakeholders must be included that represent each of the puzzle pieces listed above. Typically, many of these stakeholders are within a variety of organizational silos which focus on individual puzzle pieces. Each stakeholder has concerns and expectations that must be addressed by the project team, along with key drivers and constraints that must be considered to achieve a successful outcome. Often there will be “political” considerations concerning each silo that must be addressed concerned with how the adoption of MBSE will affect the siloed organization’s performance, budget, and resources.

4. 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 from a corporate perspective 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. A key consideration is that the focus is optimization at the integrated corporate level of the organization. As such, some of the organizational elements (silos) may need to be sub-optimized and give up some individual control and resources. As Spock in Star Trek stated, “The needs of the many outweigh the needs of the few.”

5. 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 systems engineering, the project team must understand the needs of the organization, what it means to practice systems engineering 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 causing failure of project teams to adopt MBSE. It is also important that any well-defined process must be able to be tailored to the needs of individual projects. Thus, the “just right” Goldilocks Principle may be different for different projects within the organization. Some projects may benefit from the use of language-based modeling and for others, their needs may be met with a robust Requirements Management Tool (RMT) that allows data and information to be captured within the tool and traceability established across the system lifecycle of all artifacts and work products.

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 develop 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 and a higher quality product with a shorter development time. The new processes and tools must 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, no 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.
• Reduce the time to define and manage needs and requirements.
• Support verification and validation planning and execution across the lifecycle.
• 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.

What does it mean to practice systems engineering from a data-centric perspective?

Successfully adopting MBSE and moving toward a data-centric practice of systems engineering is much more than just acquiring and using a specific tool or set of tools or focusing on the use of a specific type of model. As stated previously, MBSE is not just about the development of SysML or other language-based models nor just practicing model-based design. MBSE is itself made up of puzzle pieces, all of which contribute to the successful adoption of MBSE. To be successful, the following ten areas of capability associated with data-centricity must be addressed. Each area represents a level of capability an organization needs to aspire to practice systems engineering from a data-centric perspective and realize the benefits of doing so.

1. Holistic Product Development: A key part of data-centricity is taking a holistic view of product development and managing data and information within an integrated/federated environment. The focus is on multidiscipline, collaborative, and project teams (e.g. IPTs). As discussed earlier, many organizations still operate in organizational silos, with team members loyal to their specific silo rather than to the project team. When issues occur, the tendency is to blame those in other silos.

Each silo often has its own processes, specific tool sets, data, and artifacts. Often the data and information are generated independently from those in other silos and are not in a form to enable sharing. This can result in inconsistencies, correctness, completeness, and currency issues of the data maintained in these artifacts. When moving toward data-centricity, organizations must have a holistic view of system development, minimizing the silos, encouraging collaboration, and improving communications not only between team members but between different tools used to generate and maintain data and information. Rather than treating Systems Engineering as separate from Project Management, projects must integrate both sets of functions such that there is a single project team that does both functions.

2. Manage Product Development Across the Lifecycle: Rather than having tools that are specific to a given organizational silo, a key characteristic of data-centricity is that related data and information that represents lifecycle activities and associated artifacts can be linked resulting in “digital threads” that link related information together across the product lifecycle. This linkage enables project team members to work collaboratively and establish traceability between needs, design input requirements, system analysis artifacts, diagrams, models, architecture, design, system verification artifacts, and system validation artifacts. Traceability aids in change impact assessment across the product lifecycle to ensure completeness, correctness, consistency, and currency of the data and information and resulting artifacts.

3. Enterprise Level Data and Governance Policy, Processes, & Procedures: Because of the dependence of not just the project teams but the overall organization on electronic forms of data and information and increasing threats associated with the security of this data and information, enterprise-level policies, processes, and procedures concerning data governance and information management must be defined, implemented, and enforced.

4. Project Level Data and Information Management: Within the context of the enterprise-level data governance and information policies, each project must include the specific implementation of these policies within their Project Management Plan (PMP) and Systems Engineering Management Plan (SEMP). Because of the importance of managing the project’s data and information, the project is encouraged to develop and enforce a project-level Information Management Plan (IMP). Other supporting plans (e.g., needs and requirements management plan, system integration, system verification, and system validation plans) need to comply with the data management policies within the higher-level plans for both the project and enterprise.

5. Master Ontology: Terminology and language are key to successful communications not only between team members but between tools. For a given enterprise, an enterprise-level ontology (data dictionary and glossary) must be developed to clearly define specific terminology and relationships of various terms used within the organizational silos and projects. This is critical when there are product lines, multiple project teams, and the need to share data and information between current projects, share data and information across organizational silos, as well as reuse data and information for future projects. Within the enterprise-level ontology, individual project teams can define their project-specific ontology consistent with the enterprise-level ontology. This is a key consideration for the “digitization” of the organization.

6. Master Schema: Here the word “schema” is used to describe how the data and information are organized and managed within individual tools and associated databases. It includes the naming of individual data and information items, defining relationships between data items, and the import and export of data and information. From both an enterprise and project perspective, it is important to define a master schema so that the systems engineering and project management tools within their toolset are compliant to enable data integration, shareability, and reuse.

7. Use of attributes and associated measures: Data centricity enables the project to define and use attributes that can be used to manage project activities across all system lifecycle stages. For needs and requirements, attributes can include rationale, priority, criticality, source, owner, traceability, risk, maturity of needs definition, needs and requirements definition status, design implementation, system verification, and system validation, to name a few. Attributes can be defined to aid in reusability and product line management. Attributes can also be associated with key measures defined by stakeholders within their goals and objectives. These measures include key performance indicators (KPI), measures of effectiveness (MOE), measures of performance (MOP), key performance measures (KPP), technical performance measures (TPM), and leading indicators (LI).

Data representing these measures and attributes can be used within the systems engineering and project management tools to generate reports, dashboards, etc., which are used to better manage the project and system engineering processes and associated artifacts and work products providing managers near real-time status information and enabling them to identify and correct possible issues before they become problems.

8. Configuration Management: Adopting data-centricity, the project’s artifacts and underlying data and information are developed, analyzed, and managed holistically within the data and information model. Because the data and information are managed within the project’s data and information model, this model represents a single source of truth (SSoT) for the project. Rather than configuration control of each individual artifact represented by the data and information in the model, the project team can configuration control the model which represents the baseline state of the artifacts represented by the data and information in the model at any given time. “Visualizations” of the data and information in the form of various artifacts represent the baseline version of that artifact. Even when these visualizations are extracted as reports, the SSoT is still the data and information model from which they were generated.

Note: For many organizations, this is often their biggest challenge in that it requires the organization to redefine its concept of configuration management. However, as stated in the previous paper, configuration management of individual artifacts requires significant overhead in both cost and time to individually configuration manage individual documents as compared to managing the data and information model that is representative of moving towards a data-centric practice of systems engineering and project management.

9. Systems Engineering Tool Set: Data centricity requires projects to move beyond the use of common office applications: word-processing, spreadsheets, presentations, basic drawing tools, diagramming tools, and requirement-only management tools to define, analyze, record, and manage needs and requirements and other systems engineering artifacts. Rather, projects must transform their systems engineering process such that systems engineering artifacts are developed using systems engineering tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the systems engineering tools within the project’s toolset as well as shareable with the project’s PM tools.
When selecting specific systems engineering tools to be included in the project’s toolset, it is important that the project determine the types of information and methods of analysis that are needed based on their specific product line, culture, and workforce.

10. Project Management Tool Set: Data centricity also requires projects to move beyond the use of common office applications for project management (e.g., budgeting, scheduling, cost management, risk management). Rather, projects must transform their project management process such that most of the project management artifacts are being developed using project management tools that are fully compliant with interoperability and data sharing standards, are consistent with the enterprise and project ontology, stores the data and information consistent with the project’s master schema, and allows linking of data and information across lifecycle activities and resulting artifacts. This data and information must be managed in a form that is shareable between the project management tools within the project’s toolset as well as shareable with the project’s systems engineering tools. For example, Work Breakdown Structures (WBS) can be linked to Product Breakdown Structures (PBS) and physical architectures to enable the management of budgets, schedules, resources, and risks associated with each subsystem and system element within the integrated system physical architecture.

Developing a roadmap to successfully adopting MBSE within your organization

This section provides a general approach or roadmap to be used in your organization’s journey in successfully adopting MBSE. I say “journey” because that is what it is. Transforming an organization doesn’t happen overnight. As stated previously, there are a lot of pieces of the puzzle to address. 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 defining 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 IPT 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 the figure above.

1. 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 systems engineering and knocking down the walls of resistance. Some common reasons for them not wanting to move to a data-centric practice of systems engineering include:

• “We have been doing product development using our current processes for years, why should we change?”
• “Implementing systems engineering 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 systems engineering work products, like requirements, are managed in an RMT. FFBDs, Context Diagrams, and other diagrams we are currently using are models, so aren’t we already doing MBSE?”
• “Our project teams are already overworked; they don’t have the time needed to also do MBSE in addition to what they are already doing.”
• “Few of our people understand or know how to develop language-based models.”
• “For the type of products we develop, we see no value added to developing language-based models – all we need is a robust requirements management tool.”
• “It is too expensive to procure the needed systems engineering toolset, maintain the tools, and train our people to use those tools.”
• “We don’t have the budget to incorporate systems engineering from a data-centric perspective at this time.”
• “The expense and associated process to get a new systems engineering 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 systems engineering 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 of the risks associated with the current state of the organization, understanding the benefits of moving toward a more data-centric practice of systems engineering, and what level of systems engineering capability is appropriate for the organization (Goldilocks principle discussed earlier).

2. Understand the need to move toward a data-centric practice of systems engineering: For the MBSE IPT 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 eat into profits: Failures, recalls, returns, warranty costs, lawsuits, negative reviews on social media, and decreasing market share? What are the impacts on profitability due to the increases in time to develop the organization’s increasingly complex, software-intensive products? For these products that are highly regulated, what will be the impact on the enterprise if a product is not approved for its intended use? The ROI argument usually works with management especially when they can be convinced that by investing in a data-centric practice of systems engineering 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 systems engineering processes, the less rework, and fewer cost and schedule overruns. By moving to a data-centric practice of systems engineering, 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 who 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.

To get buy-in from the product development teams, the MBSE IPT must understand what problems the product development teams are having and show them how moving to a more data-centric practice of systems engineering 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 to 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, and 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, that resulted from the lack of the proper systems engineering 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 IPT’s mission statement will be something like this: “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.

3. Access the organization’s current practice of systems engineering: To do this, they need to first access the organization’s current state of practice of systems engineering in terms of the ten areas of capability associated with data-centricity discussed previously. The table below shows an example of what the results may look like for an assessment of the current state of an organization that is firmly rooted in a document-centric practice of systems engineering.

Sadly, this is the state of many of today’s organizations!

4. Determine the future state the organization would like to be: The descriptions made previously for each of the ten areas of capability represent the level of capabilities an organization should aspire to for a complete transformation from a document-centric to a data-centric practice of systems engineering. 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 suited 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 lifecycle 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 toward practicing systems engineering 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 systems engineering at the beginning of its journey.

Some organizations may want to start with an electronic (vs. hard copy documents) requirements management capability with the capability to support allocation and traceability and the capability to manage the requirements and other work products across all system lifecycle process activities, linking requirements to the stakeholder needs from which they were transformed, to design outputs, and to verification and validation artifacts. The project can identify measures to track system development activities and identify and manage risks. They 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 IPT can define what capabilities are needed in terms of each of these levels. For each of the ten areas of capability, the level defined represents a goal that the project team will strive to meet along with any specific measurable objectives for each goal.

5. Identify the gaps: Once the organization has assessed the current state of their practice of systems engineering, 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 project management and systems engineering 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 systems engineering tools that will be used. What capabilities are needed from a systems engineering toolset depends on the product line, its complexity, green-field vs. brown-field products, issues the organization have and want to address, and the workforce knowledge and experience.

Organizations need to understand what data and information best meets their needs and which set of systems engineering tools they need to work with and manage this data. Systems engineering tools are like any other software application…one size does not fit all. The systems engineering 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 because of using systems engineering tools and the ROI resulting from these outcomes.

The table below 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” that the project team will fill as part of their project.

Table 2: Example Gap Analysis

6. Develop action plans: For each of the ten areas, the MBSE IPT 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 systems engineering 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 project management and systems engineering toolsets that support the level of data-centricity decided on.
• Training their managers and systems engineers in the use of the project management and systems engineering toolsets and processes from a data-centric perspective.

7. 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 toward practicing systems engineering from a data-centric perspective can be made in a series of small steps.
Successfully providing the capability to practice systems engineering from a data-centric perspective requires three key things to be addressed: people, processes, and tools. All three are highly dependent. One of the first areas that should be addressed is the process, workflow, and data architecture. The data architecture represents how the organization and projects will organize, define, and manage their data and information. The next area that needs to be addressed is the selection of the systems engineering tools that will be used by all the product development project teams. Tool selection will be influenced by the data governance policies, data and information architecture, data and information management processes, product line, culture, and workforce. The product development teams will then need to be trained in the processes and the project toolset.

Use a Pilot Project

There is an old saying, “The devil is in the details.” To bring the people, processes, and tools together, the MBSE IPT 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 systems engineering. 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 systems engineering toolset, enabling their reuse for future projects. Armed with the lessons learned from the pilot project, the organization can fine-tune its various processes, policies, and work instructions to help the organization move closer to achieving its mission, goals, and objectives to practice systems engineering from a data-centric perspective.

Several key steps include:

1. Develop a practical process that implements the chosen capability level. The process needs to fit the product line, domain, and culture of the organization. The implementation process 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 project toolset.
3. Pick a pilot project to apply the process and assign the advocates of grassroots, data-centric systems engineering to that project.
4. Define and use measures so metrics can be collected that will help document the ROI that can be clearly communicated concerning the agreed-to level of data-centricity.
5. Show management how measures and metrics maintained within the project management and systems engineering 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 systems engineering capabilities consistent with the chosen level of data-centricity and chosen systems engineering toolset. Often, tool vendors will be able to provide that person or persons who can work with both the MBSE IPT 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, the project can be used as an example for future projects. The core grassroots folks can be spread out among other projects and mentor other project managers and systems engineers and train them and their teams in practicing systems engineering from a data-centric perspective and using the chosen systems engineering toolset.

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

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 puzzle 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. The overall process must, in turn, be tailorable by individual projects to meet their specific needs.

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

An organization will be successful in practicing systems engineering from a data-centric perspective when it is 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. However, following the advice in this paper – it is possible!

Access whitepapers, user stories, and informative blogs to gain in-depth knowledge about cutting-edge practices in the industry.

Biography
Lou Wheatcraft is a senior consultant and managing member of 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.

Specialties include: Understanding and documenting the problem; defining project & system scope; defining and maturing system concepts; assessing, mitigating, &
managing risk; documenting stakeholder needs; transforming needs into well-formed design input requirements; allocation, budgeting, and traceability; interface management, requirement management; & verification and validation.

Lou’s goal is to help clients practice better systems engineering from a needs & requirements perspective across all life cycle stages of system/system development. Getting the needs & requirements right upfront is key to a successful project. Poor needs & requirements can triple the chances of project failure.

Lou has over 50 years of experience in systems engineering, including 22 years in the United States Air Force. Lou has taught over 200 requirement seminars over the last 21 years.
Lou supports clients from all industries involved in developing and managing systems and systems including aerospace, defense, medical devices, consumer goods, transportation, and energy.

Lou has spoken at Project Management Institute (PMI) chapter meetings and INCOSE conferences and chapter meetings. Lou has published and presented many papers concerning needs and requirements for NASA’s PM Challenge, INCOSE, INCOSE INSIGHT Magazine, and Crosstalk Magazine. Lou is a member of INCOSE, past Chair and current Co-Chair of the INCOSE Requirements Working Group (RWG), a member of the Project Management Institute (PMI), the Software Engineering Institute (SEI), the World Futures Society, and the National Honor Society of Pi Alpha Alpha. Lou has a BS degree in Electrical Engineering from Oklahoma State University; an MA degree in Computer Information Systems; an MS degree in Environmental Management; and has completed the course work for an MS degree in Studies of the Future from the University of Houston – Clear Lake