As business continuity planners we spend a lot of time looking for risks to our client’s critical operations.
We create project plans and statements of work, carefully guesstimating the time needed for each phase of the project, which is fine if everything goes according to plan.
As Murphy knows, things rarely do “go according to plan.”
Project Management 101
A few years ago I worked a project for the city in the south. When we (the city’s folks and I ) started our conversations, the plan was to be “semi-enterprise” – “semi” because it excluded a couple of city functions, notably the local international airport and emergency services (fire, police).
By the time I arrived on site, the semi-enterprise plan had dwindled to an IT department plan which would “showcase” business continuity to the rest of the city’s departments.
My job was to mentor the city folks who would put the plan together.
On my first day on the job I was introduced to Bob Campbell, brought on as the plan’s project manager.
Since this wasn’t a major effort, I questioned the value of engaging a project manager, but fortunately – and in a rare exercise of restraint – I said nothing.
Turns out, I learned a lot about project management from Mr. Campbell.
First, I learned that before I start looking for risks to the organization’s critical processes, I’d better look for risks to the project.
Among those risks managers who, although critical to the project, fail to participate in meetings where their decisions determine the direction of the project.
Sometime later this particular risk presented itself on another project – to the best of my knowledge, the project still is in the “development” stage two, three years after I said my good-byes to the working folks who did show up for the meetings.
Some of the risks to a project are pretty much “business continuity standards,” risks such as personal absences (although how many planners consider staff taking 12- to 18-month leaves to visit Iraq or Afghanistan).
The more tightly scheduled, the more tight the deadline, the greater the probability the project will slip. If that’s not Murphy’s Law, it’s certainly one of Murphy’s cousins.
Changing priorities are a constant risk.
Today, business continuity is priority No. 1.
But tonight the sales force brings in a 200-page request for proposal (RFP) worth maybe 50 percent of the organization’s annual budget.
If some of the people needed to respond to the RFP were on the business continuity project, the business continuity project manager better start looking for replacements or start advising the client that the project can be expected to slip by “n” number of gross time units (weeks, months, years).
Vendors’ Impact
When we put together a business continuity plan we must concern ourselves with vendors.
Do they have plans in place to assure the product or services we need will be available when we need it? Are the vendors financially sound? Does the vendor have the capacity – both in personnel and production equipment – to meet our service level agreements (SLAs)?
Maybe we even consider the transportation link between the vendor and our organization.
But, and I’ve see this happen more than once, if we are relocating – makes no difference if it is a data center making a scheduled move or displaced personnel moving into an alternate site – will the destination site be ready for us?
The most common scenario is data center relocation.
Will the power be in place?
How about telecom?
Inter and intranet access?
Infrastructure – cables, routers, hubs?
That leading edge computing device, will it still be available when it comes time to stick it into a slot, or will it be superseded by something that won’t support what you need it to support?
(Think about “backward compatibility” next time someone suggests a hardware or software upgrade. In fact, think of *all* the risks inherent in any change to the “status quo.”)
All of the above fall into the general category of “dependencies.” If “A” doesn’t happen, the rest of the alphabet won’t happen.
Sometimes there is a work-around, but most often in this scenario, work comes to a halt. If the paymaster is lucky, personnel efforts can be redirected to other things while the missing link is located and connected into the overall chain of events.
Not Just Data Centers
I once put together a plan for a shipping company.
The company was located in an area that was known for flooding (high probability), and it was located next to an organization populated by ex-military types – targets of anti-war folks. Peripheral damage due to an action against the neighbor was a risk, although of relatively low probability. Somewhere in the middle of the probability scale was the fact the shipping company was headquartered in a Middle East country known as a target for its unfriendly neighbors.
The plan I presented to management included relocation to an alternate site – a hotel with large, unobstructed conference rooms, or to a convention center with wide open spaces.
Why?
"Appeared in DRJ's Winter 2009 Issue"
Easier to cable.
The idea was to have an alternate site ready for the business units and their resources to move into in short order.
This all depended, of course, on my being first in line with the vendor and the vendor having the resources to do the job. (Yes, Virginia, whether or not the vendor had sufficient resources was my problem, not just the vendor’s. It was, after all, “my” plan.)
As I write this I am involved in a proposal to create a disaster recovery plan based on a very ambiguous RFP. (Do I smell a risk here? You bet – ambiguity is near the top of my “enemies list.”)
Never mind that the project is strictly disaster recovery in a world where business continuity is the goal.
Never mind that so far neither the issuer of the RFP nor the responders really know what is wanted.
The thing that bothers me most is the lack of understanding of the project risks by the folks preparing the RFP response. Do they understand – do they listen when I talk – that what is understood is that the prospective client wants the project implemented on a tight schedule (risk) without – at least at this point – a firm statement of work (another risk) and apparently without any more thought to the project than “We want to have this up and running ASAP.”
Does the alternate (disaster recovery) site house only the data center?
Does the alternate site house the data center and the support center?
Does the alternate site replicate the original site, including the profit centers’ staffs?
There are more pre-project risks to resolve than there are crumbs in a crumb cake.
Sometimes I feel akin to Isaiah crying in the wilderness; to paraphrase him, “Prepare ye to encounter obvious and hidden risks.” (An interesting commentary on Isaiah’s admonishment is found at http://www.gracecathedral.org/enrichment/brush_excerpts/brush_20060228.shtml.)
Not all risks are risks to a profit center’s critical processes.
Some, perhaps equally important, are to the business continuity exercise itself.
As I learned working with Bob Campbell and later while being mentored by Rhonda Payton, another really good project manager, we are well advised to look for risks to the project before we begin to develop the plan.
I also learned that having an experienced project manager on board can be a very good thing.
Final thought: Checking back with the client manager a year or so later I was told that in the end, even the IT business continuity plan project faded away; it never was completed. Now that was a risk that should have been considered early on, but who wants to think of divorce when you are courting?
John Glenn, MBCI, SRP, has been helping organizations of all types avoid or mitigate risks to their operations since 1994. Comments about this article or others at http://JohnGlennMBCI.com may be sent to planner@johnglennmbci.com.
