Product Development & Management

Four Techniques to Make Models More Valuable in Product Development

By |

Models are ubiquitous in product development. There are many different models, including CAD models, systems models and simulation models. Very often, only a small group of experts creates and uses a specific model. This is not surprising; one definition of “model” is “a simplified representation of something for a purpose.” But this hinders collaboration, as one group’s model might be meaningless to another group.

Does this mean that models are doomed to be confined to silos? Of course not, but it takes active work to make them accessible and useful for every stakeholder who might benefit from them. For innovative companies, ensuring that models serve all stakeholders is imperative to unlocking the benefits of modeling and justifying the initial investment.

Identify Friction, Define Value

Before you can solve a problem, you need to recognize it.

If you are reading this article, chances are you already have something in mind (“Why do I have to explain every detail of this SysML IBD to my manager?”). Be sure to concisely identify the problem: Which aspect of the SysML model does your manager need to understand and why?

Efficiency is often a concern. For instance, a change request from a stakeholder may result in multiple, manual, error-prone updates across your models. If this applies, try to quantify the amount of effort exerted through manual transcription of information from one model to another.

In short, take the time to identify the problem to be solved, document it and discuss it with your stakeholders.

Four techniques to make models more valuable

Once you understand the value of broadening the use of your models, you can search for the right solution. The following four techniques allow you to boost the value of the model that you already have and maintain.

1. Extract KPIs

One of the easiest approaches for leveraging models is to generate key performance indicators (KPIs) for your stakeholders. This is particularly useful for reporting up to stakeholders who are not really interested in the details. KPIs are often metrics like progress, burndown rate or potential bottlenecks.

Some modeling tools are already capable of generating KPIs that are useful for other stakeholders. In particular, software tools often feature metrics like code coverage, burndown rate, defect age, and others right out of the box.

A far greater number of modeling tools, on the other hand, have no features of this kind, but do at least have scripting facilities that allow you to generate metrics. Of course, you need to know what you are looking for.

2. Produce Customized Views

Related to KPIs is the creation of views that are acceptable to your stakeholders. In contrast to KPIs, views typically contain relevant information, not just aggregated data. Most tools include reporting facilities powerful enough to produce reports that stakeholders will accept.

As an example, I once worked on a project where we defined the requirements in UML, a language that the customer and the product manager were not familiar with. By carefully building a custom report, we could generate Word documents that the stakeholders accepted and embraced. I actually wrote about this project for IREB’s Requirements Engineering Magazine.

Keep in mind that you will never be able to generate a view as elegant as a hand-crafted artifact. Depending on the capabilities of the report generator, you may still have to invest in teaching the stakeholders how to read and understand the deliverable.

3. Teach the Stakeholders to Read

This is obvious, but often forgotten: If you cannot completely hide the model behind a view that’s easy for the stakeholders to understand, then you must teach them how to read the modeling notation you use. Stakeholders don’t need to learn the complete modeling language, only certain aspects; depending on your situation, a one-hour training session could be sufficient.

Some organizations understand the need to teach the modeling language but send everybody — both creators and readers — to the same training. Since standard trainings focus on creation, this forces all stakeholders to sit through a time-consuming training that only a few of them actually need.

4. Integrations

The most elegant and effective (but also expensive) approach to broadening the use of models is integrating them.

For instance, most products start with textual stakeholder requirements. These get refined into system requirements and eventually design. Textual requirements are typically also modeled, but with a simple data model consisting of entities and relationships. At some point, however, you may want to switch to a different systems model, for instance by using SysML. Ideally, the two models are linked, so that you have end-to-end traceability from your requirements tool to your systems modeling tool.

Using integrated tools gives you two advantages. First, stakeholders operate in an environment that they are familiar with. Second, integration allows changes in one model to propagate to another model. This is a big advantage that can remove a lot of friction.

While there are solutions that promise “one model for all,” in practice, you end up with a monolithic tool that is mediocre. In practice, an integrated “best of breed” tool chain performs better and poses less risk, as individual components can be exchanged if needed. For more on this, see our blog post, “7 New Approaches for Model-Based System Engineering.”

Plan and Buy, Don’t Grow and Build

All too often, we see product development environments that grew over years or even decades. Tools were added without giving thought to integration beforehand, and brittle scripts hold everything together. This was fine 20 years ago, but in today’s world, it’s a severe competitive disadvantage.

The four techniques described above are tactics, but they need to be applied in the context of an overarching modeling strategy. From this you can derive proper model and tool architectures.

When selecting new modeling languages and corresponding tools, attention should be given to the use cases they need to support. More importantly, new modeling languages and tools need to support all stakeholders’ use cases, not just their direct users’. All use cases should support one of these business priorities: Improve quality, accelerate development or use resources more efficiently.

For all four tactics, the existing off-the-shelf solutions are preferable to self-build solutions. After all, you’re busy creating complex products in a competitive market; you don’t want to waste resources building internal software.

Key takeaways:

  1. KPIs can be produced to help inform your product development process.
  2. A good modeling tool should provide facilities for customized views (web-based, custom reports or otherwise). There are also third-party reporting tools that connect directly to data sources.
  3. If you have more than a handful of stakeholders, outsource training courses for reading models. There are excellent training providers for all standardized modeling languages. Make sure that you provide tailored training, even if it is more expensive than canned trainings.
  4. Integration is hard, so rather than writing brittle scripts, use an existing integration hub like Tasktop. This solutions is robust and easy to configure.

The good news is that you can transform your product development iteratively. As your business evolves, make sure that each upgrade aligns with your modeling strategy. You will unlock new value from your existing models in no time.

If these ideas resonate with you, check out our whitepaper, “Systems Engineering and Development” for thoughts on building better products, with input provided by the author of this post, Michael Jastram. 

Latest posts by Michael Jastram (see all)