The DOs and DON’Ts of introducing Model-Based Systems Engineering to your enterprise

Kevin Robinson, Chief Engineer

We’ve been introducing Model-Based Systems Engineering (MBSE) into organisations for some 12 years now and have learnt plenty of lessons along the way. We’ve used MBSE at many different levels; project, program and organisational level, throughout different points in the lifecycle, on some of Australia’s biggest acquisition programs in transport and defence, and for industry and government. From this broad range of experiences, we are keen to share our insights into how to introduce MBSE into your organisation. So, here are our top “dos and don’ts of introducing model-based systems engineering to your enterprise”.

DO: You need a champion

Who in your organisation is going to fight for your cause internally? Who is going to take on that leadership role to articulate the why, the vision and purpose of your project and application of MBSE? Who is going to follow it up and empower employees to deliver?

This one individual should not be in charge of engineering, or even fund the activities but they do need to have the authority and ability to inspire change. Make sure that, when they apply MBSE to their first project, it’s going to be winner that will inspire future application of MBSE.

DO: The earlier the better

We see this time again, where we are brought in a year after the project is started to implement MBSE into the program. The lesson is – apply it at the outset! Documents and information sources that are retrofitted into the model create re-work, risks and other issues. Don’t leave it until it’s too late and decisions are made and designs are done. Apply MBSE at outset and you will ensure that you consider a whole range of information and stakeholders that will influence better outcomes.

DO: Develop a minimum viable model

You need to be clear about the level of detail needed in your modelling up front, to set yourself up for success. Understand that you don’t need to model to a level of detail you don’t need to make decisions. Define that level of detail, or fidelity, which aligns with the specific purpose of the model at that point in the lifecycle and stick to it.

DO: Avoid scope creep

There is a particular project, that I can recall, where we had a senior project leader and they hadn’t quite grasped what MBSE was and how it was going to add value to their program. But when he got it, he really got it.

We had presented the results of our MBSE approach a number of times. He had nodded along and trusted his engineers and they were all motivated about it. MBSE approaches can have many different uses across many aspects of the lifecyle. At one particular meeting, we saw the lightbulb go off in the project lead’s head. He began to ask questions and, all of a sudden, the scope creep came out. This is to be avoided at all costs! At the outset, define the specific environment that your model applies to and stick to it. You then have a greater chance of success. Then go back after you have delivered that project to ask where else can we apply this model?

DON’T: Don’t forget it’s about an organisational capability

An organisational capability is around the people, process, tools, information, culture, governance; or similar capability definition you have. As engineers, we often focus on the data and translating that into information, but forget that it’s a change project where we have to deal with people issues, company culture and systematic behaviours to effect change.

Find the right group of people who are early adopters and find the right project so that these early adopters help you to run with it and prove its concept to the rest of the organisation. This will improve your chance of adoption.

DON’T: Don’t rely on the model for a shared understanding

A model is a rich source of information, but only if it’s understood. Introducing MBSE is not just about that project and that project team. It’s about a far broader set of stakeholders within and, in more complex projects, outside of the organisation that play a part.

One example is that of a senior leader that we were working with. We tried to display the model in different formats to show what it was introducing. It wasn’t until we showed him a functional flow block diagram diagram that he got it. What we have come to learn is don’t rely on just typical modelling languages to show the model, use all the available visualisations to show the model and what it applies to. We need to introduce concepts in the readers own language and situation, so that they really understand what we are capable of achieving. This allows you to engage a broader cross section of the organisation too.

DON’T: Don’t ignore the documents

We live in a document centric world and we have found that, in changing any organisation, you have to do it one bite at a time. Approval is usually given one document at a time. It is signed along the dotted line. We need to remember this.

People also enjoy reading documents (some do). It is essential that you extract the documents straight from the model and include the information you may want to add in the document within the model environment, you will not be changing the bigger process and you will always be relying on (and applying) the right information. Keeping document information within the model means that contributions can be made and validations can be undertaken via the document process. It becomes very useful. This is, of course dependent on your organisation and your approval processes.

DON’T: Don’t think it’s quicker

It’s a rookie error to sell MBSE as a time saving device. We did some analysis in the early days to see how applying MBSE contributed to time management and delivery throughout the project. What we found was that it was taking, more or less, the same amount of time. What differed, however, was that the model based approach was giving a more robust and higher quality outcome. What we also found was that in applying MBSE, you had a greater surge of effort at the beginning that tailed off over time, whereas a document base approach tends to have a consistent effort throughout the project.

When you’re trying to sell MBSE, don’t advise that it’s a quicker approach, advise that it’s a better! MBSE delivers a far higher quality product that reduces risk and rework.

See the presentation here