Risk often has a negative connotation, perhaps because very often risk is allowed to take its course without mitigating actions, and without proper or sufficient risk management. Risk is ever-present in business, and in fact, that is one of the essential ingredients in running any business - the matching and managing of risk against reward.
There is often a positive side to risk though, and this is the main topic that is going to be explored here. Let's set the scene for first accepting that there is indeed a positive side to risk, before we explore it in the context of business continuity.
Say you decide to invest an amount of money in shares on the stock market. You accept that this is a bit of a gamble (part of the risk component), because you know the value of your money could go down or go up over a given period of time. You obviously hope or calculate that it will go up, and if it does and you sell those shares timeously, you have made an acceptable profit.
Thus the risk aspect had a positive outcome simply because you made a profit in a given time period (and possibly because you might like to think that it was a calculated risk). Equally if you had lost money on the shares you might accept that outcome because of the risk element that was known up front, or you might say that the risk management (once the shares were purchased) was outside your control and you knew it was a gamble. Thus the risk outcome could have been negative or positive. Now let's look at where risk could have a positive outcome in terms of BCM, and some of the areas that could be looked at to ascertain if there is a positive risk aspect.
Projects can slip on delivery date for any number of reasons, and if that is happening to you in a project the last thing you need is unexpected scope creep in terms of additional work, right? Wrong! What might seem as an additional risk to add to partial project failure (in this case the agreed delivery date cannot be met) can be turned into a positive risk outcome if it is handled correctly. Let's use an example of a client needing 23 business continuity plans, and the delivery date is set for eight weeks time. The project is properly scoped and resourced from your side (and the BIA/RA and BCM strategy documents are complete and signed off), and starts on time according the project plan, but let's say circumstances from the client side (eg, certain staff unable to meet on agreed dates and times, or unable to provide significant relevant information on time, etc) prevent the timeous completion. At five weeks into the BCP development and implementation, project failure stares you in the face.
Although it might not be your fault, the buck could be seen to stop with you as the project manager or business continuity practitioner, and business continuity management risks a dirty smear.
Fortuitously (and you must recognise it as such) the project sponsor now asks you to extend the scope and provide a BCP for each of four branch offices. Seize this opportune moment. This is your legitimate opportunity to create a new project plan with a new deliverable date (all with the project sponsor's blessing), and at the same time include the "lost" days due to the client inability to play ball with the original project plan. Voila! The project is back on (a new) track and all is rosy again. You now have a second chance for a successful project outcome, including the newly agreed delivery time for the BCPs.
Let's look at another hypothetical example within BCM where risk may initially seem to only have a negative connotation, but actually also has a positive aspect. Let's look at the solution part of an IT technical recovery team plan, where a business-critical system (hardware platform, operating system, application and database) is required to be data mirrored at a remote recovery site, as per the agreed BCM strategy for this particular system to provide a Recovery Time Objective (RTO) of under 30 minutes and a Recovery Point Objective (RPO) of 45 minutes or less. The two systems are identical standard configuration mid-range Unix commercial boxes with a proven secure data mirroring software package, with proven fail-over capability (within five minutes as per a simple manual procedure).
Both systems are situated in secure and properly managed data centres, sufficiently geographically distanced. The hardware and software is all tried and tested and stable. All the supporting paperwork is in place: licences, change control, SLA, maintenance and technical support contract, insurance, etc. So far so good. Now risk starts to play a part that can pull us in two directions.
Let's say that after all the budget expenditure for the duplicate system, and the operational costs for housing this in an alternate data centre, whoops, the IT manager suddenly realises that there is insufficient budget remaining (or perhaps there is a sudden budget freeze) to provide a permanent data line of sufficient capacity to the alternate data centre (yes, I know, this might be bad planning on the IT manager's side, but it happens. Don't worry - hypothetically you were not involved in this stage at all!). Capacity planning had shown that a minimum 512Kbps Diginet line is required to provide the capacity to data copy so that all data could be transmitted asynchronously within say five minutes (at the busiest time of the day) of writing data to the disc on the home system. Let us say that there has just been a budget freeze for the next 12 months, and the limited funds available will only provide for a 64Kbps line speed.
All avenues are explored, and no way can be found to pay for the installation and monthly costs of the 512Kbps line, so within the budget constraints a permanent 64Kbps line is installed to the alternate "recovery" site. Note: if you want to argue that the cost difference between the two line speeds is negligible, lets just say that a 512Kbps or higher line speed is unavailable on that route/area for a year due to telecom service provider bandwidth limitations. When the recovery system is connected and run "live", it is found that due to the slower wide area network line speed, the data update to the alternate site is up to one hour behind during the peak business activity times of the day (say between 11am and 3pm), but this data transfer backlog is quickly eliminated and caught up with once the normal working day finishes. The data transfer and updates are mostly completed within 15 - 25 minutes during the remainder of the working day. What are the positive and negative risk aspects to this configuration?
At first it might seem that there are only negative risks to consider, and this is where you might need to apply a little detective work to ascertain if there is any positive side to the reduced line speed risk. Also, if there are "positive risks", do any of these outweigh the negative risk aspect to the extent that this now becomes the preferred way to operate? You could probably dig a bit deeper and find more points, but the main issues for the example given are listed here:
To conclude, risk is more likely to be viewed as a foe if it is not managed or mitigated, or indeed if there are critical components of a project left to chance or you leave them totally out of your control. Sometimes you have to dig a little deeper to find the positive aspect of a particular risk area, because at first it may not always be obvious. Finally, don't be afraid of risk, it could be one of your gateways to eventual project success, and the more you manage it and control it, the more often it will turn out to be your friend.
Share
Editorial contacts