Business Continuity Plan and Tier Levels

When planning a new application for deployment, it is important to include a business continuity plan (BCP) and assign the tier level even at the early stages of the project. The reason behind it is more than just to determine how much to budget for a fully functional BCP, but also to ensure that the application is reliable.

Often, important applications that have high visibility must have a robust production environment to prepare for any catastrophe. Critical applications should have BCPs should something bad happens to that environment.

Assigning the tier level for the application goes hand-in-hand with BCP. The deciding factor for most BCPs, especially if there are limitations on budgets and resources, is the tier level. High risk tiers such as tier level 1 and 2 applications must have a good BCP.

Having BCPs for these types of applications would guarantee that the applications will be back up and usable at a given amount of time mentioned in the plan.

1. Define the new application. This is when the PM should find out the purpose and functions of the application.
2. Define the importance of the application to the users. Is the application something that they would highly depend on in order to perform their daily tasks? Is this a high-income generating application?
3. Define the number of users. Is this an application that many users in the organization will share or only a few handfuls of users will use?
4. Define the impact should the application suffer a major outage. Will there be setbacks? Will it hamper productivity? Will there be financial loss to the organization?
5. Define any work around. Find out if or when this new application goes down if there are other similar applications that can provide some work around . This other application may act as the back up or temporary solution until the application becomes available again either in the production environment or BCP environment.
6. Define the RTO (Return to Operation) time required for this application. This would be the maximum time that the users can tolerate or allow an outage. For example, if the users can do without the application for three days, but must have it functional by the end of the 3rd day, then the RTO should be three days.

After assessing the risks, the next step is for the project team to assign the tier level. The team should define the tier level based on findings. Depending on how you grade or assign a tier, you can assess if you need a BCP. For example, assign a tier level 1 for critical applications with huge impact. This means multiple users impacted, huge financial loss to the organization due to lack of productivity, etc. Assign tier 2 for a medium level impact in both numbers of users and financial loss. Assign tier 3 for minimal impact and 4 for no impact or something the users can do without for an indefinite time. Usually, a tier 1 or 2 would definitely need a BCP environment.

A PM should assign a BCP also based on severity of impact

Tier 1- Severe Impact

Tier 2 - Major Impact

Tier 3 - Moderate Impact

Tier 4 - Minor Impact

During the project sizing, a PM should include the business continuity plan. The sizing should include the overall cost associated in duplicating the production environment in BCP. Will the budget limit the number of equipment? Instead of a pair of load balanced servers, at times a BCP can only have one system.

This is acceptable in most cases to save money. As long as the users will be able to use their application and can get by with one piece of equipment as opposed to using two. In addition, a PM would need the business users' approval to do so...such as accepting another risk of downtime should that one server encounters some problems such as slowness, outage or intermittent failures.

If that is not acceptable, they should come up with more dollars to have an identical environment for a seamless experience.

As with most technical projects in technology whereby a new application will be deployed, there is an SLA or Service Level Agreement where the users or business proponents should approve and sign off. Included in the SLA would be the schedule when the application is expected to be up and usable, the maintenance window, tier level and business continuity plan.

After receiving the sign-off, project planning can proceed with the production and BCP environments created concurrently.