Join me for another exciting webinar taking a good look at standard work and its many benefits, next Tuesday at 1pm
Join me for another exciting webinar taking a good look at standard work and its many benefits, next Tuesday at 1pm
Now, my day job is assessment of risk management and legal compliance of public services (and, by connection, I get involved with assessing and auditing quality management, although that's not my real area). I also deliver training in this area, and gawd knows safety management and legal compliance is one of the most boring subject in the world to be trained in - and quality management is another. So I have similar feelings to Mike but from a different angle, I think what's important when we deliver information and training is that we must clearly identify what the listeners' problem is that needs solving, and how what we're proposing solves it. Then we can get into the nerdy bits (and I write that as a self confessed SMS nerd). I did revisit the linked page to check before writing this - it's not at all clear that it's going to be "problem" > "proposed approach" > "evidence / argument that this will be a (better) solution", which is what makes an appealing presentation. It comes across as "proposed approach" only, which is why it's written in the language it is. If I were to advertise one of my courses by describing the content I would equally expect the target audience to describe it as "gobbledygook", as with all technical jargon it only makes sense when you understand the issue.
Ok, so what about those who are in the field who use the jargon themselves? They will still only want to attend (assuming that they have some level of experience) if they think it's going to help them solve a problem, so the same rule applies.
As the old advertising guidance advises - "sell the sizzle, not the sausage"!
It's actually exactly the same issue as we have as engineers when we talk about technology - it's very easy to get carried away with the technology and forgetting that what the potential listener is interested in is what the problem is that that technology is trying to solve - and, indeed, giving some level of confidence that it will actually solve it.
Mike, I do disagree with you about jargon though, we all use jargon, managers say that engineers use jargon to confuse things, engineers say that managers use jargon to make them sound cleverer and more dynamic than they are. My experience is that both viewpoints are wrong, all professionals use jargon in their professions, typically to distinguish between areas which seem to the outsider to be the same. And that's fine, provided they remember who their target audience is when they're writing. I'd probably use all the examples you'd list if I was talking to a project manager or a resource manager, because it would mean we'd all know precisely what we're talking about, but I probably wouldn't use them to another engineer - any more than I'd talk about "inductive coupling" or "reactive impedance" to a project or resource manager. (Good discussion at the Repair Cafe I volunteer at yesterday about the technical distinction between "buggered" and "knackered"! Translation for project managers: "we have identified a non-conformance which we are working to resolve", and "the system has failed and will require the development of a forward looking road map for a replacement system" 
)
I exclude of course the more irritating of the "sales and marketing executive" type of course who absolutely do use jargon to cover the fact that they have no idea what it is they're selling or why! 
And, back to the point, we do need to be careful not to confuse their output (which I'm sure this link isn't) with the genuine use of correct technical terms in the right context, but which miss the fact that the intended audience may not be familiar with those terms. But does also put an onus on us when writing to use jargon appropriately.
