Modern Tools for Business Continuity / Disaster Recovery

Today’s world provides so many enabling technologies for enabling an efficient and effective BC / DR plan in place.  Enterprises can no longer justify not having a working and effective BC / DR plans in place.

The coming of the Cloud is a tremendous help for BC/DR planning. You have a safe repository of all your important information physically separate from your physical operations. Even if your whole building becomes inaccessible through fire, flood, or terrorism, the data, applications, and knowledge stored in the cloud remain untouched, completely unaware that something has occurred. It is just there waiting for you to access it from wherever you are. No time or effort or cost need to be spend recreating hardware and infrastructure.

The BC / DR plans themselves that used to be kept in physical paper files can now be stored in electronic format, immediately accessible and available through different channels and devices. In electronic format, it becomes easy to update and keep current, easy to disseminate and and ensure that everyone has the latest version, and very importantly, easy to access when needed.

Copies of the plans can be kept in secure thumb drives at the homes of key employees.

When disaster strikes, the ubiquity of handheld smart devices allow employees to be easily advised, easily contacted, and potentially able to work from anywhere. 

For a web-based central platform for reporting and keeping track of what’s going on, you can also put up a wiki platform that key personnel can readily update as information and progress occur.  A wiki software you can use is Mediawiki.  This is the same software that Wikipedia runs on.

Tools for automating the DR testing make coming up with working plans far easier.  Solutions like VirtualSharp or Sanovi can help here.

BC / DR solutions need to go all the way to recovery.  Many cloud solutions merely back up your data and applications.  This is much better than nothing, but it is not enough.  You also need to restore the data and applications into a state suitable to continue doing business.  Plain backups do not help in adhering to RPOs (Recovery Point Objectives) and RTOs (Recovery Time Objectives) set for critical processes and data.

A lot of these tools were not around ten years ago.  Failure to take advantage of them is almost criminal.

The Work Breakdown Structure (WBS), part 2

Since the WBS is a hierarchical structure, it has bottom level parts.  The WBS can be constructed like a table of contents, like so:

WBS Item 1 WBS Item 1.1 WBS Item 1.2 WBS Item 1.3 WBS Item 1.3.1 WBS Item 1.3.2 WBS Item 1.4 WBS Item 2 WBS Item 2.1

The lowest level items (shown above in bold) are called ‘Work Packages’.  The Work Packages are discrete pieces of work to be assigned to someone in the project, perhaps an individual, a business unit, and internal, team, or a contractor.  The key is that there is someone responsible for delivering the Work Package.

WBS’s should be oriented towards the deliverables, not towards the functional groups.

The reason for breaking down the project into smaller work packages is for management and control. 

The smaller a piece of work is, the easier it is to estimate how much time is needed to do the work.  Work packages also facilitate the scheduling of the project. The work packages can be the components mentioned in the master schedule. Work packages can be scheduled individually, and the resulting duration be fed into the master schedule, which only shows the work packages.

It is also easier to estimate the cost of smaller work than bigger work.  To estimate the cost of the project, just estimate the cost of each individual work package and sum them up.

The WBS is often claimed to be the backbone of the project, and some writers have said that project failures can be traced back to faulty WBS’s:

“Component or full-project failures, when they do occur, can often be traced to a poorly developed or non-existent WBS”(Norman, Brotherton, and Fried, "Work Breakdown Structures: The Foundation for Project Management Excellence")

The Work Breakdown Structure (WBS)

After the Gantt chart and the network diagram, there is perhaps no other project management tool that is more ubiquitously discussed than the WBS. 

As the Gantt chart is the primary tool for documenting the project schedule, so is the WBS the primary tool for documenting the project scope.

What is a WBS?

The PMBOK Guide describes the WBS as “a deliverable-oriented hierarchical decomposition of the work required to be executed by the project team to accomplish the project objectives and create the required deliverables.” 

That is, the WBS, “defines the total scope of the project.”

According to this definition, the WBS is a “decomposition of the work required”. 

But work required to do what? There are two kinds of work:

1. Work required to accomplish the project objectives
2. Work required to create the required deliverables

Together, these two kinds of work define the sum total of all kinds of work required: all project work falls into at least one of these two.  We say at least, because it is possible that some piece of work can be properly thought of as belonging to one or the other – that is not a matter of great concern.

The first kind of work is about work that need to be done in order to successfully complete the project objectives, even though they are not the purpose of the project.  An example of this type of work is developing the project schedule (which is needed to help attain project completion date objectives).  Other examples include developing a WBS,  supervising the work-force, and conducting project communications.

The second kind of work is covers what’s needed to deliver what the project needs.  Examples include designing a piece of software, integrating components, reviewing the quality of sub-components, and testing the components.

Note that the WBS is “deliverable-oriented”, but it is not a compilation of the deliverables.  It is a compilation of the work required, hierarchically organised around the deliverables.  The star of the show is the work, not the deliverables.

A software development project with the goal of delivering a commercial software product (and nothing else, not even documentation), the list of deliverables will not change, whether you use an Agile approach or a waterfall approach.

However, the WBS for the Agile approach will be different from the WBS of a waterfall approach.  Examples of the differences include:

• The Agile WBS will include such work as ‘Write User Stories’
• The Waterfall WBS will include such work as ‘Develop Design Document’

The deliverable is the outcome, the work is the effort and activities required to produce the outcome. 

Given that there are many different ways to produce the outcome, the WBS is a reflection of the plan chosen to produce the outcome.  Change the strategy, the WBS can potentially change.