Archive for the 'Business Analysis' Category

Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan

Monday, March 10th, 2008

Our experience as IT Consultants has shown that Disaster Recovery (DR) plans are often inadequate to effect full recovery of critical business systems. The frequency of testing is also low and these two factors combine to create an unnecessarily high risk for business. This fact, coupled with the increased requirements for reporting on DR in the forthcoming Isle of Man Financial Services Act 2008 has placed disaster recovery back on the agenda for many Isle of Man company directors and business leaders. A recent Institute of Directors survey of SME’s also places DR and Security high on the priority list for action.
In the event of a disaster situation, you need to be certain that you can recover your critical business data and continue to run your business. So in order to help companies improve their Business Continuity planning, I would like to share with you a simple seven step framework for designing, implementing and maintaining your own Disaster Recovery plan.

1. DR Policy

The policy details why you have a plan, who is responsible for it and how is is to be resourced. Legal and Statutory obligations usually feature at key points within your policy statement. It is also important to remember that your policy should encompass people, process and technology.

2. Risk Analysis

Identify failure risks and categorise these by impact - where possible these should be expressed in financial terms. Look out for cascade effects and dependencies between systems - where the failure of one single step has a knock on effect on many others. Performing Risk Analysis (also known as Business Impact Analysis or BIA), allows you to concentrate your resources where they can create the greatest impact.

3. Controls and Preventative Measures

Many simple and cost effective methods can be employed to reduce the risk of failure. Look for single points of failure and balance the cost of implementation against the risk of failure.

4. Recovery Strategy

This is your high level document that should specify Disaster Scenarios and how you will respond to them. Typical scenarios might include: Pandemic Flu, Building Lockout, Server Failure, Power failure. The strategy document sets the targets for the DR team to meet. You must skip the detail at this stage and concentrate on objectives. In Disaster recovery parlance, the most useful here are Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). You should also consider here how you will communicate with your staff, customers, press and other stakeholders and how you will decide to invoke your DR plan. You should also consider creating a core DR team made up from representatives of each area of the business.

5. Detailed Recovery Planning

For each of the scenarios specified in the Recovery Strategy, a detailed recovery plan is drawn up. The outputs from this step are comprehensive plans for how you will achieve the strategic objectives. All areas of the business need to contribute and show that they have plans in place and that your staff are aware of how these will work in practice. Typical things to consider are data backup, telephone and telecommunications arrangements, office space, insurance. You will need to be able to demonstrate compliance with the legal and statutory requirements of your particular industry sector. All of these arrangements must be documented and lastly and most importantly, be made available off-site. You do not want your recovery plans to be locked in a building you no longer have access to!

6. Test the Plan

Once you have created your DR plan, you must test it. In some industry sectors this is a requirement that must be met annually. If you can arrange for independent testing then do so, as it can be difficult for those closely associated with the creation of the plan to remain objective when testing it. If your business is large enough you can form two DR teams, one to create and one to test. Tests can be desk-based, partial recovery or full recovery.

7. Maintaining the Plan

Change happens! As a result, disaster recovery plans must change too. Because you keep a copy of your disaster recovery plan in multiple locations, you need to make sure each copy remains current. Too often we find that planning for DR is something we do after a new business project is implemented. Embedding DR planning into your project management process will mean that new projects will trigger the requirement to maintain the plan.

If you require any assistance with your own disaster recovery planning and testing, KDR Ebusiness can help. Our experience can help you to meet your statutory requirements and reduce the business risks you face. If you already have an in-house team, we can provide an independent, external audit and test of your existing plan.

Bookmark to:
Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to Del.icio.us Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to digg Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to FURL Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to blinklist Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to My-Tuts Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to reddit Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to Feed Me Links! Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to Technorati Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to Socializer 

Business Requirements: The Good, The Bad and the Ugly

Monday, May 8th, 2006

When considering any changes to the way your business operates, you should always start with a clearly defined set of business requirements.

A good business requirement should have the following attributes:

  • Has a clear objective
  • Possesses a measure of performance
  • Should be high level
  • Defines the expected benefits

It is particularly important to describe tangible and measurable benefits for your business requirement before you undertake the project to deliver it.

So here are some simple illustrative examples of business requirements that are Good, Bad and Ugly:

Good: We need to improve our system response times by 50%. This will increase the productivity in our back-office by reducing the amount of time spent waiting for information to display.

This has a measurable objective, and describes the expected benefit. It avoids going into too much detail and is therefore sufficiently high level. This could be improved by specifying actual productivity gains.

Bad: Our systems are slow, we need to make them quicker so that staff spend less time waiting.

This has an objective, but there is no measure of performance so there is no way to determine afterwards how effective the benefits are.

Ugly: We need to make our systems faster.

This type of requirement would have an unscrupulous vendor rubbing his hands with glee – you might end up spending a great deal more than you had to. And with no actual measures in place you might end up with a smaller improvement than was actually needed.

Bookmark to:
Add 'Business Requirements: The Good, The Bad and the Ugly' to Del.icio.us Add 'Business Requirements: The Good, The Bad and the Ugly' to digg Add 'Business Requirements: The Good, The Bad and the Ugly' to FURL Add 'Business Requirements: The Good, The Bad and the Ugly' to blinklist Add 'Business Requirements: The Good, The Bad and the Ugly' to My-Tuts Add 'Business Requirements: The Good, The Bad and the Ugly' to reddit Add 'Business Requirements: The Good, The Bad and the Ugly' to Feed Me Links! Add 'Business Requirements: The Good, The Bad and the Ugly' to Technorati Add 'Business Requirements: The Good, The Bad and the Ugly' to Socializer