Header photo by Jason Strull

Right now around the world many IT organisations are scrambling to enable remote work. For some, that means dusting off the Business Continuity Plan and executing. For some it’s a minor shift as remote work is already embedded in the culture. For many, perhaps most, it’s a mad scramble.

If you’re in that last category and struggling to identify what systems are important and what can wait, this is for you.

The Long Way

Ordinarily this would part of a broader BCP & DR project. Requirements gathering is completed during the Business Impact Analysis (BIA) and Data Collection phases. Then you’d move into a fairly extensive process of design and implementation before setting up regular reviews. Obviously when time is no longer available we need to dramatically compress this process. In this article I will outline an approach based on a quickfire version of the BIA and Data Collection steps, to understand what you and the business need to achieve, a quick analysis phase before moving straight into an iterative implementation phase.

Build Your Team

No matter which part of the organisation you’re from, you can’t do this solo unless you work in a small organisation and know all of it’s operations intimately. To get this done we need to break down the problem and enlist some help.

1. Break the company into logical groups. Lines of business, departments, teams - whatever makes sense. Depending on organisation size you need to balance granularity of requirements against having to address too many individual groups in such a short time.
2. Reach out to relevant managers and get an assigned representative from each group. This person needs to understand the operations of the group very well and be able to reach out within the group for help. They’ll also be your representative in that group for communication when it comes time to test and validate later. From this point, these are your champions.

Business Impact Analysis

A full BIA is usually a project in itself, engaging key business and technology stakeholders. Ultimately we can boil it down to three key questions. Step one in our quickfire BCP is to answer those questions for each team, department or line of business by speaking to your champions:

1. What does the team do? Build out a list of the teams responsibilities, tasks and deliverable. Ignoring people and systems identify the processes that the team are accountable for on a daily, weekly and monthly basis. This is the foundation for our entire approach.
2. What is the impact of not doing these things? In a full scale engagement, we’d separately rate the impact in terms of business operations, regulatory, customer service & reputation, as well as quantify financial impacts, for a range out outage periods. In a quickfire versions, get them to rank each item 1-3 and make a quick guess at the financial impact of a 1 week outage. Identify any tasks that can be stopped for an extended period. Always remind people to factor in timing of the incident - processes that are only executed periodically can be critical at some times and not others, try to take that into account. Remember at this stage perfect is the enemy of good. Speed over accuracy.
3. Can work be done with reduced staff? More than likely, teams are going to have to work with reduced staff at some point. In the short term potentially because systems cannot cope. When school breaks, now or in a couple weeks depending on your state, many will have additional caring duties and we have to consider the impact to work from home productivity as parents have no caring options.

Data Collection

Once you have a prioritised list of what the team does, and not before, focus on how they do it. This is also the time to consider workarounds. For each item on our BIA list identify:

1. What systems/applications are required? For each item, work out what IT systems and applications are used. This enables you to now map IT systems back to the business priorities from the BIA.
2. What workarounds can be used? Find any workarounds that can be used if systems are not available. Deferring work, manual options, alternative systems. Particularly if you know there are systems that are hard to publish remotely, now is the time to find alternatives.

Analysis

Once you’ve quickly collated this information, you can build a quick and dirty requirements sheet. Essentially, map the priorities on business tasks to the systems they require. You’ll find multiple teams will highlight the same systems, so assign it the highest priority that appears. You now have an ordered list to focus your efforts.

Run! (or Iterative Implementation)

Now that the most important systems are identified, it’s time to go back to running at a million miles an hour getting it done. At a high level, something like the following makes sense as an iterative loop:

1. Communicate the current plan & priorities to the business via your champions or usual channels.
2. Get next highest priority system published remotely.
3. Communicate updated procedures via the champions (or usual channels).
4. Monitor capacity on your remote systems - VDI platforms, VPN gateways etc will see extra load and may hit capacity. If this becomes an issue, work with the business on demand reduction in the short term. If you can take advantage of cloud capacity quickly, do it now.
5. Check in on business status via your champions/service desk - identify any issues blocking blocking critical work and prioritise on your list. Low impact issues need to wait!

When it comes to publishing your applications, you’ll probably find there are three categories you need to deal with:

1. Already set-up for remote access. The low handing fruit. Via your champions, ensure teams know how to access what they need. Your primary issue here will be capacity management, so consider how you’ll do this. Let your champions know there may be a need to restrict usage to key staff.
2. Not set up for remote access, but relatively straightforward. Once the basics are in place, you can work on publishing out new apps based on your priority list. We’re not looking at the tech here, but initially this should leverage things you already have in place, be that VDI, app publishing or VPNs, to enable you to move fast.
3. Problem applications. Communicate this to your champions early. In the early phase, the business needs to focus on workarounds and alternatives while technical problems get solved. Once the initial wave is addressed, you can work on more comprehensive plans.

What next?

It’s clear that this is not going to be a short term incident. Once the initial fire is out, we need to focus on phase 2:

1. Medium to long terms capacity: if you’ve had to work on reduced staff due to capacity, or have solved capacity with cloud platforms, spend the time to revisit this. Cloud services may come with a significant bill for long terms use, though expansion of on-prem may also become challenging with hardware availability.
2. Security implications: revisit any changes that you’ve made in the context of security. Particularly if there have been alterations to firewall or VPN rules, revisit them now when things are calmer and validate. Have you had to add a ton of new users without multi-factor authentication? work on a plan to roll it out. Do you now have un-managed personal devices on the network via VPN?
3. Self care: Honestly, this is a big undertaking. The one thing every large delivery projects I’ve ever done had in common was physical and mental exhaustion. Teams everywhere are going to working to the limit. Keep an eye on yourself and your team to make sure you stay this side of it.