DRJ Fall 2019

Conference & Exhibit

Attend The #1 BC/DR Event!

Summer Journal

Volume 32, Issue 2

Full Contents Now Available!

Someone on one of the lists I watch noted that business continuity practitioners typically work “after the fact.” That is, they become involved in a project after it’s completed. Unfortunately, that’s true. “Better late than never” may apply, but too often, the “after-the-fact” involvement proves costly. For the purposes of the following, and because it always is standard operating procedure for this practitioner, BIA includes risk identification and avoidance/mitigation options.

Some Cases in Point

A Fortune 100 firm once moved its operations from one location to another. The distance between the two sites was a matter of a few miles. It had a new structure built to house the operation. To show off the true profit center – in this case, the data center – it put the data center on the ground level behind huge plate glass windows in the building’s lobby. Very classy. The only problem was, the building was in a flood plain and the organization’s profit center –being on the ground floor – was at risk.

Fortunately, there were alternate sites in two widely distant locations, but the flood threat and business disruption risk remained.

A friend of mine and a co-worker at the consulting company was project manager for the physical move from Point A to Point B. She was aware of the need for a project business impact analysis (BIA) and, within the scope of her mandate, she did a risk analysis.

What happens if ...

  • the new data center is not ready on schedule?
  • a piece of equipment fails to arrive on time or fails out of the box?
  • the T-3 (then) telco lines are not installed?

... and on and on.

She had these worries because this scrivener had been involved with an earlier move for the same data center, and we shared our thoughts.

The data center relocation project provided a good example of why every project should involve a risk management/business continuity practitioner in the initial stages.

Not Always Bricks and Mortar

Let’s consider a software project for a moment.

What possibly could go wrong with a software project?

Start with the most likely – missed deadline.

How about programmers who abandon the job in mid-project. It happens. People get sick, they resign, they get dismissed.

As with all things “business continuity,” there should be avoidance or mitigation options.

In the case of the programmer’s disappearance, the avoidance is to insist that the programmer “comment” his or her code. Lots of programmers object to using comments because they consider cryptic code to be job security. Someone – the programmer’s employer or not the project manager – needs to insist on commenting, not because the programmer’s reliability is suspect but because it’s “just good business practice.”

Performing a pre-commencement BIA may turn up reasons to either kill a project before it starts or modify its goal.

Architectural Risks

In the world of concrete and steel, consider a project to build a new facility.

In the United States, there are two threats that know no geographic boundaries: tornados and earthquakes.

Given that, new structures built in areas of high probability of tornados or near a fault – and there are faults all across the country – should include at least a consideration of tornado or earthquake resistant construction. Where can people go to safely shelter-in-place in the event of an environmental event? A safe room, a place designed to survive the event, is the answer.

Beyond environmental threats, the BIA should consider geographic threats such as nearby rail lines that may be necessary to move raw materials in and finished products out and possibly carry hazardous materials, seaports, and major roadways. Proximity to airports is also always a risk, especially if the new structure aligns with take-off and landing patterns.

Even acoustics from planes, trains, and trucks might be a consideration of some organizations. But the structure is sound proof, correct? Of course, but what about sound waves? If loud enough, long enough, and close enough, the sound waves (vibrations) can take a toll on staff and the building itself.

Then there are neighbors. What do the neighbors do? I once worked for a company that made automotive airbags. That company “played with” Class A explosives, but this was not advertised on the campus’ front entrance. Another time I worked for a company next to an insurance company. You can’t get much safer than an insurance company, except that his particular company was staffed largely by ex-military officers who were disliked in some quarters. An attack against the insurance company might spill over to us.

The next “got’cha” might be considered an “architectural risk” since it involved a builder. The federal government initiated a construction project. A contractor was selected and a contract signed; the contract specified a completion date and penalties if the date was missed. The contractor, as most contractors do, had a line of credit with a lender; this assured the contractor with a cash flow for the life of the project. Unfortunately, the economy took a nose dive and the lender failed; the contractor lacked funds to pay for materials and for the workers. Work stopped. The contractor failed to have the building ready for occupancy on the agreed-upon date, and the federal government started applying penalties. The contractor should have had an alternative lender as a standard procedure; the contractor also should have asked the lender for its business continuity plan.

But, in my opinion, the real focus for this failure goes back to the Federal project manager who flunked the “due diligence” test by failing to assure the contractor had a business continuity plan that included financing alternatives.

One of my West Coast peers questioned the likelihood that a business continuity plan would include financial risk. Perhaps a business continuity plan would overlook the threat, but a true enterprise risk management plan certainly would include it.

Delayed Risks

Every project has its risks, but sometimes the risks become apparent only after the project is under way.

I was engaged to help a retail giant develop a plan to temporarily relocate its data center to another state and then recover the center back to its original location. A fairly straight-forward exercise.

Turns out, the exercise was replete with risks. The first did not clearly define the practitioner’s role. However, the risk that brought the project to a halt was absence of critical personnel – the managers who controlled the operation, failed to participate, and failed to delegate authority.

Meeting after meeting was called to define the project’s scope. During meeting after meeting, when the roll was taken, the critical personnel were absent. The project apparently had, for these managers, a low priority.

As with all BIAs, all potential interruptions to “business as usual” should be considered. Some may be unlikely to occur – off-the-wall thoughts – but they still deserve an airing. As with everything to do with “risk management,” as many people as possible should be involved; input from all corners should be welcomed.

It may only be a project, but if it is worth doing and costs more than the change in your pocket, it deserves a BIA.

John Glenn, MBCI, (JohnGlennMBCI.com) is an enterprise risk management/business continuity practitioner with more than 13 years experience. Glenn invites comments on this article and others at his Web site to This email address is being protected from spambots. You need JavaScript enabled to view it..