Manifesto for Agile Business Continuity Planning

Brad GrissomBlockedUnblockFollowFollowing

Feb 23, 2015

The Manifesto for Agile Software Development contributed to a movement that changed how software gets created and how the interactions of that process unfold over the development lifecycle. Agile development has arguably improved speed of delivery, collaboration, and ultimately the value of software. The manifesto is simple, totaling only 68 words:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The meat of this declaration is found in the four value statements at its core. What would these value statements be if applied to business continuity planning?

I suggest the following tweaks to the values:

Individuals and interactions over processes and tools
Recoverability over comprehensive documentation
Customer collaboration over assessment and analysis
Flexibility over following a plan

In staying true to the original manifesto, there is absolutely value in the items on the right, yet we must value those on the left more.

Why? Because we need to plan faster, with greater participation and understanding from our customers, to achieve results that actually meet the needs of the organization.

Current planning methodologies are stale, cumbersome, and filled with pseudoscience and half-baked ideals. Risk assessments typically ignore data-rich, statistically based proven methods. Business impact analyses are more often than not subjective judgment calls that can be argued one way or another based on the information of the day. Planning software is stuck in the early ‘00's with the primary goal to create a PDF of information that is only accurate for a few short minutes after printing. Exercising is too often just sitting around a table and talking. Updates to the plans are done per a schedule instead of based on need.

Here is how I would apply these new values to improve business continuity planning:

Individuals and interactions over processes and tools

Too much time is often exerted to establish software applications to help develop and manage plans. In the end the software on the market today doesn’t end up being that helpful. In fact, I would argue that most of it creates more work than it solves. In conjunction, we often labor through extensive processes even when we know where we will end up from the onset. We need to spend more time finding the right people within the organization to champion and foster the right risk management and contingency planning mindset. When we find them, we need to work closely together to understand what is needed for recovery, how they can achieve recovery, and to ensure that it is known throughout their workgroup. Building a solid relationship with the individuals responsible for achieving business continuity will do more to further the organization’s recoverability than following a rigid process or deploying a relational database that will allow you to replace people’s names more efficiently.

To apply this approach, spend more time talking with your customers than defining your process or administering your planning system.

Recoverability over comprehensive documentation

Recoverability is the heart of what the planner is setting out to achieve. It means nothing if your documentation is up to date but key elements needed for recovery will not be available within the desired timeframe. Too often, I’ve seen planners measure their program on how many plans have been written and whether or not those plans have been updated within the last year. This is a meaningless stat that only shows that there is work being done. It fails to indicate any measure of whether or not business continuity could be achieved. I’ve seen hundreds of plans housed in the plan management system that were all completely useless, yet upper management felt they were in good shape. This mismatch between perception and reality can be resolved if we shift the conversation and focus away from written plans and documentation toward practical applications of recovery. We should demonstrate the ability to meet the recovery needs of the organization within the desired timeframes. The question will then move from “have you written your plan and tested it” to “can you recover?”

To apply this approach, measure and report on the comprehensive ability to meet recovery objectives instead of whether or not planning milestones are achieved.

Customer collaboration over assessment and analysis

As planners, I feel we should drop the pretense that we conduct meaningful analysis. The truth is, our methods for assessing risk and impact are mostly unscientific, biased, and subjective. We make up scales with associated numbers and labels, which we then assign as best as we can to whatever it is we are attempting to measure, generally a risk or an impact. What is done one way one day, can easily be done another the next. Instead, we should be working as closely as we can with our customers to understand what they need from their perspective. They know the answers to our questions — the ratings we assign to them do not further the conversation in a meaningful way.

To apply this approach, work directly with subject matter experts and decision makers to identify recovery objectives and solutions instead of writing risk assessment and business impact analysis reports.

Flexibility over following a plan

Just as we too often rely upon assessment and analysis, we often setup unrealistic ideals of what will transpire during a business continuity event. We script plans and workflows to somehow be both applicable to certain situations yet also able to handle any hazard that comes our way. Yet, what we see in practice is that disruptions and continuity endangering events don’t follow standard patterns. They evolve and morph or come at us unexpectedly. Our preconceived notions of how to deal with disruptions are rooted in some framework of how we think a disruption will occur. This logic is flawed. We need flexibility to deal with ever changing and fluid situations. What worked last time may not apply to the next event. Our plans need to embrace the ambiguity that is a part of any disruptive event and plan at a corresponding level. This means that planning for minute details will generally not yield a high return on your investment.

To apply this approach, keep your plans at a high level indicating roles and responsibilities over detailing specific tasks for each person on a team to carry out.