Dr Darren's Open Letter on managing a range of skill levels at SysML/MBSE courses (for trainers, training organisations, and their potential clients)

Icon class
icon_class_computed
fas fa-book
This is an open letter to MBSE trainers (especially SysML trainers), training organisations, and to organisations seeking to engage trainers and training organisations. It is not specific to the Webel IT Australia courses. It's for all of us involved in the SysML education community.
This content is "read-only" for your possible interest. Feedback or further questions by email or contact form concerning this content and topic will not be accepted in this case.

This page is dedicated to all trainers of the Systems Modeling Language (SysML) for Model-Based Systems Engineering, who all help to promote and disseminate knowledge about this wonderful technology we love so much. Because we've seen it work.

SysML, being a (primarily) graphically based modelling language, can present some special challenges for trainers and attendees of training courses. Some people just have a "knack" with visual representations and data structures, some do not.

An analogy: Some people, for whatever reason, can naturally always sing in tune. Some, for whatever reason, can't. Maybe someone who is not a natural singer is a natural with a violin. Some people may be able to learn to sing in tune better with correct coaching, some people however just do not have that "knack" and struggle, and sometimes no amount of coaching or training can help them learn to sing in tune. It is not a judgement, it just is.

For example, I'm completely rubbish at rugby league football; I don't judge myself for it, and nobody I know does. Some of the loveliest of my friends are completely hopeless with maths, but it doesn't stop me loving them, especially the ones who are genius cooks. People have various skills and "knacks" at various things.

Did you know? Wolfgang Pauli, one of the greatest theoretical physicists of all time, was so completely rubbish at lab work that the Pauli Effect was named after him to describe stuff going haywire in labs! It's not the same as the Pauli Exclusion Principle, but he did end up getting excluded from labs.

For people completely new to SysML, the very first stages of learning it can be unsettling. If they have a high level of competency in other professional areas, it can be confronting to have to start something essentially from scratch. Often during the first couple of days of a course they may feel they are making less progress than they actually are, then suddenly the pieces of the puzzle start fitting together and they are off and running. I'm sure many other SysML trainers can relate to that; you know from experience that they will indeed get on top of it, and it's very rewarding when you see it "just click".

... some random thing about Yoda and patience and Padawans or something ...

Beyond the SysML language itself, there is the tool, and learning new features. The aim is to get people into their "engineering zone" where they don't have to think about where a certain menu item is, and can focus on modelling their engineering domain projects in SysML, which of course takes some time and practice, and often takes some back and forth until people cognitively can juggle the GUI aspects and the SysML language aspects.

It is important when organising courses to have a way of managing different skill and experience levels.

If there are one or two people who, for whatever reason, are really struggling compared with the others, it can make things very difficult for everyone concerned. It can impact on the logical flow, it can make it hard to get all attendees on the same page as you introduce the SysML language step by step through themes and topics that build on each other consistently.

SysML for MBSE is one of those study areas where someone only has to miss one or two concepts and suddenly their comprehension can plummet and they have little chance of understanding the later topics, even the more basic ones (which may not even be harder, but may rely on understanding of a previous topic).

This can even, in some very rare cases, trigger discomfort or even anxiety reactions, especially if an attendee notices that other attendees are managing better. (Sometimes you have someone attending who has worked with electronics or circuit design tools or similar for years and they just storm through it effortlessly.)

It is tempting when offering to hold a course to accept all attendees at all skill levels in a single group (especially if it is a smaller group). It is tempting as the client for simplicity to try to place as many of the candidate attendees into a single course as possible; it's expedient and means there is less planning and less paperwork. The client may think it's a good idea because all candidate attendees will be working on their projects together.

But it is not always a good idea, and it is not always fair on the presenter, nor on the one or two attendees who are struggling, nor on the other more "natural" attendees. And it is very difficult to address if potential issues are identified after the course has commenced. Of course there are ways of teaching and adapting SysML course content so that it more appropriately pitched to specific skill levels, but it can be much harder to do that once a course has started - and can even make some attendees feel uncomfortable that their struggle with this specific technology has been "exposed" before their peers, which is of course not the intention of any trainer.

To trainers: It takes courage, but if you wish to do the best by everyone concerned (and in representation of the benefits of SysML for MBSE) you need to be able to ask the hard questions of clients about the skill levels of all attendees. For Webel IT Australia courses I have a simple questionnaire for each candidate attendee about their prior experience (if any) with the SysML language, SysML tools, UML (relevant for SysMLv1), object oriented languages (useful especially for inheritance topics), and experience with relevant technologies such as 3D modelling tools, electronics design tools, etc. But that is not always enough to predict how someone is going to cope in a course.

To clients: If you are aware that any of the attendees may be significantly less experienced with SysML or related technologies and tools, or may have learning difficulties, you have an obligation to the trainer and training organisation to disclose it, so that the trainer can discuss helpful strategies in advance of the course. Before!

Most trainers are perfectly happy to work with attendees who may find the SysML/MBSE topics and tools more challenging than the other attendees, and may have a range of training materials and worked sample problems for various skill levels. Sometimes this can be managed (in larger classes) by splitting the attendees into teams/groups. Sometimes this can be managed better by having separate training sessions even if it costs more (but is worth it because the results may be better). In my experience, it is much harder to manage an attendee who is not coping as well as the others in a smaller group.

Most trainers have a friendly, pleasant, and polite style, but they are not there to win a popularity contest, and they are not their primarily because of their personality! They aren't YouTube influencers paid to collect "likes". They are there because of their expertise in SysML/MBSE and experience as educators.

In fact, SysML trainers have the best personalities of all and the best senses of humour, even if not everyone understands why an Internal Block Diagram (IBD) can sometimes be really funny.

Above all, trainers are not there as trained psychologists to manage people who may (although it's very uncommon) react badly or behave disrespectfully to the trainer or other attendees as a result of struggling with the SysML language training topics or tools, and may demand a disproportionate amount of help (at the expense of other attendees, even if they do not do this maliciously).

Clients have a common sense duty of disclosure to training providers about potential problem attendees. Please talk openly to your trainer before a course to find constructive ways to balance the needs of all attendees.

Trainers have a common sense duty of disclosure to clients if problems arise during a course, and if a trainer does raise issues with a client, the client should understand that the trainer is doing this for a good, well meant, reason, likely based on years of experience with many course attendees of varying skills levels.

I'm certain no SysML trainer wants to insult or ridicule any attendee, and if a trainer approaches a client about potential issues with an attendee, the client should please graciously welcome and consider any advice offered, it's an opportunity to work together and pitch topics to the attendee to their benefit and to the benefit of all parties. It may also involve reorganising the attendance schedules or attendance structure.

In my experience, nearly every attendee with some background in engineering, science, IT, maths, or physics will eventually achieve sufficient skills with SysML and SysML tools to be able to professionally work with them for MBSE, and will eventually be able to collaborate with others (some of whom may really excel, the natural modelling "wizards").

But sometimes, a client is just going to have accept a trainer's well meant advice that a particular attendee does not have sufficient natural ability to work with graphical modelling languages, and trying to force someone to command the subject not appropriate. And it is a caring, considerate thing for the trainer to does as a professional!

If a trainer recommends to a client that an attendee is not suitable for further participation, they might choose to offer a refund for that student's slot, but that's a contractual matter between the client and training organisation, not some kind de facto industry rule.

No trainer can promise that every single attendee at every course will fully command SysML for MBSE sufficient for professional use after just one training course, no matter how well they teach, and no matter how much experience they have with the SysML language. They can only do their job as well as circumstances permit.

To clients: Given a choice between a sweet-talking trainer who promises you that every candidate attendee will master SysML and who tells every attendee that they are doing splendidly and that every kind of attendee can and should attend their course ($$$ greed), and a realistic, serious trainer who advises limiting attendee number so they can focus on attendees who are likely to go on and use SysML for MBSE on real-world projects, I strongly recommend that you prefer the realistic, serious trainer!
Trainers deserve a safe working environment and professional and personal respect from attendees (even struggling ones)

Finally, obviously, no trainer or attendee should have to suffer verbal abuse from a struggling student, and if a trainer advises a client that an attendee is behaving inappropriately and that it is affecting the well-being and participation of others, the client has an obligation to take that up with the attendee, not blame the trainer, and certainly not "dock" them financially!

No trainer should be expected to offer a refund for an attendee who has been abusive, and certainly, not trainer should be expected to offer a refund on a partially cancelled course due to abusive behaviour of an attendee!

If an attendee is abusive or disrespectful, it is their own fault. Difficulty with a training topic is not an excuse to abuse a trainer or other attendees. Abusive attendees need to be removed from the training space with their employer (the client) supporting the trainer. Trainers have a basic right to a safe working environment, and a right to be able to request that an abusive attendee leave the training space immediately (if the client/employer has not already). It is important that their employer (the client) then also makes it clear to the other attendees that such behaviour will not be condoned.

Trainers also have a basic right not to be unfairly blamed by an attendee for the professional inadequacies of that attendee. And in my experience, it is the attendees who take ultimate responsibility for their learning who progress, it is the ones who blame others who learn the least.

If you are an attendee and "choose" to not attend all training sessions, and have thus missed a crucial step, please don't then blame the trainer when you can't understand the topics that come later.
Happy SysMLers!

So let's all be open and frank with each other as early as possible in negotiating and planning courses so that the training arrangements and training materials and presentation can be tuned for the optimal benefit of all attendees of all skill levels, and with realistic expectations. Nearly everyone with a technical background can make progress with and can enjoy learning SysML for MBSE. Eventually, they may even become addicted to the joy of modelling!

Yours Systematically,

Dr Darren


A postscript to the bad guys

Are you a greedy training organisation who keeps offering to accept far too many attendees at once in SysML courses ("padding them" with everyone and anyone no matter what chance they have of actually learning it well) to make more $$$ money without respectful consideration of your client and their attendees (especially where clients have no prior experience with SysML and are easily taken advantage of)?

Please don't, it's a disservice to the SysML community and to the promotion of SysML for MBSE. Having fewer attendees of appropriate ability who then learn well and go on to use SysML professionally is the decent thing to do, even if you don't (short term) profit as much.

The best SysML trainers and training organisations offer training because of their love of the technology, their conviction of its effectiveness, and desire to promote it and the SysML and MBSE communities, not just for $$$ money.

For the love of SysML and MBSE.

Notes
Relevant snippets (from other sources)
Visit also
Visit also (backlinks)
Flags