Dr Darren's strategies for effectively introducing SysML for MBSE on your projects and the importance of extracting incremental benefit from the powerful SysML language and MBSE tools

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

• Don’t try to tackle too much at once. SysML is designed to reuse working sections progressively.
• Integration across a team is aspirational, but ambitious, and should not be prioritised above just getting useful stuff done. If you at first work in relative isolation with specific strategies that add incremental benefit, but don’t initially integrate across all interfaces and such, it’s not so bad. Better to demonstrate incremental benefit for your specific tasks or area than end up with nothing.
• Create lots of little diagrams with model elements that each tell a mini story. Diagrams are cheap!
• If you are modelling an entire complex Systems Of Systems, create many diagrams at different levels of abstraction, and use IBDs as the primary mechanism for communication with management. (And hide some info from display sometimes.)
• You can create multiple IBDs within the same complex context, showing different levels of abstraction.
• Use text extracts from domain source documents that each tell a "mini story" to guide your modelling.
• Graphical + Text is more powerful than either alone. There is a “cognitive resonance” that activates different parts of your brain in parallel and in a powerful complementary way when text is combined with graphical aspects, and including text also helps communicate with those colleagues and stakeholders who are not fluent in SysML. This is a very practical matter, not just “esoterics”!
• Even just using Comment or ElementGroup with domain source text extracts initially without full traceability (such as under the  Webel Parsing Analysis recipe for SysML^®) will give you the overwhelming majority of the benefit of the above Graphical+Text principle! Longer term, mastering the  Webel Parsing Analysis recipe for SysML^® provides great benefit (and will help prepare you also for the new world of NLP-generated SysMLv2 models).
• Focus on demonstrating incremental benefit (and communicate that to your management).
• To support the above, address specific pre-stated tasks. Ask what the tool and SysML language can do for you that you need most, triaged, don’t just try to produce stuff with all that is possible with SysML and your tool!
• Use query view tables, use them often, pull info from your model into tables, it will help guide refactoring of your models, and give you a “results” container that is accessible to colleagues not familiar with the graphical notations of SysML.
• When presenting your results to management, focus on specific extracted results using tables. Avoid showing SysML Diagrams just for the sake of demonstrating your modelling diligence, show actual benefit. Restrict SysML Diagrams shown to management to high level abstraction IBDs and similar. Try to show SysML Diagrams in combination with query view tables that extract info from the model represented in them.
• Don’t Panic about “breaking things”! The Single Source of Truth SysML language and SysML tools are far more forgiving to changes than other tools your may have worked with.
• Don’t stress about ownership (packaging) of model elements early on; focus on getting the “logical” or “narrative" view of the model right in small sections, piece by piece, then address ownership later using little regular "house cleaning" sweeps, often at the end or start of the day is good, using separate mindset from your main modelling. (In Cameo, use the Dependency Checker to resolve ownership issues when exporting shared packages.)

The Tortoise and the Hare fable is your guide!

You are better off doing lots of small modelling tasks slowly, carefully, and getting them right, rather than racing to get stuff done over the larger model of a very complex system.

It’s like any complex structure or machine; if you get the pieces working properly the larger engine that uses the pieces will then run.

Another analogy is a pilot flame or small starter engine; if you get the smaller sections right, the pilot flame or stater engine will suddenly kick in and ignite the real flame, the full engine will suddenly turn on, but you can’t force it by tackling it all at once.

If you can demonstrate incremental benefit you will likely get more support from your management for use of the technology than if you try to tackle too much at once then falter. Play the long term game.

Finally, the single biggest reason that people encounter problems with SysML for MBSE is NOT that it can’t do MBSE well, it’s exactly the opposite. It’s precisely because it can do so much that people can flounder, because there are so many options and so many powers that it can all get out of control.

So, just like John Gall said, build from smaller model sections that are self consistent and accurate. You can track this by using high level abstractions across a complex project, but trying to tackle everything at once from the point of view of a complex systems of systems is not well advised.

And remember always:

Dr Darren says: 'You can't obtain the optimum benefit of graphical engineering with SysML without becoming mindful of the cognitive and artistic aspects of graphical modelling. The "Zen of SysML" matters!' Just like an elegant electronics device design.