The Business Continuity Planning Jargon Problem

I have just been in Linked-In again checking out the Business Continuity Group pages and came across another discussion where a practitioner is frustrated with the inconsistent use of terminology to describe what we do.  This is becoming a rather common and far too time consuming conversation, in my humble opinion.  I am getting almost as frustrated with the complaints about the use of the industry jargon as I am with the misuse of the jargon itself.

Whereas, I think it is commendable to try to get a common language in use across the industry, I also think the complaints about the current misuse of the language is starting to sound like a bunch of excuses for not delivering what your client (be it an internal or external client) wants versus what you think they should want.

Fine, work behind the scenes in trying to come up with a common lexicon, but in the meantime accept that we now work in an environment of mixed and confused jargon and take the time to understand your audience’s use of the terms and what, ultimately they are looking to achieve in their programs and don’t worry so much about the labels they use.

If you have the time, allow me to share a little, real-world story with you.

I was once contacted by a prospective client asking me to send him a proposal for conducting a Business Impact Analysis for his organization.  He described the size of the business environment, number of departments, number of critical applications, facilities and high-level business processes that they perform and asked me to price out conducting a BIA.  I asked if we could first meet in person to discuss the project prior to me issuing the proposal and he agreed to do so.

During the meeting, I told him that the term BIA can mean a lot of different things to different people and I just wanted to understand exactly what he was looking for prior to submitting my proposal.  He seemed a little surprised to hear me say this because, he confessed, I was the sixth firm he contacted and the previous 5 had all submitted proposals based on the phone conversation he had, similar to the one he had with me.  He did admit that the 5 proposals had a pretty wide-range in delivery time and costs and that was why he sought one more to see if a consensus might develop.

My first questions to him were: “Why do you want to conduct a BIA?  What is it you hope to achieve?  What do you want this BIA to do for you?”

He then proceeded to tell me that he was responsible for the company’s IT Disaster Recovery Program.  In this program he had some 20 – 25 Tier 1, Most Critical Applications identified and he was hoping to prioritize these applications based on the business community’s needs.  He said that he was concerned that he may not be able to recover all 25 applications within the Tier 1 parameters and, if problems occurred in the recovery process, which applications should he address first?

He was calling this a BIA because he wanted the business managers interviewed to provide the data necessary to prioritize his application recovery. 

To make a long story short (or at least shorter than a long story) I told him that I could absolutely help him achieve that end.  This is not what I would call a BIA and not how I would have structured a proposal based on the request to conduct a BIA, although it did include some BIA-like processes, but sure, we could help him prioritize his application recovery program based on input from the user community – no problem.

After we concluded our discussion he shook my hand with a funny smile on his face.  I asked him what was funny and he said; “Everything you just told me makes a lot of sense.  I can fully understand your need for clarification.  I just wonder now how those other 5 companies could submit a proposal without asking me what I hoped to achieve by conducting a BIA.  What the hell, I wonder, did they bid on?”

The point of all this typing is to suggest that we practitioners should stop complaining about the jargon used by our clients (and other practitioners) and simply take the time to understand what they want and not get so caught up in how they say it.

Thank you for your input.