Well, it’s that time again when I write about personal experience rather than academic doctrine and how the two end up conflicting and sometimes not providing what you want in the end.
Recently, during a few meeting it was discussed that a new process was required for Senior Management reporting purposes and the manager requesting the process provided some guidelines/requirements on what was needed. Sounds easy enough.
The guidelines were set and when some of the work was started, prototypes of what the reporting would look like were provided to the manager to ensure what was being developed met the set guidelines. After 2 different prototypes it was confirmed that yes, things were meeting requirements (and were actually exceeding them). Seems good so far, eh?
Well, then day came that the product was finally delivered to the manager – after numerous reviews, walkthroughs and clarification requests – only to find it didn’t meet what they wanted in the end.
Well, how often has this happened to you as a BCM practitioner? I bet more than you might think.
It’s like the process of gathering requirements for IT Disaster Recovery Plans (IT DRP) and Department Business Continuity Plans (BCP), which is done through the Business Impact Analysis (BIA). You can’t – and I hope you don’t – just take everything at face value. As a professional, you need to question these results and get them refined so that you understand them and they are validated with the original BIA submitter and their manager/team. Would you believe me if I said I wanted something back up and running in 2hrs and just assume it was true? I hope no, especially if I say I’m dependent upon something else that isn’t available until the 24hr mark? Suddenly the 24hr process needs to be moved to under 2hrs to meet my expectations (of 2hrs) but that 24hr process may be dependent upon something else and those investigations and conversations must occur.
Just like that new report, you can’t take things at face value and assume that the ‘smiles and nods’ means acceptance. It doesn’t always mean that. Sometimes people just don’t understand how things work at the enterprise level and only focus on their department level and if that’s the case, you need to have conversations on two aspects: some BCM awareness and an understanding of dependencies and interdependencies.
IT could be that my 2hr Recovery Time Objective (RTO) isn’t for the entire process but for some small aspect of it that isn’t dependent upon the previously mentioned 24hr process. But if you don’t investigate this then as a BCM practitioner you’d never know.
So if you don’t have these conversations, then me – as the manager expecting a 2hr RTO, is suddenly shocked when operations are disrupted and I’m not operational for over 24hrs. None of my expectations are being met. Or, the process is up and running (all of it) in 2hrs and the 24hr process was moved to under 2 hrs – and remember, they don’t know this, when that dependency process is available quickly, they don’t have the resources lined up to do anything that I’m actually dependent on because they still thought they weren’t coming up until 24hrs and thus, assigned resources accordingly.
In the end, challenge everything. What someone states isn’t always what they want – or understood. Make sure that dependencies and expectations are clear for everyone and if adjustments are made, again, everyone is involved so that any downstream plans and processes – and expectations, are managed accordingly. There’s no further surprises at time when you least want them…
© 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.”