Blog

Integrating MBSE into your organization

Posted on: November 21st, 2016 by Lou Wheatcraft No Comments

In this first part of the series, I addressed the question “Why implement MBSE?”, listing benefits for doing so as well as discussed how MBSE enables you to use measures to better manage your system development efforts.

In the second part of this series, I introduced the concept of MBSE capability levels (MCLs) and discussed the need to choose an MBSE toolset appropriate for the MCL chosen.

In this third part of this series, I provide guidance and a roadmap your organization can follow to implement your chosen MCL.

Major challenges to implementing the chosen MCL is convincing management and co-workers that it is time to implement or perhaps improve your organization’s MBSE capabilities and knocking down the walls of resistance.  Some common reasons for them not wanting to implement or improve MBSE capabilities include: (Note: see also David Long’s blog: “9 Imaginary Roadblocks to MBSE”.)

  • “We have been doing product development using our current processes for years, why should we change?”
  • “MBSE may work for others, but not for us.”
  • “MBSE is very complicated, we don’t have the knowledge, experience, or tools.” (False assumption that to do MBSE you have to jump in at MCL 4 and be experts in SysML or similar modeling languages.)”
  • “Our current SE artifacts, like requirements managed in an RMT, FFBDs, etc. are models, so aren’t we already doing MBSE?”
  • “It is too expensive to procure the needed MBSE tools and train our people to use those tools”
  • “We don’t have the budget to incorporate MBSE at this time.”
  • “The expense and associated process to get new MBSE tools installed on organizational computers is too great.”
  • “We deal with the development of classified systems; maintaining security will be too difficult.”

Sound familiar?  Often the pushback can be attributed to a lack of understanding of MBSE and what level of MBSE capability is appropriate for your organization.

So how can you convince management that some level of MBSE capability is needed?  Three words – RETURN ON INVESTMENT!  Think about it … what has been the impact of the current, poorly executed product development efforts?  Failures, recalls, returns, warranty costs, negative reviews, decreasing market share – not good for profitability or margins.  The return on investment (ROI) argument usually works with management especially when you can convince them that by investing in an MBSE capability level tailored to your organization’s needs, they can improve the overall product development process, product quality, and improve profitability of the enterprise.  The more effective the SE processes, the less rework and cost and schedule overruns will be reduced.  By implementing appropriate level of MBSE capability, you increase the probability of achieving a competitive advantage by removing obstacles to being able to deliver your product on time, on budget, and that meet or exceed customer and quality expectations.

Even if you are able to make a good case for implementing an MBSE capability or improving your existing MBSE capability and have management backing in doing so, the rank and file may still push back.  When this happens, the source of the push back is more often due to cultural dread and anxiety associated with change not process aversion.

Success starts at the top. Stakeholder needs and requirements exist at a number of levels or layers (Ryan, 2013) within an organization. There is an enterprise view in which enterprise leadership sets the enterprise strategies; a business management view in which business management derives business needs and constraints; a business operations view in which stakeholders define their needs and requirements; and a systems view in which the system is defined in logical and physical views. Subsequently, there are views at the lower-level of the subsystem and other system elements.

To successfully implement an organization’s chosen MBSE capability level (MCL) the journey must start at the top.   At the enterprise level, the leadership must lead the push for successful project management and systems engineering.  There must be advocates at this level, leadership must acknowledge the benefits and ROI associated with implementing these industry best practices.

These various views are referred to as layers.  At the highest layer, the enterprise has a number of strategies that will guide its future.  At the enterprise layer, leadership communicates their intentions with regard to the operation of the organization—in terms of existing systems, processes, and systems to be developed.  Leadership defines the enterprise in terms of ‘brand’ and establishes a mission statement and corresponding goals and objectives, which clearly state the reason for the enterprise and its strategy for moving forward.

At the business management level, the requirements and implementing processes will be defined that will result in the organization adopting project management and systems engineering processes tailored to the needs, product lines, and culture of the organization.  It is at this level the decision will made to adopt the chosen MCL as part of how the organization does systems engineering.

At the business operations level, the infrastructure will be put in place to allow projects to develop and manage systems at the chosen MCL.  This will involve defining organization standard operating instructions, work instructions, processes, etc.; acquiring the MBSE tool set with the functionality needed for the chosen MCL; and training project and engineering teams in the processes and MBSE tool set as well as in the concepts associated with systems engineering in general and MBSE specifically.  For organizations with multiple business units, each with different product lines, each business unit will have to provide the infrastructure tailored to their unique needs.  Note that the various business units may decide on different MCLs, and a different path to achieve the MCL they have chosen.

Assuming this is done at these layers above the project/system layer, then at the project/system layer, implementation of MBSE has a much greater chance of success.  However, there are still other challenges that have to be addressed. For a more detailed discussion on levels, see my blog: “Levels of Requirements Above the System Level.”

Changing culture is often met with opposition.  To combat this opposition, you need to use your soft skills to manage your stakeholders.  Determine which stakeholders are for and against the change.  Then determine why they are resisting the changes you are proposing.  For each individual or group, identify his or her 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.  You may need to enlist the aid of other stakeholders that can help you influence those that oppose the change.

Many engineering organizations tend to be very conservative in the way they do business.  Rather than making a big revolutionary change, develop a strategy that involves incremental change over time.  It is easier to eat a turkey in small bites rather than trying to stuff the whole bird in your mouth at once.  For example, initially, you might have the core SE team be the only ones who actually work directly within the MBSE toolset for the short term.  They can work with the other engineering and management team members to ensure the data is accurate, but the broader team does not have to learn the ins and outs of the actual MBSE toolset immediately, but can have access to the various reports and view the outputs at any time.  As the team gains experience with the new MBSE driven process, they can increase their direct use of the MBSE tools associated with their specific function.

Using the MCLs defined above enable you to take these small bites rather than having to eat the whole turkey at once.  True, it may take a long time to get where you want to be, but as long as the small changes result in improvements and actually make the engineers’ jobs easier, they will go along with the change.  Most people follow the path of least resistance.

You need to make the path you’d like them to follow easier / more beneficial than the current one.  If the change is more difficult or makes communication harder, you are fighting a losing battle.  For example, your lead engineer or project manager may already be over their head and working 50-60 hour weeks.  You want them to learn and implement a new process and a new tool(s)!  Good Luck!  However, if you agree to provide them with a dedicated engineer that has the training, knowledge, and experience in the chosen MCL and associated MBSE tool set to help implement the changes, they will be much more receptive.

People 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 they are working the long hours is because they are always fighting fires, going from one crisis to another, that resulted from the lack of the proper SE tools and processes in the first place!  You need to change the culture from one of firefighting to one of fire prevention.] As time passes, they may even start to be advocates for the changes that have been made and welcome further change.  Depending on the size of your organization and culture, this process could take several years.

Even if individual projects only last a year or two, organizationally you will be in this for the long haul, you must persevere and not give up and lose faith.  Be prepared to make minor course corrections when things don’t work as expected.  Always keep the end in mind.  Incorporate the incremental changes into the existing process rather than replacing them wholesale.  Work to gain acceptance slowly.  Get your people used to seeing and using bits of the processes in small ways and grow it outwards.  People will never appreciate you telling them that their current way is poor or old fashioned – they must discover the benefits of incorporating your proposed changes themselves.  As the old saying goes: “No one wants to be told their baby is ugly!”

Use a pilot project. Our advice is to study the current organization and workflow and look for a project that you can use to demonstrate the benefits of your proposed changes in the short term.  You can use this pilot project as a viable example to effect larger scale change within your organization.

Several key steps include:

  1. Develop a practical process that implements the chosen MCL. A good process is one that people can follow as part of their job, not something they have to do in addition to their job.  Also, the process needs to fit the product line, domain, and culture of the organization. The implementation needs to be tailored to your organization, don’t try to follow a process developed by a tool vendor for some other organization or product line.
  2. Invest in training in your proposed chosen level of MBSE capabilities, the MBSE tools involved, and the associated processes.
  3. Pick a pilot project to apply your process and assign the grass roots MBSE advocates to that project.
  4. Keep metrics so that the ROI of implementing the chosen level of MBSE capacities can be clearly communicated.
  5. Encourage your team to be actively involved in organizations like INCOSE and join working groups whose members can aid the implementation process.
  6. Once the project is completed successfully (an assumption) then the project can be used as an example to get other projects to follow. The core grass roots folks can then be spread out among other projects and mentor other project managers and systems engineers and train them and their teams in the use of MBSE and MBSE tool set.

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.

You know you are successful in implementing MBSE in your organization when it is considered to be the standard for system development.  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.  It is possible!

Closing Thoughts

The goal of this blog is to provide organizations a better understanding of the challenges involved in developing increasingly complex systems and the need for an MBSE capability within their organization to address these challenges.

After reading this blog, we hope that some of the confusion has been reduced for those who are assessing whether or not they should implement MBSE and that the reader now has a better understanding as to what MBSE is and the benefits of adopting MBSE.   Readers should also have a better understanding on how to successfully implement MBSE within their organization no matter the size and complexity of the system under development or the size and culture of the organization developing the system.

Finally, we have provided a roadmap readers can use to define and successfully implement, incrementally, a MBSE capability that is tailored to the unique needs of their organization, whether small, medium, or large enterprises.

This blog series on developing an MBSE capability within your organization was broken up into several parts:

  • In this first part of the series, I addressed the question “Why implement MBSE?”, listing benefits for doing so as well as discussed how MBSE enables you to use measures to better manage your system development efforts.
  • In the second part of this series, I introduced the concept of MBSE capability levels (MCLs) and discussed the need to choose an MBSE toolset appropriate for the MCL chosen.
  • In this third part of this series, I provided guidance and a roadmap your organization can follow to implement your chosen MCL.

References

INCOSE‐TP‐1995‐002‐01, 1995. Metrics Guidebook for Integrated Systems and Product Development, Wilbur, A., Towers, G., Sherman, T., Yasukawa, D. and Shreve, S.

INCOSE-TP-2003-020-01, 2005, Technical Measurement, Version 1.0, 27 December 2005. Prepared by Roedler. G. and Jones, C.

INCOSE-TP-2003-002-04, 2015, Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 4, Edited by Walden, David D., et al.

INCOSE-TP-2005-001-03, 2010, Systems Engineering Leading Indicators Guide, Version 2.0, January 29, 2010; available at http://seari.mit.edu/documents/SELI-Guide-Rev2.pdf. Edited by Roedler, G., Schimmoller, H., Jones, C. and Rhodes, D.

INCOSE‐TP‐2010‐005‐02, 2010, Systems Engineering Measurement Primer: A Basic Introduction to Measurement Concepts and Use for Systems Engineering, INCOSE.

INCOSE-TP-2010-006-02, 2015, Guide to Writing Requirements, Chapter 5, Prepared by the Requirement Working Group, INCOSE.

INCOSE-TP-2015-001-01, 2015, Project Manager’s Guide to Systems Engineering Measurement for Project Success, prepared by the Measurement Working Group (MWG), INCOSE.

ISO/IEC/IEEE 15288, 2015, Systems and Software Engineering— System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization.

Long, D., “One Model to Coordinate them All”, http://community.vitechcorp.com/home/post/One-Model-to-Coordinate-them-All.aspx Blog, Vitech Corp.

Long, D., 9 Roadblocks to MBSE, http://community.vitechcorp.com/home/post/9-Imaginary-Roadblocks-to-MBSE.aspx, Blog, Vitech Corp.

Long, D. and Scott, Z., 2011. A Primer for Model-Based Systems Engineering, 2nd Edition, Vitech Corp.

Malone, R., Herrord, J., Friedland, B., Fogarty, D., 2016. “Paper Insights from Large Scale Model Based Systems Engineering at Boeing”. 26th Annual INCOSE International Symposium (IS 2016), Edinburgh, Scotland, UK, July 18 – 21, 2016.

NASA, 2016, Expanded Guidance for NASA Systems Engineering: Volume 2: Crosscutting Topics, Special Topics, and Appendices, NASA Headquarters.

NPR 7123.1B, 2011. Systems Engineering Processes and Requirements, NASA Procedural Requirements, NASA.

Ryan, M., 2013. “An Improved Taxonomy for Major Needs and Requirements Artefacts”, 23rd INCOSE International Symposium, Philadelphia.

Ryan, M., Wheatcraft, L, Dick, J, and Zinni, R., 2014. “An Improved Taxonomy for Definitions Associated with a Requirement Expression”, Systems Engineering/Test and Evaluation Conference SETE2014, Adelaide.

Wheatcraft, L., “Features an SE Tool Set Should Have”, blog, http://reqexperts.com/blog/2015/12/features-a-re-tool-set-should-have/.

Wheatcraft, L., Ryan, M., Dick, J., “On the Use of Attributes to Manage Requirements”, Systems Engineering Journal, accepted for publication, 2016.

Tags: , , , , , , ,
Posted in Systems Engineering | Tagged , , , , , , , | Leave a comment

Leave a reply