WTG has developed a best practice approach that defines mission-critical applications, second and third level interactions, upstream and downstream dependencies, recovery requisites, data integrity requirements, recovery sequences and solution architectures better than any form of traditional Business Impact Analysis (BIA).

We believe that only by understanding the true needs of the business and how applications and processes interact at the detail level can proportionate and cost-effective recovery strategies be designed. In our opinion, our NextGen® Iterative Business Process Decomposition (IBPD) methodology is the only effective way to define the Recovery Time Objectives (RTO – the time by which systems must be restored after a disaster interruption), Recovery Point Objectives (RPO – the point to which application data is restored, or the amount of lost data) and Business Continuity Objectives (BCO – the quantity of staffing and support requisites needed over time to support critical operations). Our IBPD also provides critical decision-making information like N+ and N- Alternatives, Break-Points and Riser Warnings and other NextGen “Level 2” data that the typical BIA does not even begin to consider. This “Level 2” information is critical when it comes to making the cost and capacity decisions necessary to chose between the alternative incremental solutions required to achieve today’s extremely shortened RTOs and RPOs and is the best way to get management’s buy-in to the recovery planning process.

Our NextGen approach is simple and in fact follows the logical approach used for most management projects, but which for some reason is completely reversed when it comes to a BIA. In fact, we attribute much of the usual difficulty in gaining management’s commitment to DR/BC planning as a direct result of this unnatural reversal of “normal” procedure. An IBPD starts with a high level analysis and only proceeds to the next level of detail once a general consensus is reached on the information at hand. In the best case, this approach avoids many expenses completely and guarantees that the resource burn of gathering detailed information is only incurred after conceptual agreement is reached. In the worst case, a management disconnect is identified early and wasted effort is avoided while scope is scaled back to acceptable levels.

While this approach seems obvious because of its familiarity, it is completely opposite the traditional BIA that seeks the final level of detail at the beginning of the project—only to produce a requirement that management cannot and will not support or fund. A BIA project’s costs are fully incurred before any results are seen…there is no opportunity for mid-project course correction…staff resources are severely and negatively impacted…the level of detail needed for solutioning is insufficient…the data that is generated quickly becomes useless…the BIA report is filed on the shelf with the last one…and the recovery capability remains unimproved. These are the unfortunate results that an industry-standard BIA produces over and over again.

NextGen IBPD is for organizations who understand that in the face of today’s extremely aggressive DR/BC requirements, the only way to gain management’s buy-in is through accurate and detailed information that can actually be used to reduce costs. These organizations are often:

  • looking to reduce costs associated with DR/BC planning by refreshing outdated BIAs
  • implementing high availability and/or continuous availability solutions
  • extending their DR capability to include a BC capability
  • renewing and/or expanding hotsite contracts
  • are actively involved in consolidating existing facilities, consolidating data centers or de-centralizing data centers
  • are involved with a merger, takeover or acquisition that will impact application rationalization

WTG will conduct a unique, interactive critical application workshop that will define the starting baseline for application and process criticality. The workshop will be conducted in approximately four hours with a group of representatives from both the business and IT areas. Through a proprietary technique of multiple “iterations” that interactively sort and resort the applications, the workshop provides a unique “top-down” approach that reflects the business owner’s view of criticality and a “bottom-up” perspective that reflects IT’s view. Together, these two perspectives create a consensus that is a far more accurate representation of criticality that either view alone can provide. Equally as important, the consensus serves as a point of reference for the subsequent IBPD interviews and will greatly enhance their effectiveness and accuracy by providing a previously-agreed upon context for impact discussions.
The workshop will define the critical business areas, critical business processes, the applications that support them, their RTOs, RPOs and their BCOs). It will also define additional NextGen “level 2” data such as Core Infrastructure, Inherent Criticality, Resultant Criticality, Recovery Groups, Recovery Sequence and Upstream and Downstream dependencies. Collectively, this data will enable very detailed solution modeling and will facilitate design of the most cost- and operationally-effective recovery architectures.

Following the workshop, WTG will also interview business area owners to define their Operational Impacts and when they manifest, their Recovery Resources (staffing) and when they are required, their BC Recovery Requisites (the tools—phones, forms, special equipment, etc.—needed to conduct business) and the viability of manual work-arounds. All elements will be defined relative to seven post-disaster time periods in order to quantify when they manifest and how they escalate during an extended outage. Our method will be to use our experience combined with general industry practices to question initially stated needs and to challenge process owners to “defend” them so as to not overstate them and to avoid the “my department is critical”response so typical in DR/BC planning.

Impacts will be defined relative to the length of the interruption for each of the following loss categories: Financial (cash flow, lost income, increase expenses, fees and penalties), Operational impairment, Regulatory and Legal (suits, sanctions, violations, etc.), Data Loss (paper and /or electronic), damage to Corporate Image and/or Reputation, Health and Safety Concerns or Internal/External Upstream (work inputs) and Downstream (work outputs) disruptions.
Recovery Resources (staff and their direct needs) will be identified in terms of quantify needed across the same seven time periods. We will also define available work-arounds and factor their viability into the staffing requirements. Additionally, the following direct needs will be quantified: type and location of work area, shift shifting and work shifting possibilities, workstation provisioning alternatives and voicemail and email requirements. Fifteen individual reports provide company management with a roadmap for proactive disaster prevention and serve as a long-term baseline for continuous improvement.


  • Facilitated critical needs analysis workshop with business owners and IT representatives
  • “Top-Down / Bottoms-Up” list of critical applications
  • “Top-Down / Bottoms-Up” list of RTOs and RPOs
  • Definition of Resultant Criticalities
  • Definition of Application Recovery Groups
  • Definition of Application Recovery Sequences
  • Definition of high-level Recovery Tiers
  • Checkpoint consensus presentation to project team
  • Documented BC requirements consolidated by department, disaster duration, work shift and work site
  • Necessary Recovery Resources and Recovery Requisites
  • Viable manual alternatives – aka Bridging Procedures
  • Direct needs: type and location of work area, shift shifting and work shifting possibilities, workstation provisioning alternatives, and voicemail and email requirements
  • Consensus presentation to senior management


  • Less impact to business and technical staffs
  • More granular data to design proportionate solutions consistent with investment levels that management can/will support
  • More definition of recovery requisites to subsequently design the most cost-effective recovery architectures
  • Continuous incremental improvement of recoverability
  • Spending directed towards recoverability, not analysis!