Developing a Disaster Recovery Plan

Developing a Disaster Recovery Plan

Information Gathering

  • Determine which senior executive(s) will have overall responsibility for disaster recovery.
  • Have this executive appoint a disaster recovery coordinator.
  • Appoint a disaster recovery team leader for each operational unit, such as the server backup or the telephone system.
  • Convene the disaster recovery planning team and sub-teams as appropriate. Working with senior executives responsible for disaster recovery, the disaster recovery coordinator should identify the following:
    • Scope — the areas to be covered by the disaster recovery plan
    • Objectives — what is worked toward and the course of action that the disaster recovery team intends to follow
    • Assumptions — what is being taken for granted or accepted as true without proof?
  • Set a project timetable and draft project plan, including assignment of task responsibilities.
  • Obtain senior management’s approval for scope, objections, assumptions and project plan.

Conduct the Business Impact Analysis

  • Identify which business departments, functions or systems are most vulnerable to potential threats, what the potential types of threat are, and what effect each identified potential threat would have on each of the vulnerable areas within the organization.
    • Identify functions, processes and systems.
    • Interview information systems support personnel.
    • Interview business unit personnel.
    • Analyze results to determine critical systems, applications and business processes.
    • Prepare impact analysis on interruption on critical systems.


Conduct Risk Assessment

  • Work with the organization’s technical and security person to determine the probability of each functional business units’ critical systems becoming severely disrupted. Document the amount of acceptable risk the business unit can tolerate. For each critical system, the following information needs to be provided:
    • Review physical security. (i.e., secure office, building access off hours, etc.).
    • Review backup systems and data security.
    • Review policies on personnel termination and transfer.
    • Identify systems supporting mission-critical functions.
    • Identify vulnerabilities, such as physical attacks, or acts of God, such as floods.
    • Assess probability of system failure or disruption.
    • Prepare risk and security analysis.


Develop Strategic Outline for Recovery

  • Assemble groups as appropriate for the following:
    • hardware and operating systems
    • communications
    • applications
    • facilities
    • other critical functions and business processes as identified in the Business Impact Analysis step
  • For each of the above systems/processes quantify the following processing requirements:
    • light, normal, and heavy processing days
    • transaction volumes
    • dollar volume, if any
    • estimated process time
    • allowable delays (days, hours, minutes, etc.)
  • Detail all the steps in workflow for each critical business function. (For example, for payroll processing, include all of the steps and the order in which the steps must be completed.)
  • Identify systems and applications:
    • component name and technical identification, if any
    • type (online, batch process, script)
    • frequency
    • run time
    • allowable delay (days, hours, minutes, etc.)
  • Identify all vital records:
    • name and description
    • type (backup, original, master, history)
    • storage location
    • source of item or record
    • ease of replacement by another source
    • backup and backup generation frequency
    • number of backup generations available onsite and offsite
    • location of backups
    • media key, retention period, rotation cycle
    • person authorized for backup retrieval
  • Identify what the minimum requirements or replacement of the critical function during the disruption would be if a severe disruption occurred:
    • type (server hardware, software, research materials, etc.)
    • item name and description
    • quantity required
    • location of inventory, alternative, or offsite storage
    • vendor/supplier
  • Identify if alternative methods of processing either exist or could be developed, quantify processing (include manual processes).
  • Identify person(s) who support the system or the application.
  • Identify both primary and secondary person to contact if system or application cannot function as normal.
  • Identify all vendors associated with the system or application.
  • Document business unit strategy during recovery (conceptually how the unit will function).
  • Quantify resources required for recovery by time frame.
  • Develop and document recovery strategy, including priorities for recovering system/function components, and recovery schedule.


Review Onsite and Offsite Backup and Recovery Procedures

  • Review current records (operating systems, code).
  • Review current offsite storage facility or arrange for facility.
  • Review backup and offsite backup storage policies or create them.
  • Present to functional business unit leader for approval.


Select Alternate Facility

  • Determine resource requirements.
  • Assess platform uniqueness of unit systems (Macintosh, IBM, Oracle, etc.).
  • Identify alternative facilities.
  • Review cost/benefit.
  • Evaluate and make recommendation.
  • Present to business unit leader for approval.
  • Make selection.



Develop Recovery Plan

  • Determine objective — This may have been documented in the information gathering phase. Establish information for each business unit.
  • Plan assumptions.
  • Develop criteria for invoking the plan:
    • Document emergency response procedures to occur during and after an emergency is declared for that business unit, and after the emergency check the building before allowing individuals to enter.
    • Document procedures for assessment and declaring a state of emergency.
    • Document notification procedures for alerting all senior management executives, disaster recovery team members, and business unit executives.
    • Document notification procedures for alerting business unit’s personnel of alternate location.
  • Define role responsibilities and authority:
    • Identify disaster recovery team and business unit personnel.
    • Determine recovery team description and charge.
    • Determine recovery team staffing.
    • Create transportation schedules for media and teams.
  • Create procedures for operating in contingency mode:
    • Create process descriptions.
    • Determine minimum processing requirements.
    • Determine categories for vital records.
    • Identify location of vital records.
    • Identify forms requirements.
    • Document critical forms.
    • Establish equipment descriptions.
    • Document equipment — at the recovery site and in the business unit.
    • Create software descriptions.
    • Determine software used in recovery and in production.
    • Produce logical drawings of communication and data networks in the business unit.
    • Produce logical drawings of communication and data networks during recovery.
    • Produce a list of all vendors.
    • Review vendor restrictions.
    • Determine miscellaneous inventory.
    • Determine communications needs — production and in the recovery site.
  • Document resource plan for operating in contingency mode.
  • Develop criteria for returning to normal operating mode.
  • Develop procedures for returning to normal operating mode.
  • Perform testing and training:
    • Document testing data.
    • Complete disaster/disruption scenarios.
    • Develop action plans for each scenario.
  • Implement plan maintenance:
    • Document maintenance review schedule (yearly, quarterly, etc.).
    • Develop maintenance review action plans.
    • Create maintenance review for recovery teams.
    • Perform maintenance review of team activities.
    • Perform maintenance review/revise tasks.
    • Perform maintenance review/revise documentation.
  • Include appendices:
    • inventory and report forms
    • maintenance forms
    • hardware lists and serial numbers
    • software lists and license numbers
    • contact list for vendors
    • contact list for all staff with telephone numbers for home, work numbers, cell phone, and pager
    • network schematic diagrams
    • equipment room floor grid diagrams
    • contract and maintenance agreements
    • special operating instructions for sensitive equipment
    • cellular telephone inventory and agreement


  • Develop test strategy.
  • Develop test plans.
  • Conduct tests.
  • Modify the plan as necessary.


  • Review changes in the environment, technology and procedures.
  • Develop maintenance triggers and procedures.
  • Submit changes for system development procedures.
  • Modify unit change management procedures.
  • Produce plan updates and distribute.
  • Establish periodic review and update procedures.

Posted in: Service Delivery

Leave a Comment (0) →

The Importance of the Sales Engineer

The Importance of the Sales Engineer

How Important is the Sales Engineer’s Role?

The importance of the sales engineer’s role in building, growing and supporting an IT organization’s sales and marketing efforts cannot be overstated. The sales engineer is the buffer between sales and deployment, and is one of the keys to project profitability. Let’s face it – we all know that a good sales person is going to do everything in their power in order to close an opportunity, and while this is great news (as we all want more sales), sometimes a sales person’s eagerness can create a client expectation that is difficult to meet. I’m certain that you know exactly what I’m talking about. A sales engineer not only helps train sales staff in what is and is not possible; and at what cost, but is also instrumental in working with vendors and partners in order to flush out a solution, put together a parts list and develop a project plan.

All of these functions are critical to insuring smooth project delivery. Let’s take a look at a typical scenario where a sales person has made the initial contact with a new prospect for an infrastructure upgrade. The sales person has performed a needs analysis, and a technician has completed a network analysis. The result is that the prospect will need to migrate from Microsoft Windows Server 2003 to a Microsoft Essential Business Server 2008 solution, and replace all 20 of the users’ desktops with new ones running Microsoft Windows Vista Business. Because the prospect has an aging analog phone system, the sales person would like to quote a VoIP solution as well. The sales person and technician have done a good job at gathering all of the necessary information the sales engineer will need to review for the proposed solution, including network documentation and asset and software licensing information..

The sales engineer will discuss the proposed solution with the account manager and technician in order to get a clear understanding  of the “lay of the land” at the prospect’s location, and ask specific clarifying questions in order to shape the final solution and proposal. In many cases, sales staff will put together standard proposals for say, Managed Services Agreements or simple services and solutions, but the sales engineer will always review any and all quotes and proposals for approval before they are presented to a prospect or client. This process can save countless thousands of dollars over the years, as it reduces the chance of quoting the wrong service, solution, equipment and/or price, which always affects client satisfaction. In addition, it sets appropriate prospect and client expectations in terms of provisioning, implementation and turn-up schedules.

Based upon the complexity of the proposed solution or other factors, the sales engineer may meet with the prospect or client themselves, and always with the account manager, whose job it is to build and maintain the client relationship. It is the account manager’s responsibility to marshal the support necessary to meet the prospect’s or client’s needs, and they must constantly be operating in this fashion – we always want the account manager to be the client contact in the relationship, deepening their bond in order to build the trust needed to continue to sell solutions deep into their environment (becoming the Trusted Advisor).

Once the sales engineer feels that they understand the prospect’s or client’s needs completely, and has all of the information required in order to scope the solution, they can move from the discovery to the design phase of the project. This is where the value of a good sales engineer really shines. An effective sales engineer also has the responsibility to build close relationships, but where the account manager builds these relationships with clients, the sales engineer builds them with vendors and fulfillment partners. The reason for this is simple, and reflects the basic tenets of human nature – people respond best to those with whom they have a relationship; and the closer the relationship, the better and faster they respond.

So the sales engineer will leverage the relationships they’ve built with their distributors, vendors and fulfillment partners in order to price, quote and deliver this infrastructure upgrade. Their distributor will provide the best quotes they can on server and desktop hardware, as well as licensing. Since the solution requires a VoIP quote, the sales engineer will engage their VoIP vendor, as well as their T-1 vendor, who will be upgrading the bandwidth at the location in order to support the prospect’s new voice and data requirements.

Once the sales engineer has received several different quotes from the distributor, VoIP and broadband vendor, they will determine whether or not to present the prospect with different options, or present a single quote in their proposal reflecting their preferred solution. This decision will be based upon current company policy, as well as the overall profit goal for the solution.

We’ve found that our closing percentage for solutions is directly related to the quality of our proposals. This is why we always include a Microsoft Visio drawing of the proposed solution from a “before” and “after” perspective, as well as a breakdown of the phases of the project, along with an estimated timeline of the proposed work scope.

Once the proposal has been created, the sales engineer briefs the account manager on the solution and goes over the proposal with them in detail. The last part of the proposal to be finalized will be the quoted price and payment terms. In our proposals, we always ask for the equipment to be paid for in advance, as well as any lab labor we will initiate at our offices to prep the solution before landing it at the client’s location. The balance of our services is due upon completion of the project, to allow for any change orders along the way.

We’ve found that billing in this manner keeps us from going out of pocket in the initial phases of our projects, and also insures that we’re paid for every hour we spend delivering our solutions. I’m sure you’ve experienced all kinds of surprises and “gotcha’s” at client locations when performing the onsite phases of project delivery. Since many of our solutions sometimes involve numerous vendors or fulfillment partners; where we are not in direct physical control of each aspect of project delivery, we must communicate and have the prospect or client agree to our change management process when dealing with situations that require us to deviate from our project plan or encounter exceptions that impact our expected completion time.

We do work with many service providers; however, that have perfected (for the most part) their onsite project quoting process to the point where they quote and guarantee their final solution price. This can be achieved when they are in physical control of each phase of project delivery, and only then through a very detailed and thorough project planning process, which includes meticulous onsite prep work to identify every single item that needs to be addressed in granular detail during project rollout and implementation. But even the best laid plans can go awry, so they make certain to include enough “cushion” in their quotes to absorb any unforeseen variables that can impact the profitability of the project.

Once the account manager has been briefed on and agrees with the proposal; and based upon the complexity of the solution, the sales engineer may become involved in the final presentation of the proposed solution to the prospect. Their intimate understanding of all facets of any solution they’ve designed makes them an invaluable asset in many client presentations.

Let’s take a look at the process the sales engineer will go through in this scenario:

  • Receives information/documentation from the account manager and technician for the proposed solution
  • Meets with the account manager and technician in order to understand the basic needs and spell out the preliminary scope of the proposed solution
  • May meet with the prospect along with the account manager in order to clarify specifics of the prospect’s needs
  • Meets with the account manager to finalize the solution before the design phase of the project
  • Contacts distributors, vendors and fulfillment partners for price quotes
  • Receives quotes back from distributors, vendors and fulfillment partners and determines the best method of creating the proposal with input from the sales person
  • Creates the proposal with network drawings, phases of the project and an estimated timeline
  • Briefs the account manager on the completed solution and proposal
  • Becomes a resource to be called upon during future client presentations


As you can see, a good sales engineer not only helps close client business and increase revenues, but also saves money by insuring that solutions are scoped properly and quotes and proposals are priced correctly. And finally, a good sales engineer helps to increase client satisfaction through all of the above, as well as by helping shape appropriate client expectations.

Posted in: Sales

Leave a Comment (0) →
Page 30 of 285 «...10202829303132...»