This post is the fourth and last in a short series on how to talk about modeling in the scope of product (or systems) development. You can read the other parts here:

• Part 1: Model vs. Tool
• Part 2: CMT/A
• Part 3: Maturities
• Part 4: Stakeholders and Expertise

This post will build on the basic concepts introduced in the earlier posts, integrate them, and put a holistic view on top. Before we do that, let’s recap the CMT/A thinking tool on a high level:

• It is important to make a very clear distinction between model and (digital) tool.
• CMT/A distinguishes between the following aspects: a tool (T), its underlying concepts (C), a method (M) on how to use the tool (or which may be supported by the tool), and a specific situation to which the tool is applied: the application (A).
• In a specific situation, each of the aspects concepts, model, tool, or application has a certain maturity, which can be made explicit.
• Each of the aspects concepts, model, tool, or application has one or more stakeholders (typefied in stakeholder roles) that want to achieve something with it.
• Each person fulfilling a stakeholder role has a certain level of expertise. Not all expertise is equal and we can differentiates types of expertise.

Using one or more of the above concepts from the CMT/A thinking tool, you can be much more precise about:

• Which assets (in terms of CMT/A) are concerned?
• What is the current maturity level of each asset separately?
• Are all relevant roles assigned?
• What is the current expertise (problem- and solution-related) of the involved people?

Once you have the above, you can start describing:

• What is the desired maturity of (some of) the assets?
• What is the desired expertise level of the involved people?

This is a very powerful way of communicating with your environment. We already saw that by being more explicit when talking about modeling, we can provide support in analyzing different contexts to support decisions on required next steps. Being more explicit, means to be precise and specific in naming and identifying the various elements and aspects (technological, organizational, and any other) in a modeling context. By doing that, we are actually able to describe different options much more clearly and make the required decisions. And that is how we can compare, choose, and steer towards the desired direction in a more targeted fashion and with better arguments for all stakeholders involved.

In this way you can compare different directions more precisely and steer for the desired result more targeted.

If you want to talk about the impact that a model can make in a certain context, you have to describe the context much more precisely. To do this, use the metaphor of your company context as an internal “market economy”, where each circle represents a team:

Each team has to deliver value to another team. There are dependencies between the teams, where a team needs results from other teams and in turn delivers results to other teams or the customer. Start describing:

• The results that a certain team/context provides: the final and intermediate results
• Activities to get to the results
• The people and roles required (with their concrete responsibilities) and how that maps to the results and activities

Once the context is sufficiently understood, you can reflect on the following:

1. Which results and activities are represented and supported by digital assets?
2. What is the desired future, vision, roadmap? What are first feasible steps…?

So only once you know what is the most imporant, most most error-prone, error-prone, most difficult, most critical result, you can speak about the impact of introducing a model in that place for a result (e.g. for better communication and less errors or for more automation and faster results by automating activities). Only then you can start talking about what the future steps are that make sense. You can always have a good roadmap for where you want to be (first few important steps) without having the full plan.

Once we have the roles in a team, we can see how they relate to the product development roles. In reality you will have to make mapping between the roles described in CMT/A and the product development roles. This may result in vacancies, which is important information. It is also important to realize that the same person can have different roles. Sometimes one person can have different roles in different contexts.

Then you can go on to describe the benefit of introducing a modeling asset and activities going with it. The FQ$T-tradeoff: do we want a lot of functionality, do we want good quality, do we want it cheap, or do we want it fast. You can also think about risks: if we don´t have this modeling support, what does it mean for the team performance?

Once you can do this exercise with CMT/A for one tool and one model, you can scale this up to interconnected tools within one contexts or between different contexts. How does this grow as a network? What is the impact of adding a tool into the mix of an existing ecosystem of tools?

Finally, you can ask yourself what is the relation to the data (ML, big data, logging) domain. In the wider context of Continuous Digital Transformation, not just modeling, but also data plays a big role. You can use this context mapping to describe and analyze impact the leveraging of data has – or can have – in your context.

This concludes my fifth and last post, and thus the short series on How to talk about systems modeling. I hope you found the material helpful for better understanding and clearly communicating about modeling with others, and will be able to use in your own product development context.

One final thought: when you have to understand and communicate a topic like the one I described - involving technology, processes, product, people, and organization - discussions with stakeholders can get difficult. It helps to have the perspective that the teams have to always do things together for a bigger goal. My favorite phrase related to this is: for each other, with each other.

Thanks for reading and see you in another post!