Sometimes expanding the abbreviation makes things clearer to the uninitiated: for example, the terms “recovery time objective” (RTO) for an IT system and “business impact analysis” for BC planning give some hint of what lies behind them.
But what about “recovery point objective” (RPO), also one of the commonest terms used in defining a suitable disaster recovery/business continuity plan? Would we be better off if we banned the use of such jargon?
Banning probably wouldn’t work. For one thing, it would be the curtailing of free speech, and for another, like weeds, jargon would spring up again anyway. We need a better way of managing business continuity jargon, recognizing that it also has its uses.
Among other things, it is a shortcut for referring to stages, deliverables, or objectives. Two people can have a faster, more productive conversation when using jargon, instead of constantly spelling items out in full. There are conditions, however.
Both people must have the same understanding of what the jargon means, and the meaning must link back to something of value to enterprise and business objectives or performance. Too many times, jargon ends up out of synchronisation with what a business really needs.
On the other hand, jargon has no place in conversations involving stakeholders who do not understand the jargon.
Jabbering on about RPOs to your CEO may be a fast way to getting your budget cut – after all, why fund something whose value to the business is not properly explained? If the essential concepts are clearly and simply defined without jargon in the first place, then introducing abbreviations afterwards may be legitimate.
But at the first sign of glazed eyes, switch back to simple, explicit terms that everyone can understand, for which an added benefit is that it also forces you to make sure you understand what you’re talking about anyway.