Have you ever been in the situation where you ask your significant other what they want for dinner but receive the response that sounds non-committal and open ended? They don’t care what it is; they’ll eat whatever you make only to say they weren’t in the mood for what it was you made for them? It happens allot I’m sure, just as it happens in the BCM / DR world.
Some IT groups (those responsible for IT Technology Recovery) just start throwing around ideas and thoughts of what they believe they need or want and start making determinations and decisions without fully investigating what it is they really need. They start speaking for the clients and customers – their business – and moving forward based on what they believe if required only to get further down the path and find out that what they set up or have started in progress, doesn’t and won’t meet the need of their business. They didn’t investigate the requirements; the very things that will determine what path they need to take in setting up a Technology Recovery Plan (TRP).
In some instances there are bits and pieces they don’t need the requirements for because they know that some aspects must be up and running before other activities can begin. For example, they won’t need a requirement to tell them that the network needs to be configured/available or that the mainframe needs to be restored and recovered before any business/user activities can begin. But when user applications/system are required, IT can’t assume they know best. After their initial restoration and recovery efforts, they can no longer assume that they know ‘what is required’. When it comes to user applications/systems, IT can’t assume that just because more people use application/system ‘X’ doesn’t mean it’s the first thing to become available. If application/system ‘X’ is dependent upon application/system ‘Y’ to be operational first when they haven’t made this investigation – confirmed business/client requirements – well, the restoration and recovery isn’t going to go as planned now is it?
In project and program management, the System Development Life Cycle (SDLC) can’t really get going until the requirements are defined by the client/customer/business. And even then, there is some back-and-forth discussions to clarify requirements that may not be fully clear, understood or simply don’t read as a requirement (Note: Often a requirement reads as a solution.). Requirements must be clear and expectations understood between all parties or as you get further down the line the costs start going up because of rework, change requests and failures in communication.
So do you document your requirements for BCM and DR? Could the BCM practitioner in your organization be in a position to point to a documented agreement that clearly states ‘these are the expectations and requirements of our client/business’ and that the desired TRP strategy aligns with the need? Make sure you know your requirements up front and don’t guess or assume because you know what’ll happen further down the road when something disastrous occurs…
© 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.”