Jargon is a fact of life in pretty much any field. It’s unavoidable, because people need a shorthand way of communicating concepts that are standard in their field. Now, this is usually not a problem, even if it can be frustrating to outsiders, but there is a case where it does become a problem – when the term means something specific to two people who are working together, but it means a different thing.
An acquaintance of mine who had served in the US military once told me the following joke. What’s the difference between the United States Marine Corps and the United States Navy? When the Marines secure a building they go room by room with flashbang grenades. When the Navy secures a building, they take out a 20-year lease on the property.
More seriously, I remember reading a story of when troops were used to supplement police during the Los Angeles riots. The police yelled ‘cover me’, which to them meant ‘point your guns at the bad guys in case they open fire’. The troops, meanwhile did what they understood ‘cover me’ to mean – ‘open fire with everything you have so the bad guys don’t dare lift their heads’. Fortunately, no-one was killed due to this little conflict in terminology.
The reason why I bring all this up is because of a number of times that I’ve personally seen where these same conflicts in terminology have led to problems. Thankfully, these weren’t cases involving covering fire or flashbang grenades, but they still led to conflicts.
The first case that springs to mind is during a program meeting at a bank in the Gulf, where one of the attendees, the enterprise data architect, offered the opinion that one of the advantages of Master Data Management was that it ‘improved quality’. The enterprise application architect later commented to me that it was incredibly stupid to think that, MDM doesn’t magically improve data quality automatically. Talking to the enterprise data architect, all she meant was that an MDM project will force an organization to undertake a data quality exercise separately, because otherwise what’s the point?
The second instance that comes to mind was on a consulting job where on the first day, I was asked by my supervisor in an email to list the deliverables that I’d be providing. I was a little surprised that this had not been agreed in advance, but used my consulting background to list out the work products that I proposed to create. I got a ballistic response back as the supervisor means deliverables to mean ‘business benefits’ – somewhat at variance with my experience, but there you go.
There are two points here. The first point is that while jargon is useful, it’s important to remember how it can be misinterpreted. In particular, it’s worthwhile being attentive for cases when a term is ambiguous – for example, it’s never a bad idea to state “and by improving quality you mean it will automatically improve data quality?” The second point is that more often than is ideal, when a dispute exists it can be because of a misunderstanding than a genuine disagreement.