I’ve sat through many meetings between IT and Business Unit (BU) representatives where people assume they know what the other wants or is trying to say; constantly interrupting and providing their own commentary before the other finishes theirs. Has this ever happened to you and were you the interrupter or the interrupted? Maybe both depending on the meeting. It got me thinking that there is often a big gap between what the Business Unit needs (or wants) with that of current technology capability…or understanding.
Too often the two don’t speak the same language and instead of listening and then requesting clarification to get a clearer picture of what is needed, the two interrupt each other and make lots of assumptions when the meeting ends. This doesn’t help anyone.
I was listening to a recent webinar about Recovery Time Objectives (RTO) and how IT develops them…and then later in the day I was reading a document at a client site, which outlined the RTO that was set by a specific Business Unit. I did a bit of digging through corporate sites and through a few questions and found that there was actually two (2) sets of RTO’s. The first was the one desired by the BU and then one based on actuality from IT. I asked how come there was such a difference and no one could answer it. It turns out the two almost never touched base on the subject so there was no reconciliation or confirmation of what the actual RTO would be.
I’m going to use an example – one that I experienced some years ago – to make my point. At the time the BU assumed that after a major event their critical user applications, systems and data would all be up and running and available in 24hrs. However, IT knew that since they subscribed to an external vendor, that vendor had up to 24hrs to make the site client ready once the company had declared they needed the site (which might take the company a few hours to determine if they needed it or not).
Then, IT would take up to another 24hrs to get the most critical systems operational (i.e. mainframe, network infrastructure) before they would then begin work in critical applications (i.e. email, financial application etc.). As no one had done any reconciliation between what the BU wanted and the current IT capability, it turned out that the original 24hr RTO was actually 72hrs…or more. Not good for meeting anyone’s expectations don’t you think?
In this example, the BU assumed that when a disaster occurred or some business interruption occurred the ‘DR site’ is automatically ready for immediate use and 24hrs would be met. Imagine the horror when they found out that wasn’t the case. Is this your case?
When you get an RTO from the BU for a new application request, system change or as part of Business Impact Analysis (BIA) results, there has to be a discussion between the two groups to ensure clear comprehension of what that number means and whether it can be met or not or what’s needed to happen to make that number achievable. There has to be some reconciliation between the two; one group can’t assume it’s meaning and the other can’t hide the fact that there is a discrepancy.
How do you reconcile between the two – IT capability and BU need ? Do you keep it secret so as not to upset anyone or do you clearly explain the situation, placating any concerns with convoluted responses? Or do you just ignore the queries until you can reply that you’re in a better position to meet RTO needs. Ensure that the two are on the same page and if not, get them on the same page. If one believes something and the other is doing the opposite of what’s understood – or completely off base, then this is going to cause allot more difficulties than just the disaster itself.
© StoneRoad 2016
A.Alex Fullick has over 19 years’ experience working in Business Continuity and is the author of numerous books, including “Watch Your Step”, “BIA: Building the Foundation for a Strong Business Continuity Program” and “Testing Disaster Recovery and Business Continuity Plans.”