Successful Product Architecture and Systems Engineering Initiatives

00:00:00: Welcome to Next Level Engineering, the MBS e-podcast from VDE Bayern.

00:00:05: In our podcast we discuss current product development topics and how a model based approach can help tackle challenges.

00:00:15: My name is Thomas Gessner And I'm your host today.

00:00:20: Today We are talking about How initiatives for model based working Can be implemented successfully within a company?

00:00:31: And today's guest can provide profound insight on that.

00:00:35: A warm welcome to Dr. David Allaverdi!

00:00:39: If we look back at the previous episodes of the podcast, We can see that we started with a topic what is MBSE?

00:00:47: What is model-based working?

00:00:49: What's its purpose and what benefits Can we expect from it?

00:00:54: And in this third topic area It's going to be about implementation Implementation.

00:01:02: so How do I roll out MBSE initiatives successfully in the business?

00:01:07: And David, maybe starting with you first.

00:01:11: Give us a quick intro and may be also a bit of background on your experience in the field of model based systems engineering and also Of course in terms of your background.

00:01:25: Yes thank You very much Thomas for having me. What connects me or what was basically the starting point for this whole topic.

00:01:36: It goes back to my studies, yeah?

00:01:38: The topic of complexity management.

00:01:41: how can I deal with complex products?

00:01:43: everything around product development and product portfolio management.

00:01:47: How can I standardize?

00:01:48: How can I handle variants?

00:01:50: All of these topics occupied me during my studies and then of course in various active parts project that I had the privilege of working on in companies.

00:02:02: Then I was in Norway for a while, got to work on the offshore oil and gas industry there on very same topics.

00:02:07: Then I did my PhD also in systems engineering and was able to work in consulting in somewhat product agnostic way where I got to know learn about all these topics across various industries and ultimately combining methodology & software and now ended up with Zuken in software.

00:02:32: Software isn't just about software, it's definitely also the services component that matters there.

00:02:39: so I basically bring together these three fields with industry experience. The deep dive of an industry on one hand then looking at things from outside a consulting perspective and now software.

00:02:55: It is really nice to go back now.

00:02:58: what connects them, what connects that experience.

00:03:01: What are the key takeaways,

00:03:03: that make this type of project successful?

00:03:06: and there are definitely things that share a common denominator

00:03:09: exactly, and that's what we want to discuss today.

00:03:12: David you and I have been companions for many years initially in consulting. I think, we work together therefore five years and back then I got to know you in consulting as a very, very experienced project manager.

00:03:28: You did projects with very large enterprises as well but also with SMEs and it was always somehow about product architecture optimization variance optimization.

00:03:39: essentially that's very closely related to what we present in our podcast or model based working, but when you look back a bit and also reflect a bit on your project experience.

00:03:53: Are there like, few key topics where you say yes for me those are the four three or five key success factors?

00:04:03: Or areas were success factors lie hidden that people should watch out for?

00:04:08: is it some kind of sort pattern or blueprint?

00:04:13: in my view absolutely. Across the sheer number of projects you eventually spot a pattern and realize that it's not just certain areasthat make for success.

00:04:23: So, for instance Just introducing a methodology on its own, just introducing software On its own that or for example also leaving IT processes the organization out Of the equation those are all things where Failure is basically pre-programmed and no matter how much You invest In the end, it can simply backfire and that's why in my view.

00:04:45: It is absolutely the case.

00:04:47: That comes down to many other factors as well.

00:04:50: And yes absolutely!

00:04:53: There are three distinct areas that you can see here.

00:04:57: First there are leadership and ownership.

00:05:00: The fundamental question Who is wearing a hat?

00:05:05: Is there someone who really... Yeah, when things aren't going so well is still continually committed.

00:05:12: high level that this.

00:05:14: The second topic is organization and enablement.

00:05:17: yeah?

00:05:19: The people working in it.

00:05:20: They need to be enabled, they need empowerment.

00:05:22: That's just one of many factors.

00:05:24: but organization an enablement naturally play a crucial role.

00:05:28: And finally execution and adoption as Well.

00:05:32: It doesn't help if you've thought everything through conceptually, but can get it onto the road.

00:05:38: And unfortunately, it often ends after a concept phase because the organization wasn't brought along for instance

00:05:48: and because the added value was continually demonstrated over time and you lose people.

00:05:54: so those are just examples.

00:05:56: but they're roughly three areas I'd identify.

00:05:59: So I think with these three, four areas, if I jotted it down right,

00:06:04: were the topic sort of ownership.

00:06:06: I really have to have a clear line of responsibility that must be defined.

00:06:13: That was number one, we ought to get into it.

00:06:16: The topic of enablement.

00:06:17: organization is the second point if i've understood correctly and then as it were implementation in the company third-point gives us an agenda for today.

00:06:32: Before we had jumped into that and maybe examine those individual points in a bit more detail, I'd like to take a step back.

00:06:39: And just ask the following question when you describe that?

00:06:42: Just now.

00:06:42: those three points... Those aren't classic points where you say MBS-E is software topic and provide some software and then implement MBS E and then that sorted.

00:06:57: That obviously doesn't work.

00:06:58: based on your experience it was implicit what you said.

00:07:01: So maybe before we dive into that, We can look again at the tension between to put it very bluntly.

00:07:10: I hire a working student who picks out an MBSE software and then says That's my MBS E project on the one hand?

00:07:16: That's one extreme here.

00:07:17: And on the other end of this second extreme i bring An expensive strategy consultant onboard and they'll do an mbs e enablement Project for our high six figure sum.

00:07:28: Somewhere in between obviously is where the truth lies.

00:07:30: Well, at least that's what seemed to shine through.

00:07:33: That would be my first question to you Where exactly within that spectrum do you see from your experience?

00:07:39: The golden if it exists?

00:07:41: the Golden mean

00:07:44: Yeah, that's a good question.

00:07:47: Ultimately the topic of MBSC and I'd aggregate that A bit higher up Is product development per se And the methodology behind It includes product portfolio management developing modular systems, variant management costs down projects for product.

00:08:02: All these topics.

00:08:03: I'd view them in an aggregated way right now and they naturally have a very strong methodological component.

00:08:09: that means with software alone... ...I can't achieve success And at the same time With just methodology i no longer handle complexity.

00:08:23: That's why need both somehow requires certain competence.

00:08:28: And this competence, I often get that through the experience of the employees as well.

00:08:35: Ideally they're inside a company but first have to be enabled and gather these experiences then also apply it.

00:08:45: Then software also has working with software which utilizes this methodology and the software integrally.

00:08:57: whether it's a working student or strategy consultancy, its more about the fact that in end would actually be one of my first points.

00:09:04: The client is on the driver seat and through specific route using external know-how for example own all of them.

00:09:18: so they basically have to be expert with methodology.

00:09:21: They can always ask questions externally, that's clear.

00:09:25: But they need to have a fundamental understanding and they must be able to apply it themselves too.

00:09:30: So this helping people help themself is essential.

00:09:35: There we are already on the first of three points you just mentioned.

00:09:38: I think thats really important.

00:09:39: but if alot of people listening us say yes thats all well and good You know your stuff in the driver seat yourself.

00:09:48: But then lots of people also say, hey I'm just not there yet.

00:09:52: It's

00:10:15: step-by-step enablement in my view.

00:10:17: Yeah, so there are many People and companies who partly already have these skills Who at least have a foundation methodologically?

00:10:25: And where it's easier to enable them There are people who don't have that at all who maybe have very strong product know how but just not methodologically.

00:10:32: yet No matter where you're coming from I think You have to define as standard As it were defined the baseline and once you have that baseline then you can.

00:10:41: Then you also have person in the company who carries the whole thing where it doesn't all fall apart.

00:10:48: And at the start, It might not be the driver's seat either perhaps At the beginning is still a passenger seat but that The perspective must be That person gets into the drivers seat because often These whole well consultancy projects are Often planned from the outset with the client and the passengers seat.

00:11:06: But my experience Is precisely that it falls apart as soon As you take step back here From the consultant side.

00:11:12: I believe for a project to be successful, and that's what we want after all.

00:11:18: We want to increase effectiveness.

00:11:21: The client should move into the driver seat as soon as possible And that means for example knowing how to operate the tool That's where it starts but also having the methodological foundation To know what a function is for us.

00:11:34: For instance yeah?

00:11:35: What is product structure What are requirements, what our functional requirements?

00:11:41: All these things are often not known or used differently and you have to establish a baseline there.

00:11:46: And that's important.

00:11:47: going forward developing them towards that for instance yeah...what is the product structure?

00:11:52: What are requirement as well?

00:11:54: Functional requirements all of this thing they're often not know or use differently in your.

00:11:57: after establishing base line their and thats whats important going on with developing it was that

00:12:01: starts off course would be certain mindset.

00:12:03: I reckon so also with the awareness That as the person in charge, I say right okay this is something that i have to be able do.

00:12:10: ultimately so.

00:12:11: Have you been able to master?

00:12:14: This whole topic of model based working or let's say model-based requirements management was more scale.

00:12:18: also work sustainably with a company and get it Okay.

00:12:21: So there would now we one point which starts somewhere in my head.

00:12:23: And then I said Right Now I'll go looking for um coaches Let's Say I'm deliberately not saying consultants look For Coaches I Look For Technology.

00:12:32: I try to help myself or get help, To the point where i can do it myself.

00:12:37: Understood?

00:12:38: Does that actually bring us to this first point.

00:12:40: you called leadership and ownership didn't You?

00:12:41: so we've got ownership now but We don't have leadership yet.

00:12:44: What's involved in That?

00:12:44: Now then So we know someone who says okay brilliant I want This after master this I need be able Do It Myself And so on But were not quite done.

00:12:50: Yet are we?

00:12:50: There is probably I'm guessing still a bit missing.

00:12:54: Definitely The thing Is my experience Projects like that, in principle it's about making a product better.

00:13:03: Making it better as a blueprint so defining the architecture pursuing reusability Reusing this product architecture multiple times for different instances.

00:13:12: That is the projects.

00:13:14: And that obviously has a major impact on product success, and then also in the company's success.

00:13:21: Ultimately it's important.

00:13:24: these projects don't just stay within specialist disciplines but are supported at an overarching level especially by management even at sea-level I'd say because its precisely important.

00:13:41: Yeah, that the business knows or those who are in the pilot seat and everyone working around it.

00:13:45: The whole...the entire core team actually That's working on it knows I have support right from the top And no matter what happens if we lose our way This is our strategic goal Because Naturally sometimes You can't reap the rewards yet And impatience suddenly creeps In If you don't have Let say commitment then And sponsorship form From the top then it can also backfire.

00:14:12: I like that.

00:14:13: now of course you've got the classic big IT projects say introducing a massive ERP or PLM system and that can drag on for years, I reckon after six months at the latest you probably lose a lot of interest there.

00:14:40: How do you actually manage to prevent MBSE projects from falling into that trap?

00:14:47: It's good point, it is more about how the project are carried out but i think its fine here.

00:14:52: From my point view ,its continuously generating value for clients to lose the client by saying, for instance delivery is now... The content delivery in about a year or a year and half.

00:15:07: That's how I loose the clients meaning i open the curtain and tada here what have been working on.

00:15:13: you can go ahead use it know doesn't work like that really need to deliver added value to the client on an ongoing basis whether they're existing projects or not, so whether there are specific clients behind them.

00:15:27: But it always has to be tied to a value because ultimately I need buy-in from the entire team and by that i don't just mean management... ...I really mean the whole team!

00:15:38: Because one of two people can completely derail a project like this And that's why I constantly have to keep people engaged and say, right?

00:15:47: What matters to you what do actually need.

00:15:50: Whether it is a list of requirements whether its visibility on the impacts impact chains all of that can create massive value.

00:15:59: That's why continuously generate value continuously check whether we've generated has delivered value.

00:16:06: feeding feedback back in is essential.

00:16:09: for me

00:16:10: That implies some sort.

00:16:14: I mean, it implies communication obviously and presumably also what i'd call a structured cadence.

00:16:19: How would you see that?

00:16:20: or how do you organize this?

00:16:23: This communication that now seems so vital in central

00:16:27: Exactly So.

00:16:28: ultimately we did say We need someone in the pilot seat Someone driving this At company xy.

00:16:36: right We said we need Executive sponsorship But It's not enough To simply let's say have that sponsorship from the start.

00:16:48: Have a kickoff and then Let's say management disappears for a year.

00:16:52: That's simply not enough.

00:16:54: you constantly have to With the core team wearing that hat The person at XY in the pilot seat.

00:17:02: You constantly have two synchronized, you always have to see where are we now?

00:17:05: And where do we want it?

00:17:07: get too and the best thing you can Do is regular steering committees.

00:17:12: were I bring these two worlds together to?

00:17:17: well, it's not just about let say holding a status meeting.

00:17:21: I think that wouldn't be thinking far enough ahead.

00:17:23: It's about demanding a certain active role from management In terms of steering the project in terms off.

00:17:32: at this point Maybe there are other priorities because strategically we want to be X or Y Or clearing roadblocks.

00:17:40: for instance doesn't really want to collaborate due to a lack of capacity.

00:17:46: Yeah, that's also an issue for the steering committee and in my experience yes it is extra effort but its worth because there tends to be sort of divergence between management and core team.

00:17:57: after awhile over time that divergence becomes so wide when new budget decisions come up they might end being negative.

00:18:06: then all work you've done is worst case scenario unusable.

00:18:13: generate value, that was the point of the Value Release Plan.

00:18:16: But in the steering committees getting management involved as well so you essentially always keep the whole team on board?

00:18:23: Maybe you could give a concrete example.

00:18:25: these Steering Committees.

00:18:27: what does it actually look like?

00:18:28: do they happen every six months or every three months?

00:18:32: and What's Actually On The Agenda?

00:18:34: So maybe A Bit More Detail On That.

00:18:36: Is There Typically A Good Cadence Or Rather A good Frequency?

00:18:41: Well, working in four to six week cycles has proven effective.

00:18:45: Six-week cycles are actually very practical.

00:18:47: two and a quarter makes huge amount of sense.

00:18:51: In terms of structure the steering committee is naturally a status check To some extent right.

00:18:56: you do present.

00:18:58: what were the objectives?

00:19:01: What have we achieved?

00:19:02: maybe include a short demo as well, so basically getting everyone up to speed and very importantly bringing the various stakeholders along.

00:19:10: Right?

00:19:11: So not running this steering committee from just one perspective but delivering something for one product manager or high-level management... And once you've done that it's really vital to open.

00:19:23: the floor Is best held not during the presentation, but ideally at the very end because it's so often gets derailed.

00:19:33: That's why It is strongly recommended to leave until the end.

00:19:37: unless there are clarifying questions.

00:19:40: and then you have items that need deciding on You should have those well prepared.

00:19:44: for instance need to make an organizational change.

00:19:50: It could be that conceptually we've hit a brick wall and need to pivot here, plenty of things you have to bring into decision And then above all especially with management You should make these decisions together Then move in the next round.

00:20:03: work on it for six weeks.

00:20:06: Yeah That's kind of the agile principle.

00:20:08: basically We follow

00:20:09: I think now picking up what you foreshadowed earlier.

00:20:13: So this value oriented project approach.

00:20:18: That's reflected again in these steering committees, so the way I understand it now right is that you sync that up and say on one hand i probably slice my projects into value slices And then see them again somewhere in the steering committee.

00:20:34: Even if we have three points backing from my management, and then I also need this steering committee cadence which has to be properly managed.

00:20:54: Those are sort of the three points that i've noted down for now.

00:20:57: once I have them am I good-to-go with the first point leadership ownership?

00:21:02: Are those pretty much central points ?

00:21:05: I'd say it's a prerequisite for success but its not quite enough yet.

00:21:10: The reason is because This brings me a bit into the organization of the whole thing.

00:21:18: The person who's in the driver seat right now, but also everyone working around them so I'd see them as part of the core team.

00:21:25: they have to get a certain dedicated capacity for this project XY For whether it is an MBSE project or product improvement project... ...I've often seen that these topics were not prioritized because customer projects were competing with them.

00:21:44: And of course, if that's not driven by management either and so to speak from above predefined where the priorities lie then The Customer Project will always win out.

00:21:56: Yeah!

00:21:56: Because it has got a higher urgency.

00:21:58: Not higher importance significance but simply the urgency.

00:22:02: That is why its important to make clear on the outset that team or person XY who are responsible for this project is also allowed and required to dedicate, say fifty percent just as an example of their time to it no matter what happens.

00:22:19: And you then have to compensate for the capacity for customer projects elsewhere.

00:22:25: but its not enough.

00:22:26: simply get on with that because this problem is priority.

00:22:38: Well, for the environment around that team as well because one person alone can't do it all.

00:22:43: So implementing MBS E after hours like that?

00:22:46: That's obviously not going to work.

00:22:48: we know that.

00:22:49: but I think you probably also need To find some kind of pragmatic balance between The absolute demand Of saying right i need a hundred percent of your time For the next three months You Can't Do Anything At All For Clients Anymore and actual customer focus.

00:23:06: I think we might talk a bit more about that later.

00:23:09: when it comes to the implementation, i've kind of followed from your projects as well uh...that you have a few tricks up your sleeve for how to balance that thing without giving too much away right now.

00:23:21: but what's important at least is that we understand this tension for the implementation and there might potentially be a conflict of objectives with client projects, we need to recognize that then resolve it individually.

00:23:43: Okay very good from your perspective.

00:23:49: now under the organization side-of things enablement you called earlier as well We need capacity.

00:23:56: who should typically provide this capacity?

00:23:59: is just anyone?

00:24:01: or Do you see specific roles from your experience that would be particularly suited there?

00:24:08: Yeah.

00:24:09: That ties in, so that links up very closely with the point from earlier.

00:24:14: and that's the question who should actually lead or which team should lead?

00:24:18: the whole thing right.

00:24:21: And what I've experienced is not often it happens to be spare.

00:24:31: Sometimes people bring in a working student or an intern here and there, which I don't mean to talk down at all because they can definitely make a contribution.

00:24:39: But really for work package X-Y... ...I think it's very important that the person brings certain amount of experience into the table And not just from other companies but also within the company itself Because its'nt about understanding products Technically, of course.

00:25:01: So the products, the portfolio that's an important component but it is also about understanding the organization and having contacts within the organization because you will definitely encounter resistance on these topics.

00:25:14: That's just how it is.

00:25:15: A change process always has resistance Always brings resistance with it And can spread very... The fire spreads significantly Very quickly.

00:25:28: that the person is someone who brings that experience and has contacts at the same time.

00:25:35: So, it's a strong network which is very helpful.

00:25:38: Those were also projects where we had success ideally with dedicated capacity And then that person in the driver seat.

00:25:48: That would be a dream.

00:25:49: It doesn't always work out but this kind of ideal scenario Anything can happen and this person, talk to the stakeholders knows products as well.

00:26:02: Can also prioritize which product might be brought forward?

00:26:06: That is really important.

00:26:09: It's not just a matter of having methodological foundation or software per se knowing your way around the software but it simply vital that these other factors play an important role.

00:26:23: I'd call it organizational intuition.

00:26:26: We have in the past done a few projects simultaneously together or in parallel.

00:26:32: And sometimes it really is the case that when you have a person on the client side who has this intuition, someone who knows where hidden stakeholders might be for example Or to put it bluntly Someone Who Knows That Mr Müller Has Spent The Last Seven Years Drawing Requirements In Visio and Loves It so that this person knows that.

00:26:55: And coming from the outside, we don't know either and probably realize just as little that Mr Müller even exists.

00:27:02: but knowing that being able to navigate it I think is why you need this organizational intuition exactly.

00:27:13: Maybe follow up on that because thats very close.

00:27:17: another topic namely You NEED THAT INTOITION TO IDENTIFY THIS PERSON.

00:27:23: Yeah, and not late but usually early on because... And this is another point.

00:27:28: You have to have resilience, organizational resilience.

00:27:31: that means it doesn't just fall apart somehow That you don't bring the cost engineer into the project midway through.

00:27:40: He thinks oh my god what are you doing here?

00:27:43: That's competing with my own project in my own spreadsheet.

00:27:53: Have I, for instance pinned the project entirely on one person or does it rest?

00:27:59: Let's say.

00:27:59: Does It have a broader foundation so that if That person leaves The company and then you can still let Say prioritize and push ahead with this topic?

00:28:08: i've had all of that happen as well Where everything basically ground to a halt With One Person.

00:28:15: So All These Things are Important And Its All Interconnected As You Can See Right that person who gets picked, this transformation leader the one wearing their hat.

00:28:26: They naturally have to be like I said well connected and so on And quite rightly said Thomas they have to identify people might be potential opponents... ...they try get them onboard.. ..and also need soft skills by way of doing it because is a very difficult process.

00:28:44: For me its also one of most crucial points for all project success getting the team on board with you.

00:28:53: I think we've gone quite deep into the whole organization side of things now, and the way i see it that was also a bit of how to straight from hands-on project experience spotting early on potential...I won't call them adversaries but spotting people earlier who might have different agendas or different incentives.

00:29:14: uh spotting that where possible and being able to resolve it.

00:29:20: And I think that brings us right back full circle too.

00:29:22: earlier when you said, yeah i need executive management.

00:29:25: well why do i need them?

00:29:26: because maybe someone In terms of, let's just say their remuneration is incentivized in such a way that this project brings them more disadvantages than advantages.

00:29:36: So with respect to course I'd need to adjust the lever together with management.

00:29:39: so really important.

00:29:40: these things are massively interconnected.

00:29:42: but if you're okay with it just briefly wrap up this second point on this organization enablement topic because what i would like now is hear about your third area mentioned earlier.

00:29:55: everything is supposed to lead, it's meant to lead to execution and implementation.

00:30:04: If I've got all of that in place if i'm in the driving seat... ...if I have an organization on board or spot potential disruptors early-on and do something about them am I safe then?

00:30:18: Or are there still stumbling blocks during implementation you'd want to point out?

00:30:28: Absolutely, maybe just one addition to before.

00:30:33: What we described earlier is essentially the organization topic.

00:30:35: that's something I need to keep in mind right from the start.

00:30:38: but of course i've also got processes and IT.

00:30:40: so where does my tool go?

00:30:42: All these topics ought be considered.

00:30:44: it not about defining a stakeholder map who could potentially be against it.

00:30:49: It's much broader than that.

00:30:51: But back your question Thomas.

00:30:54: It's obviously about generating this value continuously, but we've already covered that right?

00:30:58: it simply not enough to build up the suspense over eighteen months and then To stand on stage.

00:31:04: curtain goes up.

00:31:05: And oh That's not what I wanted at all.

00:31:07: in the worst case scenario You've completely left the steering committee out of the loop and that is Well, that's the recipe for an unsuccessful project that i can genuinely say.

00:31:17: So that-that's the foundation.

00:31:18: We've...we've already covered that.

00:31:20: another point And I think this is a mistake.

00:31:23: A lot of people make seeing the initiative as a detached initiative, meaning they see a product improvement project, a blueprint for the future and they detach it from all these customer projects which have high urgency for their customers.

00:31:39: we've spoken about that already too.

00:31:43: The trouble with the whole thing if you don't connect then you can't clearly demonstrate this value to the stakeholders because as You said they have their own interests and if you don't empower them tomorrow with x y. so for instance Tracking changes.

00:32:00: Yeah, what does it mean?

00:32:03: If the Mechanical engineer makes a change there Does it impact my overall system or not?

00:32:10: And because that is essential for delivery For successful project completion and that this connection between the conceptual, project blueprint architecture definition an instance currently running ideally.

00:32:29: That is already providing certain results but isn't finished yet has lots of questions it might want answered through this conceptual project.

00:32:38: to me thats key because then I can tie value directly something relevant customer.

00:32:45: I also get greater buy-in than if it's completely detached.

00:32:49: And the resources are so much easier to justify, because they're then indirectly working on a customer project when they provide expert knowledge.

00:32:59: for me that is really essential.

00:33:02: and one point i see with this execution with proper execution very often now i've got methodological background myself.

00:33:15: you can easily get bogged down, for instance in modeling functions.

00:33:19: Modeling architectures but In the end it's essential that there is an off-taker and a user And That one side of this usage site But also strategically anchored.

00:33:33: What should our products look like?

00:33:36: what does my portfolio looks Like?

00:33:42: That's where we sit.

00:33:43: We have to, in this balancing act between strategic and usage be it a CAD engineer or CAE engineer somehow manage to establish relevance And very often that isn't done.

00:34:04: We squander a massive amount of resources and in the end we get product that maybe has zero buy-in left.

00:34:13: We essentially lose these offtakers, users or potentially management as well which means you need to make sure that model with purpose.

00:34:23: there must be a purpose behind it because I can go into endless detail, I can model the product at even greater depth but don't need down to very last bolt function.

00:34:33: That's decisive thing!

00:34:34: I always have tie up to goal tied usage and only then do my modeling, rather than the other way around where I just start modeling away.

00:34:42: And if worse comes to worst this ties into that other point right?

00:34:46: Not continuous value but i spent eighteen months on it!

00:34:50: I've worked on something that ultimately has no off-taker at all isn't strategically anchored at all.

00:34:56: um yeah a functional model has been created fantastic...and what do i do with it now?

00:35:02: No idea.

00:35:03: So those are the kinds of hurdles you face, and there always has to be relevance too.

00:35:08: You often talk about in other contexts connected engineering.

00:35:11: I think that's also a really crucial point.

00:35:13: if i translate what you just said for myself The user Of a model needs to be clear from the start And What they're doing with it Like, what do I need it for?

00:35:26: as let's say a developer?

00:35:27: A PCB developer or mechanical engineer.

00:35:30: What do I needed for our software engineer?

00:35:34: are my test cases in there, For instance is that Is that linked to the model somehow?

00:35:39: and when i When I understand That then naturally also inevitably Understand how far I Need To Model And thats what you're saying.

00:35:48: so meaning by orienting towards consumer of the model, not quite the right phrasing I know.

00:35:59: I automatically create relevance Right?

00:36:03: I can work with.

00:36:03: that gives me value That actually matches my own project experience when developers suddenly go hey Now i Can Actually See The Context Of My Work.

00:36:14: That's A Massive Benefit Exactly.

00:36:19: You Put It Very Well Earlier Model With Purpose.

00:36:23: Let me circle back to one point, though.

00:36:27: That you mentioned I think two points ago and i'd like to touch on that very briefly already quite pressed for time but still this topic of orienting towards value uh...that sounds great at first obviously But surely you have to do that somehow pragmatically and methodically.

00:36:46: You have to reflect that in a project methodology.

00:36:50: How do you see or how would go about it?

00:36:54: Well, I think you have to look the stakeholders.

00:36:58: The users You call them uses?

00:37:00: I think that's fine.

00:37:01: to call them users Always look at how do they work?

00:37:07: what do they need?

00:37:08: where do they have changes for instance That maybe aren't traceable?

00:37:17: Which other stakeholders are involved as well?

00:37:19: What tools are they using?

00:37:21: and They define my work obviously in the modeling, in the architecture.

00:37:29: And if I don't marry these two worlds then i've got this lighthouse and...I'm missing the bridge!

00:37:41: Yeah into the user's world and ideally it'd be bi-directional.

00:37:46: you mentioned introduced connected engineering earlier.

00:37:50: This connected engineering isn't just an MBS e-topic.

00:37:53: It goes further, right?

00:37:55: And it also goes towards CAD for example and there you have to see that things can be triggered by the users in this case as we've said.

00:38:09: That could go other way around too meaning You have to establish use cases and model via use cases, And then also see okay How do we work so?

00:38:23: We have to set it up once based on relevance But then we need a concept for how to use it Continuously.

00:38:30: right.

00:38:30: that's the second aspect That often gets forgotten because in my view MBS E isn't just one-off thing.

00:38:36: That's how It's often understood your early phase of product development.

00:38:40: All the stakeholders sit down together.

00:38:42: We avoid the waterfall model, we all work on functions.

00:38:46: that's well and good but you need to establish it sustainably in the company And establishment works through this usage.

00:38:54: Often there is a pull from user.

00:38:58: I have to respond to that pull.

00:39:01: There are collaboration software tools enable this bridge between the two worlds where the barrier to entry isn't so high for these users.

00:39:16: To just look into our tool, but whether they can initiate a review process from the user side?

00:39:22: For instance an electrical engineer has question X Y and kicks off a review processes gets in answer to a questions that sits on the MbSE site.

00:39:34: That means you have to lower this threshold which still exists towards the MbSE silo, um...to help it land with the organization.

00:39:43: With the overall organisation and that I think is the key?

00:39:46: I don't know if we can do anything

00:39:47: about it.

00:39:48: Yes absolutely!

00:39:49: For today i reckon We should roughly leave at looking my own notes.

00:39:56: It actually looks like a cheat sheet.

00:39:59: Looking at it right now, I think there are ten points written down here that you mentioned.

00:40:04: Um...I suspect quite a few listeners have probably been taking diligent notes as well but you don't really need to i think.

00:40:11: do you have what you just laid out for us in such a structured way available?

00:40:15: As a cheat sheet You could share with others?

00:40:18: Definitely!

00:40:19: I've created an extended cheat sheet Just to present my knowledge In an aggregated Way And That's Available.

00:40:28: You can get hold of it if you want, and all you have to do is get in touch with us.

00:40:34: Then I suggest we just link either a link or your email address on the show notes so people could help themselves.

00:40:42: So anyone who's been taking notes up to this point didn't need too Right!

00:40:47: With that David A huge thank-you To YOU.

00:40:53: You've drawn us wonderfully structured roadmap Of what really matters when we run MBSC projects or generally want to approach model-based working in an organization.

00:41:07: Brilliant stuff, including if I've counted correctly a ten point plan... Super!

00:41:14: Thanks a lot for that.

00:41:15: Absolute pleasure.

00:41:16: it was great fun Thomas

00:41:17: thanks and that brings us to the end of our fifth episode.

00:41:24: To all our listeners, first of all thank you very much for tuning in and those who are paying close attention looking back a bit over past episodes will have realized we've reached out third topic block so to speak.

00:41:35: We started off talking about what is requirements complexity?

00:41:40: We talked about systems thinking...we then discussed MBS-E What Is It Even And Where Is it Used In Companies?

00:41:48: ...and now I think since the last episode, Episode four we've gone right into the nitty-gritty of implementation.

00:41:55: We want to carry on with that!

00:41:57: That was also the feedback from you our listeners.

00:42:01: so we're going to explore implementation in a bit more depth and looking ahead to the upcoming episodes in The Autumn through To End Of The Year will hear directly about how things look for them.

00:42:19: With that, I'd like to say a huge thank you all and once again David.

00:42:24: Thank you so much for coming on today.