 So, welcome everybody, it's a pleasure and an honour to be invited back for the third of the sessions. So, in this one we're going to be, it is not necessarily that you've seen the first two, but we will be referencing the first two presentations that I did. And we're going to be talking about deploying MVSE. So, this is what I look like normally. So, thank you for the introduction, Thomas. And so, as Thomas said, I currently work for Scarecrow Consultants. I'm also a Professor of Systems Engineering at Cranfield University and the current Technical Director of IncozUK. So, we're going to start off with an introduction. But before I do that, I'm going to give a slight bit of background on this presentation. So, people often ask me, you know, where do some of the ideas come from? Is it all based on industrial experience or, you know, academic experience? And unfortunately, sometimes it isn't, it isn't based on that. It's based on other things. So, before we begin, just for five minutes, I'm going to give you an interlude and talk about the origin of this presentation. And the origin of this presentation begins quite a long time ago. It begins in 1996. So, in 1996, in the last millennium, something quite wonderful happened in most of our lives, okay? Because in 1996, George Lucas remastered the original Star Wars trilogy and re-released them all on VHS and on early adopters. It wasn't DVD at the time, but on VHS. So, he digitally remastered the original Star Wars trilogy. And this was a great event in many people's lives. And in order to celebrate the digital remastering of the original Star Wars trilogy, these things appeared. These were called Star Wars tazos. So, I don't know if people are familiar with these, but essentially, these are small circles of cardboard with pictures on them. And you could collect these if you bought a certain brand of crisps or potato chips, some people might call them. And this brand was called Walkers. So, inside, somebody thought it would be a good idea to put small pieces of cardboard inside food. So, if you bought all of these, you could collect these tazos. And at the time, Walkers crisps had just bought Doritos. So, there were a special number of limited edition tazos that you could only get in Doritos back. So, you had to buy the Nacho chips. So, my son at the time was five years old. And so, he ate a lot of crisps during these three months. And he ate an awful lot of Doritos. In fact, he went orange at one point because he'd eaten so many Doritos. And if you collected the entire set of tazos, you could send off for the limited edition collector's force pack, which was kind of like a file of facts with these cardboard pages. And you could put your tazos inside. And it was like a special collector's thing. And my son and I, obviously my son, not just me, was very, very happy to do this and very keen. And in the back of these, some of you might have had this, but in the back of this folder, there was a Star Wars quiz, 30 questions to test your knowledge about the Star Wars universe. And I don't want to show off, but I got all 30 right. But I want to draw your attention to question number 15, which says, which singer from Chalamar, Chalamar being the popular 1980s disco band who had hits with Night to Remember, played C3PO. And at the time, I thought, well, I know who plays C3PO, it's Anthony Daniels. But I didn't know he was the lead singer of Chalamar. But I thought, what I'll do, I'll remember that piece of information. And one day, that will come up as a question in a pub quiz or something. And I will be able to answer that question. And I will look like a trivia genius. So fast forward 15 years. And my friends and I were going to a place in Wales. I live in a country called Wales, where I live called Tenby. Tenby is known as the Las Vegas of Wales for various reasons. So my friends and I went for a weekend to enjoy the culture of Tenby. So there we were enjoying the culture of Tenby, sitting by the beach and enjoying the sunshine. And then after several hours, we went to a local hostelry. We went to a place called the Cochin Horses. And we were sat in this pub called The Cochin Horses, the oldest pub in Tenby. And there's a guy in the UK called Professor Brian Cox. And he's a famous physicist. And he used to be in a pop band called D Ring. And this came up as a subject. And so as people were talking about famous people that used to be in bands, the voice in my head said, tell them about C3PO. Okay. So I said, that's nothing people. I said, you know, I said, you know, Star Wars, and everybody said yes. And I said, you know, C3PO, and everybody said yes, the Golden Droid. And I said, you know, remember Chalamar, and everybody said yes, the disco outfit you had hits with night to remember. I said, the guy that played C3PO was the lead singer of Chalamar. Okay, I was expecting everybody to be very impressed by this, but the entire pub felt deathly silent. Nobody said a word. And then another voice in my head said, that's not true, is it? And everybody in the pub looked at me and said, that's not true. Because the guy that plays C3PO is called Anthony Daniels. Okay, he's a tall, British, white dancer and actor. The lead singer of Chalamar is called Jeffrey Daniel. He's not even got the same surname. He is a short American Black singer. You can't get two people that look more different than Anthony Daniels and Jeffrey Daniel. But the trouble is, I believe this because I read it. And it comes back to haunt me to this very day. People still remember it. And every time Chalamar comes on the radio, I get emails, I get LinkedIn messages. And I learned a very valuable lesson on that day. And that lesson was, just because you read it somewhere, it doesn't make it true. And this is the genuine origin to this presentation that I'm about to give you, because it gave me quite a big insight into some aspects of model-based systems engineering. In particular, when it comes to deploying model-based systems engineering. Because when we talk about model-based systems engineering, it's becoming more established. It's becoming more important and more established as time goes on. And it's been adopted very widely. However, in my experience in the work that I do, we've seen for many, many years, it's being adopted very, very badly. And people are failing in their adoption of MBSC. And when they fail in their adoption of MBSC, it reflects badly on the whole discipline of model-based systems engineering. So the question really was, well, why are people failing badly? And after many years of looking into this, of deploying MBSC successfully in many organizations and seeing how other organizations didn't deploy it successfully, we came up with certain key criteria or certain considerations that we need to bear in mind, that we need to take into account when it comes to deploying MBSC. And we refer to these three things as Trinity. This is just the name that we give to these three things. And although we use particular techniques when we talk about this, what I want to talk about today is initially these three considerations and why I believe they're the absolute minimum considerations that you need to take into account in order to deploy MBSC successfully. And these three considerations, if you like, this Trinity of considerations are the reason, the capability, and the evolution. Now, I'm going to focus today on this one, on the reason, because these two, I'll mention them briefly, but these two were actually the subjects of the two previous presentations that I've done. So the first one was all about the evolution, I believe. And the second one was all about the capability. So I will make reference to those and give you a quick summary of what we spoke about. But today, what I want to talk about is this. And to my mind, this is one of the single most important reasons why people fail is because when it comes to implementing MBSC, it's a business change. And because it's a business change, it's absolutely essential that we know why. Why do you want to do MBSC? And if you don't understand why, then don't do anything. Okay. And this is very important. And we're very serious about this, because if we don't understand why, we can't possibly know what success looks like. We can't possibly know when we've succeeded or when we failed, because we don't know what our goals were in the first place. We don't know what we were setting out to do in the first place. So knowing why is essential. If we don't know why, we're in danger of buying solutions to a problem that we don't understand. And that when we start to buy solutions to a problem that we understand, we very rarely, if ever, succeed. In fact, the probability of success in my experience is very, very low. So we need to understand why. But rather than just say, well, why do we need MBSC? What we need to understand is that this is different for different people, for different organisations, depending on their background. If you do a Google search and, for example, you type in benefits of MBSC, what returns, what comes back to you is a big list of different tool vendors and what their tools will do. And the tool functionality, tool capability. But this isn't necessarily the benefits that we want. These aren't necessarily the benefits that we want. So we need to understand why. And this is contextual. This is going to depend on our particular point of view, because different people will get different benefits from MBSC, depending on who they are, depending on what stakeholder role they're playing, I should say, depending on which organisation they work for, depending on what their business goals are. If you don't know why, then don't do it, because different stakeholders have different needs and therefore different stakeholders will want to realise different benefits. When it comes to model-based systems engineering, this is a diagram that we've probably all seen a number of times. You might not have seen it exactly in this structure, but this is what what most people are familiar with. This idea of people, process and tools. Or if we were doing this today, because this is quite an old concept people process and tool, it's been around for many decades. If we were doing this today, what we would probably be referring to more specifically is competent people. So it's really the competence we're talking about there, rather than the people themselves. And when we talk about the process, we're really talking about an overall approach. But the expression that we generally use is people, process and tools. And these are seen very often as the three cornerstones or pillars of MBSC. These are the things that we need to do. Make sure our people have the right skills, make sure they're competent, make sure that we have a good approach in place that complies with standards and reflects the business needs of the organisation, and make sure that we have good tools, make sure that we have sharp tools. Very importantly, as everything that we do in systems engineering and therefore model based systems engineering are the lines between these. So it's essential that the skills that our people have, the competences of our people, enable our approach. We can have the best people in the world. And if we don't have a good approach to underlie that, then we will fail. Likewise, we can have the best approach in the world. And if we don't have the people with the right skills, it means nothing. We also need to make sure that our approach, our process drives the tools and not the other way around. We want to limit the constraints that are being applied by tools. Every tool that we pick up is going to constraints in some way, and we need to make sure that we can control that. So all I'm going to do, I'm going to take this diagram now, and I'm going to expand it ever so slightly. And so what I've done here is the same diagram we can see here, but I've introduced this idea of stakeholders and benefits, so stakeholder roles and benefits. So what this says now is that stakeholders, stakeholder roles, must realize benefits via using MVSE. If we can't realize benefits, then we failed. But in order to do that, we need to understand what those benefits are. And in order to understand the benefits, we need to understand why. Why are you setting out to do this in the first place? So in order to try and understand this, for many, for many years, as part of, we deliver training courses, for example, as part of our business services within the scarecrow. And so for many years, what I started to do is try and identify the key stakeholder roles of people that we would have on our on our training courses. So all I'm going to do now is expand this, I'm going to show different types of stakeholder roles. So a classification hierarchy or a taxonomy of stakeholder roles. So this here is exactly the same as what we've got there. I've just switched this part off and I'm going to focus on the stakeholder roles. So we've taken the classic ISO split of having customer external and supplier roles on the supplier side. So the supplier roles according to ISO, they're the ones that allow us to realize the system successfully in the first place. So they're the stakeholder roles that are involved with the development, the deployment, and the support and ultimate retirement of our system. And typically these will be things like managers and engineers. And I've also introduced a role there, NBSE sponsor. On the external side, these are things that we don't have much sway over. These are things that we can't control typically directly, things like standards. So standards were important when it comes to NBSE. And on the customer side, we have the end users, we have the operators of the system. So the roles that make it run on a day to day basis. And ultimately, the stakeholder roles were paying for the system, the system sponsors. So I just identified this as a very basic generic set of stakeholders. It's not intended to be 100% complete. We do recommend that people try and do this as an exercise. And obviously, this will depend on the way that you work, on the way that your business works and so on. So I just use this as my start point. So every time we do the training course, what I would do is towards the end of the course, I would say to people, I would say to the attendees, what do you think the benefits of NBSE are for you? And so during the course, I would make sure that I could understand which of these stakeholder roles the various attendees were playing. And then at the end of the course, I would say, what do you think the benefits are to you? And then they would tell me, I would remember them. And then when the course was over, I would rush back and I would write these down and I would start to model their responses. Because when we say that the underlying stakeholder needs are contextual, what we mean by a context is a point of view. And what we mean is depending which stakeholder you are on here, the way that you view NBSE, the way that you look at NBSE is going to differ. It will change. So potentially for each one of these different stakeholders on here, we have a different context, we have a different point of view. So for example, from an engineering point of view, I captured at the time, in my opinion, with some of the general, some of the generic needs that the different stakeholders had, in this case, the engineer. So what I'm going to show now is just a simple high-level diagram that captures an example of what the needs are for an engineer. So again, this is just a generic one. This will change depending on you and on your organisation, but it's a very worthwhile exercise to do. So what we're saying here is engineers generally want to improve system development. This will involve improving consistency, making the approach more efficient and improving automation. And automation, what do we mean by that? Things like automation for testing, automation for artifact generation, automation for model checking, for example. The manager might be interested in making the approach more efficient, and certainly the NBSE sponsor would be interested in improving the system development. And we've got three constraints coming in here, three ways that we can limit improving the system development. And these are managing complexity, increasing our understanding and increasing the communication. As I said, this is just a generic example of an engineering context. If you were to do this for yourself, it would look different. But these were just based on the conversations that I was having with the attendees of the course. So what we have here, then, is a list of basic needs for a particular stakeholder role. So the stakeholder roles on here, there's engineer, engineer context. Potentially each one of these is going to have their own context. It's going to have their own diagram. And indeed, that's what I did. So I created one for each one of these different stakeholder roles. I'm not going to show you all of them. I'll show you one more. So we've seen the engineer. I'm going to show you the NBSE sponsor. And the first thing we'll notice is they look very, very different because the need from the point of view of the NBSE sponsor, so the internal stakeholder within the organisation that's responsible for promoting and ultimately paying for the NBSE deployment, they have a different set of needs. And it looks very different. So for example, here, what they want to do is increase the value of the business. And this will include things like increasing the sales and increasing the quality. There's a big constraint on that is that they want to do this by investing in NBSE. And there's a big constraint on investing in NBSE, which is to do with demonstrating the return on investment, making sure they get value for money, making sure that we achieve benefits from what we're doing. So I end up with a set of one, two, three, four, five, six, seven contexts that look like this, all of which look quite different because different stakeholder roles have different expectations from, in this case, deploying NBSE. And on the basis of these sponsors, I then created a benefits map. So I identified a number of benefits. And very importantly, I identified relationships between them. In this case, these dotted lines represent dependencies between them. Now, on the right hand side, we can see things that we normally associate classically with NBSE, so communication, reuse, tool interoperability, automation, and so on. Now, the idea behind this is it allows me to identify tangible and measurable benefits, and that's key. What this now allows me to do by drawing these dependencies between them is so I now know that when I talk to a particular stakeholder, so for example, if I'm talking to the NBSE sponsor, and I know that this is what they want to do, demonstrate return on investment, the benefit that I need to try and sell to the NBSE sponsor, the benefit that I need to demonstrate we can achieve by deploying NBSE is this one here. So if somebody at the senior level says to me, what benefit will we get from looking at NBSE, I will say we can demonstrate a good return on investment. That will get their interest, because this reflects directly back to one of their key needs. So I've got their attention now. They'll then say, well, how do we do that? Then I can go on and I can trace these dependencies. Well, we can save you time, we can save you resources, we can save you money, and we can increase quality, such as safety, security, compliance, and many others. If they then say, well, how is it going to save me money? I can say, well, we can improve efficiency by promoting reuse, by promoting automation, and therefore total interoperability, for example. How can I improve quality, such as safety? Well, we can improve our consistency and our complexity management. And again, we can improve our automation. So what this gives me is a benefits map here that I can trace between, and what we'll find is that different stakeholders I've talked to will be interested in different aspects of this. So the engineers tend to be interested in the right hand side. The managers tend to be interested in this one. The NBSE sponsor tends to be interested in this one. So we do this as an exercise. We want to identify what are the contexts, what are the needs that these different stakeholders have within the business, and what benefits are they expecting to realize from deploying NBSE. So essentially, what we're saying is this is what they want. And here we're saying, and this is what success looks like. If we can achieve these benefits, then we've succeeded. Obviously, we want to make these benefits measurable in some way, or at least demonstrable in some way, so that we can demonstrate that we've met the expectations of the different stakeholders and that we're adding value to what we're doing. So this is the first thing that we do when we engage with an organization that wants to deploy NBSE. We establish why. What is it they want to do? And that's contextual, depending on the stakeholder roles, and what are the benefits that we need to demonstrate in order to demonstrate that we've succeeded, that we've been successful. So that's the first thing that we need to do when it comes to this idea of this approach, this Trinity approach. There's two other things we need to do. Now, one of them is the NBSE evolution. We need to talk about, well, where are you at the moment? Where is your organization in terms of their maturity? How have they evolved their NBSE? Are they right at the beginning of their maturity cycle? If you like their maturity evolution, their NBSE evolution, or are they closer to the end? So if you were present for presentation number one, you would have seen me talk about this. And basically, what we talked about then was that complexity over the last few decades has increased enormously. It's evolved over the last 50 years, such as system elements and interfaces, such as the number of constraints and the nature of constraints, such as standards, legislation, state stakeholder expectations, again, safety, security, and so on. We can see these reflected back into the why that we just spoke about. Also systems of systems. We live in a connected world now and complexity shift. Technology is shifting away from internal combustion engines, for example, to electric motors. The responsibility is shifting away from me as the driver making decisions here to the actual system making decision. So what we've seen is over the last 50 years, this complexity has evolved enormously. And one of the things we spoke about in the first presentation was as the complexity of our systems evolve over time, so must our approach to systems engineering. And so the point of the first presentation was NBSE is just a natural evolution of systems engineering. We can start off here at stage one, which is document based and work our way through document centric, model enhanced, model centric, ultimately, up to model based systems engineering. There's nothing wrong at all with document based systems engineering, but as as time has gone on, as the complexity of our systems has evolved, then so the techniques that we apply must also evolve. So this is just representing the evolution from a document based approach to a truly model based approach that we see there. And what we need to understand there is, where are you at the moment? Where are you currently? And also, where do you want to be? What's your target stage that you want to be at? Remember, this is business change. And when we do any business change, we need to know, where are we now? And where do we want to be? Okay, so so far, therefore, we've we've captured why, why we want NBSE in the first place by looking at the context of the different stakeholders and the benefits that they hope to realize. And also, we capture, where are we on here? And where do we want to be our current stage and our target stage, for example? The third thing we need to understand, sorry, the third thing we need to understand for Trinity is what we refer to as the NBSE capability. So basically, what we're talking about now is when it comes to NBSE, where, where are you? If you were present for the second presentation, you might remember something like this, again, I won't go into it in too much detail. In order to do NBSE correctly, you need to have a good approach in place. With process sets and frameworks, we need a good solid model in place that comprises views, and we need different notations. We can also expand this to say, well, we also need tools that allow us to implement our notations and our frameworks and standards. We need some provenance to everything that we're doing. Again, I'm not going to talk too much about that at the moment. But when we talk about business change, same question, where are you now on here? Which of these are you strong in? Which are you weak in? And where do you want to be? So in terms of the slides, there's a recap there for what these different things mean. That's there for your information. So basically then, what we need to capture is the why. Why do you want to do this in the first place? What are the benefits that you're looking for? What does success look like? We also need to know, in terms of your NBSE evolution, in terms of the Lego figure scale, where are you at the moment and where do you want to be? In terms of this, this NBSE in the slide, we also want to know where are you now and where do you want to be? And it's by answering these three questions, by capturing this information, this gives us a good input into developing an NBSE implementation strategy. Now, this is all well and good, but the question becomes, how in earth do we do this? Okay, so what I'm going to talk about now is just some techniques that allow you to do this. These aren't all the techniques. It's not meant to be an exhaustive list, but these are the techniques that I tend to use. I've been using for many years that I find very, very useful and very, very practical. And we get a lot of value from them. So when it comes to the reason, when it comes to why do we want NBSE in the first place, what are some of the techniques that we can use to do that? So ultimately, it comes down to, well, we want to identify contexts. And that's great if your stakeholders or all systems engineers, particularly if they understand NBSE, because you can get them together into a room and you can start to draw out, in my case, I would use use case diagrams for this, as you can see, but you can start to draw these out. You can start to have a sort of brainstorming session and you can capture these very effectively and very efficiently. However, if you're dealing with people that are non-systems engineers or even non-technical experts, because we have all sorts of different stakeholders involved with this, we might have financial people, people from HR, all different scientists. So we need to apply our modeling to capture the reason, but to do this in a friendly way. And the technique that we use for this, and again, you can do it any way you want to, one of the techniques that we use for this is a thing called team storming. And what team storming is, it's a kind of user-friendly way to apply what we refer to as NBSE by stealth. So we're doing NBSE, but people don't realize that we're doing it. And basically the way that this works is we run a number of games. We play a number of games with the participants and we have post-it notes and we draw pictures of things and so on and we come up with storyboards. And we answer a specific question. In this case, it's why do we want to implement NBSE in our business? So we play various games. For example, we'll get people to put post-it notes of what their main concerns on the board. We will prioritize those concerns using dots, dot voting. We will then create what we refer to as empathy maps, so simple drawings representing different stakeholders and what does success look like for them. They're called empathy maps because they say, if we're successful, what are we feeling? What are we saying? What are we hearing? And what are we seeing? So this is why they're called empathy maps. All of these are very well-established games to play, business-related games to play to capture information. What we've done is we've got a model underneath this and essentially we've changed rather than using something like CISML or UML or any of the other modeling notations that are out there. We play these games and we draw pictures and that helps us populate our model underneath. This way, people don't realize we're applying NBSE. They're not scared. They won't run away screaming and they enjoy playing the games. So we do empathy maps and then we'll do things like storyboards. Okay. Well, this happens and this happens and this happens and this happens and so on. And then we'll run through these storyboards and we'll identify what can go wrong. We'll identify, well, what mechanisms can we put in place to enable this? So we have enablers and disruptors that are identified and we play through these various storyboards. At the end of the day, what this allows us to do is to create this big picture of, well, this is what success looks like. These are things that can go wrong in black. These are things the enablers in green and on the basis of that, it allows us to then generate something like that, something that we can then use and capture this information more formally in the tool. So we're using this team storming as a kind of friendly front end. It's a user-friendly way to capture this information as a user-friendly way to populate our model. So that's one of the techniques that we use when we deal with non-technical stakeholders, but we want to capture the why of MBSC. Why do they need it in the first place? When it comes to the next two aspects of trinity, capability and evolution, how do we populate those? It's well and good saying, where are you on here and where do you want to be? Where are you on here and where do you want to be? But how do you capture that information? How do you sort of qualify the conclusions that we're going to make? And so we deploy a thing called Ravens, and Ravens looks like a big jigsaw puzzle, essentially. So we have these different branches that represent people, processing tools, and we get different stakeholders together in a room, and we get a big table, and we get them to place these big, they look like jigsaw pieces to place them onto a table. Okay. And they'll look something like this. Okay. And we'll say, this is a jigsaw puzzle. We can see dots on here. They help me identify priorities. So red, where they've got no capability, yellow, where there's some green, where they're very strong. And on the basis of this, we can identify their current position in terms of where are they here? So here, the notes on here are telling me exactly what they've got. And where are they in terms of the, what's their start point in terms of their Lego evolutionary scale, which is what we can see here. So this company's at stage two at the moment. We can then take this further and say, well, where do you want to be? What's your desired capability? And this is what we're seeing here. So we change the voting system. We've now got white dots and blue dots. They allow me to prioritize which ones do we want to do first? Okay. What's the most important? We can, that then helps us populate where they want to be. It gives us our desired capability or our target capability. And it also helps me identify the transitions that they need to make, because we now know what station wants to go to. We know which transitions we need to make between the stages. And we can identify the activities that we need to perform. So the work functions, if you like, that we need to perform in order to cross these transitions in order to make our way across this evolutionary scale. So we use these techniques. In this case, it's called ravens. And it's like big jigsaw puzzles that we can see here that allow us to do that. We take these three things. Where are we on here? Where do we want to be? Where are we on here? Where do we want to be? And the why? And we use these to create what we refer to as an evolutionary path. Okay. And an evolutionary path is basically it's our main input into our MBSC implementation strategy. How are we going to go about doing MBSC? Well, we take all of this information. We can put, we can start to model it and put it together. We can see the different techniques that we've been using here. So the stuff in blue here is just what we said at the beginning, the three considerations, reason, capability and evolution. Here, we can see the outputs in pink. So MBSC in a slide, MBSC evolution, context diagram. And in green, we can see the various techniques that we've been using to do that. The output of all of this, of all of these work, these work activities that we've been doing results in what we refer to as an evolutionary path. Okay. And this gives us the main input into our strategy. So we can identify stages. These are the different stages that we want to be at. We can identify time scales. We can identify which capabilities we need to have in place at the different, at the different stages. So here we can see stage three, which is model enhanced. So that's coming directly from our evolution. These are the capabilities we want to have in place. So these are coming from our MBSC in a slide. And then we can identify these are the work activities that we need to put into place in order to achieve that. And we can start to estimate time scales as well, based on that. So for this particular organization, we think it's feasible to achieve stage five in between 12 and 18 months. So this is the strategy that we can put in place, but we still need to demonstrate that we've, we can keep the stakeholders happy. We still need to demonstrate to them that we can manage their expectations. So what we do then is we take this information and we relate it back to the original use cases, to the original needs, to the original expectations that we had. And so this gives us our validation. Okay. So now we can say, yes, we can get you to here, we can get you to these stages in this time scale. And very importantly, originally, we identified these needs, we identified these benefits that you wanted to realize. And that's what we can see here. What we're seeing here is the validation of the work that we've been doing at the overall, this overall trinity approach. So that's just a very quick sort of overview that ties the three presentations together. So in the first two presentations, we spoke about the evolution and the capability. So where are we on the Lego evolutionary scale? Where are you at the moment? Where do you want to be? And we explain the rationale behind that, the reason why we use that. The second presentation, we spoke about the capability, we spoke about MBS in the slide. Where are you on that at the moment? Where do you want to be? And we explained how that helps us justify the model and the whole model-based approach. And today, we've focused mainly on the reason, why do you want to do MBSC in the first place? And one of the biggest messages that we need to do here is you must understand why, because the way that you deploy MBSC is going to depend on your reasons why. And it's not necessary going to be the same as anybody else's. The number of times that we go to organizations and they started to buy solutions, they started to buy tools, they started to apply frameworks and standards and we say, but why are you setting out to achieve that? And it comes back to C3PO and it comes back to it because they will say, well, I read it somewhere or they will say, we looked at one of our competitors or we looked at another company and this is the way that they did it. Just because you've seen somebody else do it or just because you've read it somewhere, it doesn't mean it's going to work for you. You must understand why. You must understand where you are at the moment in terms of your capability in your evolution. And you must understand where you want to be in terms of your capability in your evolution. And you must specify how are you going to demonstrate that you've satisfied the original need that you've met. You've realized the original benefits that we wanted to have. And it's only by doing all three of these in my experience and in my opinion that you can truly increase the probability or maximize the probability of success of deploying MBSC into your business. So don't just believe everything that you read. Don't just think that because somebody else has done it, the same will be true for you because remember C3PO and that's the main things that we want to talk about today. I've also mentioned very briefly some of the different techniques that we use and we've said how we take this information and this results in what we refer to as an evolutionary path. This is what gives us our MBSC implementation strategy. Deploying MBSC is business change. We need to have a strategy in place. And just to finish off with them, although I've just said one of the main messages is don't believe everything that you read. Don't let that stop you buying any of my books. Buy all 17 and get a free shrine. There's some books here for example this red one is actually focused on what we've been talking about today on Trinity. There's books here on team storming and various other ones. I won't go into too much detail. So that concludes everything that I'd like to talk about today formally and we're finishing pretty much bang on time. It's quarter two now. So I'd like to thank you all for attending. I'd like to thank you all for listening and I will happily answer some questions now. Thank you very much for the great presentation, John. I will now look over the questions and see what we have. Okay, Ulrich asks, but how do you demonstrate, for example, cost savings? You have no concrete comparable result as well as not conduct the project twice? That's a very good question from Ulrich. So obviously in this presentation I haven't had much time to do that. So one of the things that we do right at the beginning when we talk about the benefits is, and I did say yes, we have to know how do you measure them. Things like cost savings can be sometimes more difficult. I wouldn't say they're more difficult to measure. It's more difficult to come up with a good measure for cost savings. So one of the things that we will actually often do is exactly what Ulrich is mentioning there, because we can't run the same project twice, but quite often what we'll do is run a pilot project, so a smaller scale project alongside a smaller project that doesn't use NBSE, and we can compare the results. So that's one way that we can demonstrate cost savings. Another way, if I can go back to my presentation, go back to the slides. Right, I'm going to have to do it on here. I was hoping to avoid going back through all the slides, but let me go back to the benefits model. And this is one of the reasons why we do the benefits model. Now bear in mind, I said that this is just the generic benefits model, and it doesn't include all of them. If we want to demonstrate, for example, we can save money, one way, as you say, is to run two projects in parallel, maybe pilot projects. But also, if we trace this back, we can say, well, actually, let's look at efficiency measures. So if we can measure this one, we can apply metrics to this one, we can relate it back to here and say that's going to save us money. So for example, we might apply metrics to processes and the time spent on each process or the resources needed for each process in terms of the skill sets and the cost associated with the individuals, it might come back to automation. So for example, we can say by using document generation, and we've done this on numerous occasions on different companies, we went from, for example, one company, we were able to demonstrate that by setting up automatic document generation. Now document generation doesn't work for every document. It's got to be the kind of document that is being repeatedly generated for a project. So something like a systems engineering management plan, interface control documents, design documents and so on. We went from a situation where people were spending six mandates each month generating an 800 page report to them spending under six minutes each month generating a report because we'd automated it. So in some cases, we want to be able to put, well, in all cases, we want to be able to measure them. And so for example, money, yes, you're quite right. Can we run it on projects in parallel? Can we run pilot projects? But also by following these lines on here. So efficiency, we can measure automation, we can measure things like reuse, and we can put numbers associated with those benefits. And then we can directly translate those back into in this case costs. Okay, so hopefully that's gone some way to answering that question. But the point you've raised is absolutely crucial is there's no point saying these are the benefits if we can't measure them. Okay. So that's the answer to that one. So we've got another one from Roy. Do we use the encoding model based capabilities matrix as reference to map your evolution goals? Yes, that's one of the things that we've used in the past to do that. So all this does map back, there is a province what we're doing. There's a lot more input than we've got in the Encosy capabilities matrix. And similarly, we also apply the competent the Encosy competency framework. But again, it's one of many inputs that we apply. It's one of many, you know, we just refer to these as standards. So when we look at MVSE in a slide, and we want to demonstrate our approach that we've used, these are some of the standards that we're mapping back to. So we're using standard here in the broadest sense of being any best practice model that we have. So the simple answer is that Roy is yes, we have. What else have we got? We've got Jayesh here saying thank you for showing your knowledge. Well, thank you for that. So Victor, Victor Sluta here. How many stakeholders do these consider? I see a lot of tool promotion, adding value to companies, getting new use cases. Probably this targets the C level. I get a very uneasy feeling about this because using MVSE is an NGO. And I also pretty great place to get a priori system and several. Yeah. And to my mind, stakeholder, you know, well, I would refer to a stakeholder modelling. So identifying, capturing stakeholders and their needs is crucial to everything that we do, because it comes down to context. So when you're talking about, for example, different engineering disciplines, each engineering discipline in your example, Victor, I would represent as a context. So under engineer, I've only got one on there. But as I said, this is just my generic list. When we do this for real, we'll probably find, if I get my stakeholders, that there's going to be all sorts of. So under here, we might very well have, you know, electrical, mechanical, software, and so on and so on. But I think for multiple, you kind of answering your own question, because yes, you have to do this. And unfortunately, I'm in complete agreement with you, Victor. Too many people don't do this. And it's also why, and you're saying it's, you know, we're targeting particular areas. It's also crucial to understand the impact that something like MVSE will have, whether the people, whether the stakeholders are aware of it or not, on, for example, the customers on, for example, the standards and things like that. So stakeholder management is absolutely crucial to everything that we do. Identifying stakeholders, capturing the stakeholders. And crucially, in my opinion, and in my experience, is capturing their context. What is it they're trying to get out of it? That's the key part of this. This is a very high level example that we're showing here. When we do this for real, we end up with more stakeholders. Having said that, there's obviously there's a balance between having too many stakeholders, and it not being feasible as an exercise, and getting the right number of stakeholders. But again, another very good question there from Victor. So Ian, oh, hello, Ian. How are you? What do you think of using a measure of avoided costs, comparing the number of change rate? Yeah, absolutely. And again, coming back to what we've got on here, in the benefits, you know, again, this is just a high level set of benefits, we need to better measure them. So that might be, you know, we might have two types of we just put money there, we could have that cost, we might have two types of costs, you know, cost incurred, and costs avoided, or something like that. Absolutely. And these are, this is the way we need to be thinking is we need to be looking out of the, you know, outside the box, and, you know, thinking about, well, how do we demonstrate this? What's going to keep these different stakeholders happy? So yeah, complete agreement there, Ian. So we've got Jayesh, another question. Would it be arrogant to emphasize the need to learn system for developing system? I don't think you need to. I think you need to have, you need a notation, absolutely, because when we talk about a common language, as we spoke about in the second presentation, there's two aspects of the common language. There's the spoken language, which is the notation. This is where SysML sits. It doesn't have to be SysML. It could be SysML. It could be a mixture of SysML, UML, BPMN, a mathematical language. You have to have a language that whether that's SysML or not is up to you. I tend to use SysML because I think it's a very good general purpose modeling language, but we're not constrained to that. I would also say that alongside SysML, crucial to what we're doing here, we also need the domain specific language or the ontology on there. In fact, if you look later on here, there we go. This is the spoken language, so SysML, text, maths or whatever it's going to be there. We have to have that in place, and here we've got the domain specific language, the ontology. We need both of those in place. I don't think it would be arrogant to emphasize that, but I don't think it's necessarily SysML. I think in reality, it's going to be SysML for major organizations, but it could be anything. We've already had a question for a moment. I'm going to go to Justine. Thank you for this presentation. I'm interested in the contents on the blocks, jigsaw puzzle using the Ravens approach, what capabilities are being measured within the different evolution stories. Essentially, what's on the blocks? It starts off with a generic set. For example, on the process arm that we can see, let me come up with this slide. The process one is, I believe, the blue one. On the process arm, things on there will say having a defined process, having a process model, standards, things like that. Frameworks as well will appear on the process arm of things. On the people side of things, we've got things like competency frameworks. We've got things like training on there. We've got things like upskilling on there, different training models. This is where we start to identify things like the Incozy Competencies framework. Each one of these different shapes on here, we've got a big triangle in the middle, the big arms, and then we've got the big blocks and the little blocks, the connectors and so on. We've got a big set of those generic ones, but also, I don't know if you can make that out, some of them are handwritten. We have some of them that are blank so that when we go in, we use the jigsaw puzzle as our generic start point, and then we tailor it. We can write down any specific needs that the organisation has. If you go to our video site, which is called the MBSC Embassy, I guess which came first, the name or the thing, on our scarecrow site, there's a video up there about Ravens, which will give you more information on that. We've got time for a couple more quick questions. We've got Peter on there. One additional possibility to make evidence that MBSC works pays off is doing things, adopting MBSC, which is not feasible or difficult to do using the approach before. Yeah, exactly. Again, I completely agree with Peter, and this would be one of the things that we identify on our contacts. Let me go back. It would be something that we identify on our contacts here. On here, it might say, apply to novel areas or apply to new areas or whatever, and that would result in becoming one of the benefits on there. Again, similar to the previous question, the Ian Cunningham's question, it's thinking outside the box, how can we demonstrate this? Think about this. What can we measure? What can we demonstrate? Is this going to keep the stakeholders happy? Very importantly, by having this approach where we've identified the stakeholders, we've identified their needs, we can get this validated by the stakeholder and say, look, this is what we think you want. Is this true? If they say yes, that's a big step forward, but then we can say, okay, if this is what you want, these are the benefits that we're going to demonstrate to you, and this is how we're going to do it. Is that going to keep you happy? If you can do that, immediately, you've got your validation criteria, you've got your acceptance criteria for doing the work in the first place, for doing your MBSC in the first place. Okay, I would say the last question. Let's go for Graham, because Graham hasn't asked the question yet. This might be a technical implementation question. How do you think it's best to build in VMV into MBSC? What would your approach be to ensure quality? Again, it's getting the, on MBSC in the slide, it's building up the framework and the processes effectively to take those things into account. It's having a good approach in place. Okay. Like I say, if you go to our videos, there's more videos about things like Ravens and team storming on there. If you want more information, there's a couple of questions regarding how can they find out more about these techniques. If you email me directly or go on to our website, and in fact, the best way is probably to go to our website and ask a question via inquiries, because if you email me, I'm quite lazy. I can't guarantee I'm going to answer. If you send it to inquiries, it goes to me and one of my colleagues, and he will make sure that I answer any of the questions. Okay. So thank you for that. That was a very good set of questions. Okay. Thank you, John. One more time. Just for information, we will give us your presentation. We will distribute to all our participants in the next few days. And finally, I want to say make note about our upcoming webinars. It's on June the first for Professor Simon Burton. He talks about safety assurance and under uncertainty and Michael Gainford at the July 6th, how to learn systems engineering. Okay. Thank you for attending. We hope you enjoyed this talk. Good luck and goodbye. And one more time. Thank you very much, John, for this great Trinity webinar. If you have an event, come up and say hello. Come and introduce yourself. As I say, go to our website and ask questions via the website. And take care. Stay safe. Thank you. Bye-bye.