Continja

Seven Tiers of Disaster Recovery

2012-01-25T20:29:00.000-05:00

Photo Source: Topato

Today, to make a long story short, I landed upon the Wikipedia entry for the "Seven Tiers of Disaster Recovery". The original source is over here at Recovery Specialties.

If you're not familiar, it's a very common, if not somewhat dated, breakdown of the various levels of systems and data protection categorized by tier. Starting at 0, the higher the tier, the more protection, right?

[Ignore the fact that tiers 0-7 is actually 8 tiers... but I suppose we don't count "Tier 0: No offsite data".]

At first glance, one might think that "Tier 0: No Offsite Data" is as bad as it could get for a specific system or an organization in terms of preparedness. It's either a DR planner's dream or nightmare, depending on your expectations.

But no. It could be worse. In fact, the spectrum of tiers is to be expanded... and in the negative direction...

As I learned from the Wikipedia entry:

Tier -1: No backup of any sort

Businesses with Tier -1 continuity have absolutely no backups and data recovery is completely impossible.

[So this would exclude backing up to a local VTL providing recovery only in scenarios less than total loss of the data center, which I suppose could be classed a Tier 0 in the original model.]

Tier -2: Intentional deletion of data

Users deliberately delete mission critical data and cripple their organization.

[Perhaps a Mexican drug cartel, or a presidential candidate, earning a lot of money in ways they don't want discovered might consider implementing DR at Tier -2, but more likely at Tier -3.]

Tier -3: Human memory

A human is tasked with memorizing all company data. Transmission occurs by speech from this employee to all other employees. Computers or other technology are not used in any way whatsoever to assist with storage. Even hard copy backups are strictly forbidden. Recovery is not possible if the storage user is lost.

[Johnny Mnemonic was into this kind of thing.]

Tier -4: Data has never existed

Data has never existed possibly because the company does not exist, it retains no employees, or business operations have not yet begun.

[Yes, we even have a DR solution for the company that never makes it past the dream stage, or whose product won't exist for another hundred years, or may never exist in this universe.]

For reading all the way to the end, as an added bonus, you can download a PDF of the Wikipedia entry for posting to your cubicle wall. I saved it just in case someone reverts the article back.

Sickweather Says Social Data Analysis Has Already Detected Two Illness Outbreaks

2012-01-22T13:13:00.000-05:00

Sickweather, a start-up that’s attempting to forecast illness outbreaks by tracking Facebook and Twitter updates, says its method might have already worked.

That is, Sickweather noticed increased occurrences of the word “cough” near Algonquin, Ill., dating back to Oct. 5, about one month before whooping cough reports hit the local news. About a month later, the service recorded the same trends in Milwaukee, Wis., another area hit by whooping cough.

Read More

Ultimate Productivity and Life Management with Springpad

2012-01-22T13:08:00.001-05:00

Over the years, I have been on a constant search for just the right combination of tools and processes that would give me the most features, most accessibility and least management headaches possible, while giving me the most control over all the information and to-do’s in my life that I need to keep track of.

Previous iterations of my ‘method’ involved using MS OneNote, Evernote, Google Docs, Producteev, Google Notebook, Google Tasks, Astrid Tasks for Android, Remember the Milk, a Wiki, or some combination. But each had one more missing features or failures that made it almost too cumbersome to manage once I really started using it daily.

Then, one, day, my sister introduced me to Springpad. I admit that I didn’t like it at first. But over the past several months, it has met my every need. And I am still finding new ways to use it to make it even better. With that said, it isn’t perfect, but I’ll get to those later.

So, “How do I use Springpad?” you ask.

First, if you haven’t already, read these three articles:

Getting Things Done with Google Notebook
Practicing Simplified GTD
Getting Results the Agile Way (Getting Started Guide)

The first walks you through setting up Google Notebook to manage your life using the Getting Things Done (GTD) method, and in the process, does a good job of explaining the hightlights of GTD itself.

The second is one example of how you can stick with the basic principles of GTD, but water it down to better suit your own needs.

The third, is just an intro to Agile Results. If you have a chance, you can read the entire book online for free.

I provided the above links as background, because my own method is a combination of both GTD and the Agile Way... with some of my own personal tweaks (apologies in advance to purists of either).

My Springpad Setup - The Notebooks

Create a notebook called “Braindump”. This is the universal Inbox. Throughout the day, I collect notes, ideas, things I need to do and emails I want to keep (yes, you can forward emails to Springpad and store them), and store them here for later processing. I color this notebook orange.
Create notebooks called “Big Picture”, “Weekly Review” and “Ideas”. These are reserved for strategic thinking. I color these brown.
Create notebooks for your contexts (ie, the ‘places’ where you get things done). In my case, I created 3 called “@Computer” (my personal computer), “@Office” (work) and “@Home” (at home, but not at the computer). I color all of these green.
Create one notebook (for now) for a sample project. GTD defines a ‘project’ as any effort that is composed of multiple individual tasks, and requires completion of all component tasks before you can call it complete. I color my work-related project folders red, and my personal project folders blue. Note that I also use these project notebooks to store notes, emails, call logs, meeting notes, charter, risk assessment, mission statement, etc, related to the project (as well as project tasks) for the life of the project (to be archived with the project closes). Additionally, I create a “Work” notebook colored red, and a “Home” notebook colored blue. I use these folders to store work or home-related information that isn’t necessarily tied to any project. The colors just help me visually group them together quickly.

That’s the basic foundation. I do have a few other notebooks for different purposes, but for now, this will get us where we want to be as a starting point.

My Springpad Setup - The Tags

Keeping with the GTD method, I primarily use 5 tags:

Next Action: These are things that I can do right away (once I’m in the ‘context’ to do it).
Waiting: These are things that I need to do, but before I can, I am waiting for something else to happen or someone to deliver something to me.
Scheduled: These are things that I need to do, but for whatever reason I’ve scheduled it for a particular date in the future.
Tickler: These are my maybe/someday items that are not a high priority, or they may just be an idea that needs more thought before figuring out what I really want to do, if anything.
Complete: Done.

Putting it all Together - Processing

As I mentioned earlier, as things come up throughout the day, I drop them into the Braindump notebook. Any ideas or tasks get entered manually. The notable exception are tasks that I can do immediately and take less than 2 minutes (eg, replying to an email). If I can do it right away in less than 2 minutes, I just do it. Everything else goes into Braindump. But emails that require some research before replying or something I just can’t do at the moment (because it’s personal, but I’m at the office), I forward to my Springpad email address (using some markup in the Subject line) so that it gets put into the Braindump notebook.

Every few hours, or when I’m in-between tasks and switching mental gears, I ‘process’ my Braindump. This means going through the items in the Braindump notebook, tagging them and then putting them where they belong. For example, a work-related task I can do right away would be tagged “Next Action”, then moved into the “@Office” context notebook. If someone sent me an article to read online, I tag that as “Next Action” and move it to the “@Computer” context notebook. A non-actionable, informational e-mail about a project doesn’t get a tag, and just gets moved to the relevant project’s notebook.

I continue processing my Braindump until it’s empty.

When I’m finished processing, I can go to the context notebook (e.g. @Office), filter on “Next Actions” and all I see are those thing I need to do and can do right now. (Yes, one of the powerful features is that tags stick with the item when you move it to different notebooks.)

Putting it all Together - Projects

Managing smaller projects is where I find tremendous value in Springpad. I develop my WBS, or at least a list of tasks required for the effort, and I put all of these into the project’s notebook, along with any notes, files or other related information. I then find the first (or next) item that I can do right away, tag it as a Next Action and ADD it (don’t MOVE it) to the context notebook. (Items can exist in multiple notebooks!)

So now, that item appears in my filtered list of Next Actions in the relelvant context notebook. I don’t have to look in multiple places to see what I need to do next for each of the multiple projects I have going on. The next steps are all visible in one place.

Putting it all Together - Completing Tasks

When I complete a project-related task, I remove the Next Action tag, and instead tag it “Complete”. Then I remove it from the context notebook, but leave it in the project’s notebook. This way, in the project’s notebook, I still have a record of what’s been done for future review, but it’s not in my way when I’m trying to work on something unrelated. If this task was a biggie, or a major milestone, I will also ADD it to the “Weekly Review” notebook.

I then go to the project notebook and see what needs to be done next, tag it Next Action or Waiting as appropriate, or schedule it and tag it Scheduled, then ADD it to the context notebook.

When I complete other tasks in my context notebook, depending on how big/important the task was, I’ll either just delete it or I’ll move it to the “Weekly Review” notebook.

Putting it all Together - Strategic Thinking

Inside the “Big Picture” notebook, I have a single note called Strategic Vision, where continuously update what I want my world to look like a year, 2 or 3 years from now, depending on the subject or Hotspot.

I create a new note every Friday night or Monday morning called “Weekly Outcomes for [date]” and, following the Agile methodology, identify 3 major goals/outcomes I want to achieve that week in each of my Hotspots. At the end of each day, or beginning of the next, I take a look at my Weekly Outcomes, my current Next Actions task list, Ideas, etc, and create a new note titled “Daily Outcomes for [date]”. This is what I use as the basis for my task prioritization and figuring out, of all the things I CAN do next, what SHOULD I do next.

At the end of the week, I conduct a “Friday Reflection” review of all the things I’ve done and progress I’m making toward my objectives, going through all the completed tasks in the “Weekly Review” notebook. I make notes (stored in “Big Picture”) about what challenges kept me from achieving my goals, or maybe I need to better define my goals, or maybe I didn’t set my goals high enough. This reflection feeds my Weekly and Daily Outcomes for the next week. I also take a look at my Strategic Vision, to make sure what I’m doing is still on the path to where I want to be or, if something has changed, that my vision is updated to reflect it.

Summary

So that, in a nutshell, is how I use Springpad (and manage my world).

A few other things to point out about Springpad that makes it awesome:

All the data is stored in the ‘cloud’ and is accessible from any computer with an internet connection (assuming the company firewall isn’t blocking it).
There are Android and iPhone apps, so you can have access to all your data while on the go. (Love this!)
You can use the Scheduling/Alert feature to add deadlines and reminders to any item, and even integrate with Google Calendar (do I don’t use this integration feature yet).
I just recently starting storing my favorite recipes using the special "Recipe" type. Then I can pull up the recipe on my tablet in the kitchen instead of printing it out or running back and forth between the kitchen and then den.

The only real complaint I have is that the WYSIWYG editor leaves a lot to be desired. When I make notes, I use a lot of outlining with bullets or numbered lists. But Springpad only lets you do one level of indentation, which sucks... just a bit.

Do you use Springpad for GTD, Agile or anything else? What do you think?

RE: The differences between business continuity and disaster recovery explained

2010-10-09T09:55:00.002-04:00

While waiting to have my oil changed & power steering checked out at the Nissan dealership this morning, I happened across a set of articles posted to Helium.com discussing the differences between business continuity and disaster recovery. I felt it my moral and professional obligation to chime in.

What follows is the article as I originally posted there (with a little added formatting to make it easier to read). Enjoy.

I think the responses to the top article show that there is quite a bit of disparity, even among industry professionals, about how to define business continuity, disaster recovery, crisis management, risk management and organizational resiliency. I don't think anyone is right or wrong, but I do believe it's important that the terminology is defined and used consistently within an organization. How do these terms apply in companies I work with?

Risk Management

First, with respect to "risk", in contrast to the other posts and common usage of the word, risk management is not just about reducing the loss impact of unexpected events. Risk management is about managing uncertainty as it relates to the business and business outcomes. These uncertainties can be both good and bad and have both positive and negative impact. We call the good risks "opportunities". We might call the bad risks "threats".

From a very high level, there are two components to any uncertainty:
The probability that an uncertain event will occur or scenario will be realized, and
The impact of that uncertainty should it occur or be realized.

Within risk management, we (need to/should) tackle both.

For opportunities, we work to identify what positive scenarios could happen, how the organization can take advantage of those opportunities if/when they happen and finally how the organization might influence and increase the likelihood that that the opportunity does happen.

Regarding the bad, we do the same. We identify threats to the organization, how the organization can reduce the impact should the threat become reality and finally how can the organization decrease the likelihood of or prevent that event.

Business Continuity

From this perspective, among all the uncertainties (risks) identified, many of them have to do with projects/programs or corporate level strategy including product launches, marketing campaigns, public relations, trademarks/copyrights/patents, etc. But a number of these involve day-to-day operations and the potential to interrupt critical activities that keep the business going.

Among these operational risks one might include threats to process management (increased variation), regulatory compliance, legal liability, employee safety/security, the supply chain, IT system and service availability and information security. The threats to each of these critical functions include things like lack of or inadequate process control, lack of policies or inadequate policy enforcement, environmental/safety hazards, viruses, hackers, lost laptops and, of course, natural and man-made 'disasters'.

As a subset of Risk Management, Business Continuity Management deals with a specific category of risks to the organization that have the potential to impact critical day-to-day business activities. And while we primarily deal with threats that could, if left alone long enough, result in losses fatal to the company, BC planners are often in a unique position within the company to identify and help the company take advantage of a number of opportunities. There is much more value in a BC program that is not limited to only mitigating loss.

Disaster Recovery

Distinguishing between Business Continuity and Disaster Recovery, then, is a dubious distinction. For historical reasons, because "disaster recovery" was usually associated with mainframes and data recovery in the good ol' days of information systems, we primarily use DR to refer to and label threats, targets and vulnerabilities specifically within the realm of IT. At best, Disaster Recovery is a sub-discipline of Business Continuity, and is only broken out due to the technical skill-set often required to perform adequate risk analysis and mitigation on IT infrastructure, systems and applications. But in the end, DR applies the same principles of Business Continuity.

Conclusion

As I mentioned at the top of this post, there is much disparity, even among professionals in the industry, in the use of specific terminology and how to apply it. And while I would prefer to see a universal adoption of standard terminology because I think it would help tremendously in communicating outside our industry, I also think it really only matters within an organization where it is important to define and delineate scope of responsibilities and identify goals and objectives of ERM, BCP and DRP programs.

So, what do you think? Are Business Continuity and Disaster Recovery the same, or related but significantly different or truly different disciplines altogether?

Image Credit: shawnzlea

10 Business Travel Hotel Safety Tips

2010-10-04T06:37:00.002-04:00

When traveling for business, we're often traveling alone. We're also often in a hurry to get from one place to the next. When it comes to the hotel, if you're like me, you are usually checking-in late at night and just want to get in your room and get some sleep before the busy agenda that awaits the following day. When our minds are racing or we're tired, we are especially vulnerable to making poor decisions regarding personal safety. Here are a few hotel safety tips:

When you arrive at the hotel, especially if you plan to come and go at night, find a parking space under a light.
If you can, avoid staying in a hotel room above the 6th floor. Though some newer fire trucks have ladders that can potentially reach the 9th or 10th, the reach is a function of how far the truck is from the building. Also, if trapped in your room and the window is the only means to escape, you might be forced to jump. And definitely stay above the ground floor, especially if there are sliding-glass doors.
When you get to your hotel room, unlock and open the door, but don't let it close behind you. Place your suitcase on the floor to prop it open while you check behind the doors, the bathroom, closets and curtains for anyone who might be waiting.
After inspecting the room, hold the door open all the way then let go. Does it close and latch on its own? Next, open the door only a few inches and let it go. Does it latch, or need a little push? You probably cannot get maintenance to do anything about it, but at least you'll be aware and not inadvertently leave your door open when you leave.
Walk the fire escape routes. Become familiar with where the stairwells are, both the closest and the second-closest, relative to your room and to the elevators. Remember that if there's smoke, you may not be able to see the emergency exit signs usually mounted near the ceiling. Be sure to walk the entire route down the hall, down the stairs and all the way out the door on the ground floor. Make a mental note of doors, turns and 'landmarks' along the way. If the alarms sound during your stay, absolutely do not try to use the elevator.
While in your room, lock all of the available locks.
If you have a safe in your room, make use of it. Put all your valuables you won't be carrying with you in the safe. Remember to keep your ID and passport on you at all times.
If you plan to use the breakfast menu (the one you hang on the door overnight), don't put your name or number of occupants on the form. Anyone walking by will know you're alone.
Unless you're staying for awhile and really need to, avoid using the dresser or desk drawers to store your items. Just keep your stuff in your suitcase. This will help avoid accidentally leaving anything in the room when you check out. Be particularly conscious of where you put any documents exposing your home address or other identifying information. Keep these things with you or well-hidden inside your luggage or safe away from prying eyes.
If possible, try to check-out and leave your hotel during daylight hours.

I recommend making yourself a checklist of these and other to-do's, printing it out, and carrying it along with your travel itinerary. Any other travel tips I missed? Travel horror stories? Love to hear about 'em...

Process Management Maturity and Disaster Recovery Capability

2010-10-02T08:45:00.002-04:00

Most companies start small. As they experience success, they grow. As they grow, their business gets more complicated. It's the second law of thermodynamics at work*.

As business needs change, this system responds with subtle changes to maintain equilibrium. And because this growth toward disorder is incremental, it's often not even recognized as a problem... until it has to be rebuilt from scratch in the aftermath of a disaster.

Systems Management Equilibrium

In the IT world, we've all seen the results. There's always that one business unit, perhaps through a previous acquisition, still using Lotus Notes when the rest of the company is using Exchange. Or there's that small R&D department still using an MS Access database to track test results when the company has long-since declared Access forbidden in favor of MS SQL Server for all critical databases.

Or, beyond non-conformance to standards, there's the "I have a problem to solve today" factor. At some point, the business had a legitimate problem. A solution was implemented to solve it. Later, another problem followed by yet another solution. Over time, you end up with a lot of solved problems, but a plethora of solutions that really don't work so well together. And that, at some point, becomes a problem in-itself. The solution: build interfaces and code snippets to make them all play nicely.

In the end, you have an environment that probably works pretty well. Day to day, things run relatively smoothly, and the staff know the landscape well enough to troubleshoot and resolve the small problems that arise. When one system is upgraded and no longer talks to the others, the developers know which export needs modified. No one even realizes what a management nightmare they have because, well, it's not. This system is near equilibrium... maximum entropy.

Systems, Processes and Disaster Recovery Capability

Industry-wide, it seems to me that managers and vendors are improving their mutual-understanding and use of terminology when it comes to "business continuity" versus "disaster recovery". Most use the former to refer to business process resumption and the latter to refer to IT systems, applications and data restoration. This is a meaningless distinction. IT systems are just automated business processes.

The problem is not systems and technology. You wouldn't, or shouldn't, have a piece of technology in place consuming dollars and staff resources if it's not there to support something of equal or greater value to the business. So while we are talking about managing the IT landscape, we're really talking about those business processes automated by technology and the meta-processes used to manage them.

Here is an axiom:

Resumption, restoration or recovery of any process implies that someone knows the required input, the expected output and the details of how the process transforms one to the other.

In business or IT environments where processes are undefined or loosely-defined and uncontrolled, environments that have reached equilibrium through incremental, ballistic change over time, the expectations and confidence in recovery capabilities are very, very low.

It's analogous to asking even the most accomplished engineer to re-build a previously-functioning Rube Goldberg machine with only the parts and a vague idea of what it's supposed to do.

The Next Step

Sometime soon, when things are calm and you have time to put your feet up on your desk and think strategically, do so and take a deep breath. Take a cold, hard look at your environment. Mentally walk through your support, implementation and service delivery processes and how things run day to day. Is it a convoluted mess of incremental solutions and ballistic processes? Is it a Rube Goldberg machine that only continues to work because you staff constantly tweaks little pieces here and there when it hiccups? Do you find a lot of ambiguity along the critical path?

If seriously considering business continuity and disaster recovery in this type of environment, throwing money at technology is surely to end in disappointment. One must absolutely address how business processes and process change are managed in the organization first.

*Footnote: I know this is an incorrect application of the Second Law of Thermodynamics. I use it with some poetic license only to illustrate the point.

Photo by Alex Garcia

Twas the Night Before Earl [Video]

2010-09-02T14:40:00.002-04:00

A quick video-blog entry, with some shots taken of the ocean at Croatan Beach as Hurricane Earl was approaching.

Business Continuity & IT as a 'Business within the Business'

2010-08-21T10:12:00.002-04:00

Though I am seeing this change slowly in organizations across industries, most companies still separate IT disaster recovery from business-side continuity and process resumption planning. As planners, and often the IT guys realize this too, it is incredibly difficult for IT to prioritize and determine the appropriate technology investments without knowing what is important to the business... and how important in terms of quantifiable dollars-at-risk data.

Unfortunately, even a lot of CIO's are only given financial information at a very high level, making it hard for them to provide cost-benefit analyses and ROI data for disaster recovery technology and services that make sense to the company's senior management.

Ideally, we would all like to see this change. We would like to see business continuity planners conduct thorough BIA's and provide IT with a prioritized list of applications and services and what availability and recovery capabilities are required for each. Because a lot of organizations, even in 2010, still have not embraced business continuity planning or have not integrated their BCM and DRP programs under a single umbrella, IT is left to guess and to deliver cost-effective disaster recovery solutions without the business impact information required to do so.

Knowing that we can't change the world all at once, and BCM/DRP programs mature at different rates in different organizations, I have an approach that I believe helps plan from an IT perspective... and lays the foundation for a mature and comprehensive program in the future. The trick is to look at the IT/IS department as a business within the business.

Even in organizations where IT is the business, there is a portion of IT that is a business-supporting or business-enabling function. This IT function includes those activities not directly tied to services provided to the company's customers (ie, not directly tied to generating revenue). For example, in non-IT companies, application hosting is a business-support function. The applications are required for the business to operate efficiently, but the company's customers often do not see/use these apps directly.

In tech companies that provide Software as a Service (SaaS), application hosting may very well be part of the service portfolio provided to the company's customers.

However, in both cases, IT does a lot more and provides a number of other services that support hosting applications. IT staff manage network connectivity, provide capacity planning, change and configuration management, provide moves, adds and changes on request, manage information security, technology vendors, software licensing, compliance and other service providers and provide support for the hosted applications, the entire infrastructure and even the desktops.

Despite this fact, I see senior management tasking IT with providing disaster recovery for mission-critical applications, and IT then building out infrastructure solutions and recovery plans starting at the application level. They start by asking the question, "How can we recover this application and restore the data within the timeframe allotted to us by the business?" This is definitely a challenge... because this is not the right question... not yet anyway.

What I suggest is that one look at IT as a stand-alone service provider and conduct an IT-specific BIA from this perspective. Look at IT as a separate business with its own customers, suppliers, revenue and expenses. Identify your 'revenue generating services'; those services you provide directly to your customers (ie, the rest of the company) and separate those from the back-end services you provide to support your 'revenue generating activities'.

With this in mind, you can begin building your IT business continuity plan and program with a focus on improving the IT organization's ability to continue providing services to your customers. This will drive you to identify and prioritize not just the core infrastructure requirements for hosting applications, but also the management tools, crisis response and management plans and other non-technical processes needed.

In a disaster event, your recovery will first focus on recovering these core infrastructure components, services and management processes... and only then can you even think about recovering customer's applications.

Keep in mind, as it is often missed when planning recovery from the application level, that core infrastructure and IT process recovery times have to be figured into application RTO's. This means, then, that every core infrastructure component necessarily has a much lower RTO than any of the company's most critical applications.

Mint vs Yodlee vs Quicken

2010-08-10T20:42:00.002-04:00

Over the weekend, due to compelling reasons I'll get to later, I took a deep-dive into the two most popular online "Banking 2.0" products: Yodlee and Mint. My overall impression: These guys really have a long way to go.

This isn't really a review of either. Instead, it's more of a wish-list... for what I wish either Yodlee or Mint were, but alas, they are not.

First, I admit it. I love Quicken. I've used some version of Quicken's desktop product since I migrated from MS Money in 2002. Well, actually, when I went anti-Windows and switched to FreeBSD in 2004, I couldn't get Quicken to work with Wine and gave GNUCash a whirl for a few months.Â But eventually I returned to my beloved financial management software (the only reason I returned to Windows). I currently use Quicken 2008 Home and Business.

And my wife, well, she's a financial analyst. She likes crunching numbers more than shopping for shoes, if you can believe it. (Ok, that's probably stretching it a bit.)

My point is that we're not just managing our weekly allowances here. We're serious about our finances and our financial futures.

What do we like about Quicken?

While we have a lot of gripes with Quicken that I won't go into, none of them prevent us from getting the job done. Sometimes we just have to be creative or work a bit harder to understand how Quicken works.

For starters, we love the automated account aggregation features. We've gone so far as to move nearly all of our accounts to banks that support updating via Quicken's OneStep Update feature because it saves so much time in reconciling accounts, analyzing our 401k's, IRA's and brokerage accounts and tracking loan and credit card balances.

We also love the ability to categorize transactions and then tag categories to specific tax line-items. Though I use QuickBooks for my business accounting, we both incur a not-insignificant amount of unreimbursed work-related expenses. We also donate to charity, have capital gains, have healthcare-related expenses, student loans and mortgage interest. While tax time is never 'a breeze', it certainly isn't the nightmare it would be without Quicken.

Finally, we love Quicken's reporting. We use the custom reporting features extensively to drill down and better understand every aspect of our spending and our investments, to compare to previous periods and to ensure that we're always improving our situation.Â We don't have to experiment or guess.

So why would I want to move away from Quicken?

Perhaps my wife and I are peculiar in this respect, or perhaps not. We each have our own computers for normal, day-to-day use and we share an old laptop for our "family" activities. Turns out the only thing installed on said laptop is Quicken.

Ideally, we'd both love to have access to our Quicken data from our own machines, with the data itself stored on our shared file-server. I know there are convoluted or 3rd-party ways to make this happen, but the fact is that Quicken is not designed to run this way. All of the work-arounds have some limitation we're unwilling to accept or risk we're unwilling to take.

And, just recently, I found out that I'm going to be traveling extensively. Though we share the laptop with Quicken installed, we each take responsibility for updating our individual accounts, categorizing transactions and making manual entries when required. As I anticipate being on the road for weeks and possibly months at a time, I feel horrible about making my wife take care of all of our finances alone.

Wouldn't it be great if Quicken existed 'in the cloud'?

My wife initially suggested that I install some Remote Desktop application so that I could access the shared laptop over the internet and keep my accounts up-to-date. To me, that seemed really cludgy and so 2004. I asked her to give me some time to investigate our online options as I was sure there was a solution out there. Here's what I found:

Aggregation

Both Yodlee and Mint offer the account aggregation features that Quicken does... but not as nicely. For example, let's say you make a transfer from a savings account to a checking account. Quicken, Yodlee and Mint will all download the transfer transaction from the banks for both accounts.

But Quicken goes one step further and, while the transfer shows in both accounts, it considers the transfer a single transaction. You can tag it, classify it, add a memo to it, change the description or whatever, and the changes show up in both accounts. In Yodlee and Mint, these are separate transactions and to get the reporting to work correctly, you have to edit the transaction twice, once for each account.

Budgeting

Both Yodlee and Mint offer budgeting features, if you want to call it that. What they really offer is the ability to set a monthly goal for each expense category, let you report on how your actual spending compares to your budget and can alert you when a category is getting close to going over your goal. It's the old 'envelope budget' method I suppose.

Perhaps this is enough for someone in high school managing their income from their part-time job at the local cinema. Adults are more sophisticated and require more sophisticated budgeting and forecasting tools. Both Yodlee and Mint fail miserably in this area.

Taxes

Yodlee and Mint both have, for individual transactions, a checkbox to identify that transaction as "tax related". I am at a complete loss as to how this could be helpful to anyone.

Hopefully Mint, being owned by Inuit (the guys who make Quicken and TurboTax) will come up with some tighter tax integration features... and preferably let customers tag categories to specific tax line-items like Quicken does today.

Accessibility

Both Yodlee and Mint have one up on Quicken. They are accessible anytime and from anywhere you have a web browser and internet connection... including your mobile phone. Our instance of Quicken sits securely on a laptop and is accessible only from that laptop. And while I could go through the trouble of setting up a VPN tunnel... well, that's a lot of trouble. The Remote Desktop solution is, unfortunately, the only solution I see as viable.

Conclusion

As I mentioned before, if you're managing your income from a part-time job or managing your weekly allowance from your parents, the 'snapshot' view of your transactions provided by the likes of Yodlee and Mint might be sufficient. But it's exactly that... a snapshot view. Neither Yodlee nor Mint allow for managing your finances.

And while Quicken does nearly everything very well, the fact that it is a desktop app is severely limiting to those of us who 'tele-home' (my newly-coined term for those of us who have to spend significant amounts of time away from home, yet still want to feel a part of it).

People Like You: CERT Community Emergency Response Team [VIDEO]

2010-07-14T08:22:00.002-04:00

Here is an excellent Public Service Announcement regarding Community Emergency Response Team (CERT) training.

People tend to forget, or are just not aware, that they are overly-dependent on emergency management services (EMS) and rescue workers to come to their aid in a disaster.

In a regional crisis such as a hurricane, earthquake or wide-spread flooding, resources will be limited. Individuals and families should be prepared to take care of themselves for 48 to 72 hours.

Disaster Recovery Test Results and What to Do With Them

2010-06-28T12:46:00.002-04:00

Early in my career, I worked in a manufacturing environment. And though we were not yet a disciplined SixSigma shop, we were obligated by customer requirements to conduct, on a monthly basis, 7-Step Root Cause Analysis on the top 10 issues causing downtime or product defects on our assembly lines.

I learned two important things from this process that I believe applies to business continuity and disaster recovery exercises and testing.

First, what appears to be the cause of a failure on the surface rarely is. Second, even if we identify the true root cause of a failure, if we don't take measures to remedy that root cause, the entire process is a waste.

Something I learned long ago from Stephen R. Covey is to "begin with the end in mind." This is applicable to testing in that before we even begin to design a test or exercise, we should know what kind of results we expect, how we are going to measure them and what we're going to do with them afterward. This can be accomplished through Root Cause Analysis. Having a root cause analysis process in place will make designing and conducting tests and exercises much more effective.

Different organizations have developed a number of root cause analysis methodologies that meet their own specific needs. Particularly in manufacturing, where numerous tiers exist in the supply chain, it makes sense for those at the top to develop standards and pass those down the line to ensure some consistency in monitoring, reporting and controlling defects.

With respect to using a formal process for BC/DR testing, unless your company is in a regulated industry or is at the top of a supply chain where some vendors are extremely critical, I recommend taking time to understand the fundamental concepts of root cause analysis and then modify the steps to fit your own company culture and existing processes.

Root Cause Analysis and DMAIC

My experience tells me the best starting point for ensuring test results find their way back into making the plan better is the DMAIC process.

D: Define
M: Measure
A: Analyze
I: Improve
C: Control

Each one of these words/concepts/phases in root cause analysis is a separate discipline in itself, and each one is key. Don't skip steps!

Defining the Problem

Much of the time, especially when in meetings and brainstorming, we have a tendency to jump right to throwing out solutions to problems before we really understand what the problem is. It is imperative at this stage to focus specifically on defining the issue. And we define it objectively, without placing blame. Further, we want to, as best we can, define it in quantitative terms so that we can measure the extent of the problem.

Finally, it's important to focus on the scope of the problem, identify what other systems or processes are impacted and which are not.

The final step, or it could be first, is to designate a problem owner and stakeholders. Just like managing a project, the process is much more effective with a single champion who is accountable for solving the problem.

Measuring the Problem

If we have defined the problem well, the results should be predictable and repeatable, and therefore measurable. In BC/DR we may measure business process resumption simply with a pass/fail, worked/didn't work metric, or we may measure customer calls missed or revenue lost of the data is available. If we're talking about data and IT, we may measure the number of accounts affected, users impacted, records recovered versus lost or measure time relative to RTO's and RPO's.

Again, the trick in defining and measuring the problem is to narrow the problem down to a point where we can measure the extent to which the problem impacts recovery efforts so that we can, in turn, measure the extent corrective actions actually improve those efforts.

Analyzing the Problem

Now, for the first time, we get to try and figure out what's causing the problem. There are several different methods to do this, from simple brainstorming to drawing diagrams. I like the 5 Why's approach because most organizations are not using statistical process control on BC/DR planning and trying to is probably overkill. The 5 Why's approach is simple and it generally works.

The idea behind 5 Why's is just asking Why? through five iterations. Start with "Why did we have this problem?" (referring to the problem identified earlier). Here's an example:

1. Why did we have the problem?
A. Because the DR plan was not up-to-date.

2. Why was the DR plan not up-to-date?
A. Because Joe didn't update it.

3. Why didn't Joe update it?
A. Because he was busy with other priorities.

4. Why does Joe have other priorities over updating his DR plan?
A. Because his performance metrics are based on activities not related to his DR plan.

5. Why are performance metrics not tied to DR planning?
A. We don't have a policy in-place that tells managers to hold employees accountable for the DR-related activites.

Ok, so you see how it works. The problem might be related to the plan not being up-to-date, but by drilling down we can see there is a deeper root cause. And what we typically find is that this root cause is not just the cause of this single failure, but is generally a fundamental failure with the potential to impact other areas, processes or systems.

Improving the Situation

Sometimes the Analysis phase will point very closely to a good solution. But even so, it's good to brainstorm and work out the details of several options. For each, understand the time required and conduct a cost/benefit analysis.

Also evaluate each proposal to ensure that implementing a particular solution does not break or cause problems elsewhere. Especially when we are talking about systems and applications, changes can have significant impact and should be passed through a formal change control process (a subject for another time).

The final component of Improvement goes back to the metrics identified in the Measure phase. Know ahead of time how and to what extent the improvement is expected to address the problem. This will be important in future testing to ensure the improvement was implemented correctly and yielded the expected positive results.

Once the best solution is selected, depending on the size and scale, it should be implemented either through a simple Corrective Action process or, if needed, a separate, stand-alone project.

Control

Even if we implement the right solution to the true root cause of a problem, if we neglect it over time, the problems resurface. Hence, especially in BC/DR where many of our solutions are going to be based on changes to processes, the organization needs a mechanism to verify that the process remains under control. This frequently takes the form of an internal process audit.

In designing our improvement, then, implementing the solution is not enough on its own. We need to additionally define how we will continuously measure the process going forward and verify that the solution continues to prevent the original problem or reduces the frequency of occurrence.

Conclusion

In business continuity and disaster recovery testing, many organizations take the findings and results from tests and exercises and fix the immediate issues without addressing the root cause. Doing so means the organization continues to face many of the same related issues repeatedly. Incorporating a semi-formal root cause analysis process following each test, and for each problem identified, can result in better and more reliable plans, and a more efficient and cost-effective test and exercise program.

The Importance of Reading Instructions

2010-06-26T20:14:00.002-04:00

I've always been the type to read the instructions... on nearly everything.

When I was a kid, I loved putting together plastic models of cars and airplanes. The process always went smoothly because I read the directions first.

I always first read how the Transformer was to transform from robot to car and back again while my little brother broke his trying to figure it out.

As I grew older, I learned the value of changing my own oil (well, not MY oil, but the oil in my car), replacing brake pads, belts and spark plugs. It turns out most automotive maintenance is fairly simple... if you read the instructions.

And when it came to assembling Sauder furniture, I was a pro... because I always read the instructions.

When I bought my first house, I did so with the intention of becoming a DIY 'weekend warrior'. I was amazed that I was able to, with no prior experience, wire electrical outlets, hang and finish drywall, lay hardwood flooring and even build a bar... all by just reading the instructions!

Now that I'm married, I cook frequently. For most of my life I was intimidated by the thought of cooking because I've eaten good stuff and bad. I always thought it was a tremendously difficult skill that took years of training, trial and error... and not everyone gets it. One day, to surprise my wife, I downloaded a simple apricot pork chop recipe I found on the internet. I read it thoroughly, bought the ingredients, followed the directions and it turned out fantastic!

Time and time again, I've learned that I don't have to re-invent. While of course there are some things that one just has to learn by him/herself, there are many things that mankind, as a collective, has learned and documented.

In general, this axiom has proven true: if someone has taken the time to write instructions for completing a task that you're about to do, and you have access to those instructions... you should take the time to read through them prior to undertaking the task. Even if you don't follow those directions to the T, knowing where you're going to end up and how you're supposed to get there is tremendously valuable in saving time, effort and frustration.

I wish I had considered all of the above before tonight, when I proceeded to make some really simple macaroons. I read through the list of ingredients, whisked them up in the bowl, spooned them onto the cookie sheet and, only when I checked again to see the recommended oven temperature, did I finish reading the procedure. I really should have whipped the egg whites and folded in the coconut and sugar.

My macaroons turned out exactly unlike anything edible.

Lesson learned.

Twitter, Facebook and LinkedIn: Syndication and Respecting SocialNetwork Cultures

2010-06-24T06:28:00.002-04:00

Or: How to NOT Alienate Your Friends and Contacts

I saw today that Twitter is releasing a new service/app that provides another level of integration with competing-yet-complimentary social networks.

The articles tout the ability to cross-post (aka, "syndicate") from Twitter to both Facebook and LinkedIn. For those of us using all three services daily, we know that's been around awhile. Nothing new there.

The real treat is that now Twitter will allow you to quickly find and follow your friends on Facebook and connections on LinkedIn that also have Twitter accounts.

I actually found this by accident on LinkedIn the other day and it's quite awesome. I tried last night to attach to Facebook with no success due to technical issues on Facebook's side. The latest update says Facebook has blocked the application.

But with great power comes great responsibility.
I've seen it happen, and I think we need to get the word out. It seems to me that social media/networking experts, small business and techies are likely the only people really using all three networks. Most other people are primarily using one or two and have little knowledge of the third. For example, the stay-at-home mom talking about her soaps knows about Twitter and Facebook with no understanding of LinkedIn. The CIO of a Fortune 1000 company is on LinkedIn for business, Facebook for personal (maybe) but has not felt compelled to learn much about Twitter.

In the end, I think these new features are going to cause significant alienation if care isn't taken to understand the respective 'culture' of each social network.

So, for those using, or planning to use, these features and cross-post from Twitter to Facebook or LinkedIn, here is some info you might find helpful.

Twitter

To be blunt about it, Twitter is a narcissistic social media platform where everyone blasts their information into the ether to be picked up by anyone and everyone who is listening. To listen, just go to their profile page and read their posts. If you kinda' like them and would like a shortcut, create a list, add them to it and periodically take a look at that list to read through the latest updates. If you really want to see everything they have to say when they say it, you can "follow" them. This effectively puts their broadcasts into your inbound stream.

There isn't really a single 'culture' on Twitter. People talk about all sorts of things. Some people tweet a message less than once a week, and others tweet more than 50 messages per day. Some people just tweet motivational quotes, others just re-tweet those people and some people actually reply to posts and try to interact on a more personal level. The cool thing about Twitter is that anything goes and there are no real rules.

It's common for Twitter users to follow hundreds, if not thousands, of other users. This can be overwhelming to new users as Twitter lacks any built-in filtering or prioritizing functionality beyond the 'list' feature. It's also common for individuals to duplicate their own posts throughout the day or week, as it's understood that most people aren't going to read every post in their stream since their last sign-on.

Facebook

I probably don't have to say much about Facebook. It's different than Twitter in that, while you could potentially broadcast to the world, most people I know connect with others they actually know, either friend, family or business contacts. Additionally, businesses are establishing a presence on Facebook to interact with customers, but that's a different animal.

From an individual's perspective, the big difference between Facebook and Twitter is that Facebook is locked down just a bit more, which gives people a more personal experience when interacting with their 'friends'. And since Facebook 'friends' tend to have some relationship outside of Facebook, most shy away from alienating each other with 50 posts per day advertising their small business or forwarding tons of work-related links. Instead, posts often tend to be more of a personal nature compared to Twitter. For most people, it's a great platform to connect, reconnect and stay connected with friends, family members and colleagues.

It also seems that Facebook recognized the lack of filtering issues with Twitter and incorporated a solution into their newsfeed interface. Though many people don't like it and they see it as Facebook determining what news is important, it works well for those with a lot of friends by highlighting more popular items and filtering the rest.

LinkedIn

If you're not familiar with LinkedIn, it's a social network, but with a culture completely different than that of Twitter and Facebook. While there are always exceptions, LinkedIn is for professional networking, making business-related connections and building professional relationships. While "open networkers" violate the rule, the premise behind what makes LinkedIn valuable is that you actually have a solid business relationship with each of your connections such that you can and are willing to make referrals, offer recommendations and connect others.

It's been my impression and experience that people are not using LinkedIn to find out about movie reviews, local bands, discuss politics, religion or share recipes. People on LinkedIn are there to build relationships, grow their business or advance their careers.

For a while now, LinkedIn has had a 'status update' feature that allows users to post a short message. It used to ask "What are you working on?", prompting users to stick to business, work, career-related topics. Today, the homepage, by default, shows the last three updates in your network. You can then click the "more" link to see the latest 8-10 or so.

So What About the Cross-Posting, Already...

Yeah. With Twitters ability to cross-post, the potential to alienate your friends and business contacts is a very real one. On Twitter, people follow and unfollow others for a myriad of reasons and the advice to individuals is to not take it personally when someone stops following you. However, for most people, our Facebook friends and LinkedIn contacts are too valuable and we want to encourage relationships, not drive people away.

In terms of post quantity vs quality, I think of it like this:

Twitter: High Quantity / Quality varies and no one cares
Facebook: Medium Quantity / Quality will vary, appropriate to your specific audience/friends
LinkedIn: Low Quantity / High Quality to project the best professional image of yourself and your company

Strategically, it boils down to:

Twitter: Use it for self-promotion, but, since it's 100% public, make sure you are filtering your own posts and not getting too personal. Provide information that's helpful and relevant to your target audience.
Facebook: Keep in touch with friends and family, but keep in mind that you probably have business contacts too. Use FB's new privacy features to filter overly-personal or risque updates to only the people you really want to see it.
LinkedIn: Use the status updates feature sparingly to establish yourself as an expert in your field, a professional, and to stay "BOB & TOM" ("Best of Breed" and "Top of Mind"). Since your connections only see the last 8-10 updates from all their contacts, too many irrelevant updates from one individual fills this up quickly and, as a result, quickly becomes annoying.

Solutions?

Fortunately, both there are solutions available for both Facebook and LinkedIn to help the situation and make syndicating tweets more appropriate to these other network cultures.

For Facebook, check out Selective Tweets. It connects Facebook and Twitter accounts and allows you to cross-post, but further allows you to filter what you tweet. You can end your tweets with the #fb hashtag and ONLY those tweets will show up on Facebook.

LinkedIn's Twitter app has similar functionality. Once installed, go to the Settings tab and enable the selective tweets option. Use the #in hashtag when you want a tweet to also appear on your LinkedIn status.

Using these features allows you to tweet all you want, and selectively cross-post/syndicate only the relevant tweets to the appropriate network. Hence, it prevents you from flooding your Facebook friends or LinkedIn connections with all of your irrelevant tweets so you don't violate the network's established culture and risk alienating your friends and professional connections.

Twitter for Emergency Management & Crisis Communications

2010-06-14T09:49:00.002-04:00

In December 2009, my friend Mike Ellis (@EmergCommNetwrk, website) posted an excerpt of Mark Prutsalis' (@LivingPrepared, website) August 13, 2009 article Use of Twitter as an Emergency Notification Service. Both became relevant this past week when Twitter experienced serious outage issues making its site inaccessible and API unavailable.

In the article, Mark argues that government agencies should not use Twitter as an emergency notification service. His points are valid and applicable to private sector businesses and non-profit organizations as well.

Mark, prophetically, highlights two basic concerns:

Twitter is down frequently for a myriad of reasons, and seems particularly sensitive to capacity issues especially during high-profile, highly visible disasters and incidents, and
Twitter has not yet fully implemented a means to validate user accounts, which diminishes the reliability of information dispersed.

Both of these concerns, fulfilling Mark's prophecy, presented themselves beautifully in the last few weeks; most notably the above-mentioned outages and intense public out-cry over the Gulf Oil Spill (#oilspill). Political pundits used Twitter to blast their competing parties, Gulf-area locals brought minute-by-minute updates of their experiences and BP, already suffering and PR nightmare via normal media outlets, had to contend with a fake Twitter account, @BPGlobalPR (article). This account, that early on many believed to be the official mouthpiece of the oil giant, continues to spout inaccuracies and make outrageous, politically-motivated, reputation-damaging claims.

To be fair, BP's real Twitter account is @BP_America.

It is important to distinguish between two different, yet relevant and interrelated, concepts: emergency communications and crisis communications. The former deals specifically with dispersing critical information to affected parties and/or to response and relief personnel in the field. The latter, as a sub-specialty of public relations, deals with protecting public perception of an organization and to defend its reputation.

Participating in the live reporting and re-tweeting of event information does not make the social network expert in emergency and disaster management.

- Mark Prutsalis

While Mark's argument deals specifically with government agencies and emergency management, the BP fiasco demonstrates how Twitter's shortcomings should make private-sector organizations think twice about using social media for emergency notifications and communications. It should further highlight the need for addressing, in a formal crisis management strategy developed long before it's needed, if and how social media will be used as a crisis management and communications tool.

Twitter apologists and social media marketing experts argue that no one is urging companies to use Twitter exclusively, but only to integrate it into their crisis communications along with other tools and services. To some extent, this is true. However, rather than promoting its use, the crisis management plan should specifically detail how Twitter and other social networking platforms will be used and, more importantly, NOT used during an incident. For example, Twitter should not be relied upon to deliver authoritative quotations or official comments, but instead point to and promote an official website where the reader can find press releases, status updates and other relevant information. Even so, there is a danger of the public becoming overly dependent on Twitter status updates for these links. Hence, it is important to integrate social media to supplement the organization's overall communications strategy, not to replace it nor even as a critical component.

Marketing, in general, and crises, specifically, require control of 'the message'. Unfortunately for most organizations in today's connected world, as we saw recently with Tiger Woods, Toyota and BP, controlling that message is not easy. Gaining control of that message after-the-fact is nearly impossible. Organizations must take steps today to develop their emergency and crisis management strategies and to clarify internally and to their customers how official information will be distributed. And while Twitter may have a role in some organizations' strategies, it should be limited to supplementing other methods and delivery mediums over which the organization has control.

Disaster Recovery: Tests vs Exercises vs Practice

2010-06-03T13:47:00.002-04:00

I believe a lot of managers and board members hold a number of misconceptions regarding business continuity and disaster recovery testing and exercises.

Over the years, I've heard many argue about what makes a test successful or not, and how to best present test results relative to business objectives when management, auditors and regulators are pushing for 'successful tests'. I know of several large organizations that base employee performance evaluations, at least partially, on the outcomes of disaster recovery tests.

I think much of the confusion comes from the very sloppy way we, as practitioners, use terminology that has meaning in common speech outside our specialty. The following describes how I distinguish testing, exercises and practice, and will hopefully serve to help others in the field to explain the differences and how success and failure in each can mean very different things for the organization.

Tests

One activity that takes place in organizations involves validating that a proposed recovery or business resumption process works under ideal circumstances. This can take the form of working from a "plan" or, although discouraged, letting an employee do what he knows how to do without any documented guidance. The key here is that at this stage, the recovery process is somewhat experimental and untried.

Validating whether the process works can be accurately described as a 'test'. The result is usually a pass or fail outcome, as it either works or it doesn't. And I stress that tests are performed under ideal (or at least consistent) circumstances, because test results in a controlled environment should always be repeatable.

Exercises

Another activity that businesses should undertake, though few actually do, is the exercise. As an analogy, consider the body builder. A body builder knows and can successfully perform his routines with proper form. But simply going through the motions is not what gives the body builder his size or strength. To grow and improve, the body builder must push his body to its limits by constantly increasing the difficulty or intensity of his program. Frequently, he 'lifts to failure', meaning he lifts very heavy weight enough times in a single set that he just cannot lift any more.

The same concept applies to disaster recovery planning. Once the recovery process is tested and proven to work under ideal circumstances, organizations must increase the intensity of their program to keep it strong and continuing to grow stronger. Increasing intensity involves introducing variables into an exercise scenario that requires participants to think a bit outside the plan, executing recovery under other-than-ideal circumstances. By making each exercise more demanding than the last and exercising 'to failure', the organization grows more resilient in the face of a broader range of disaster sources and scales of business disruptions.

Practice

The last activity I want to address that occurs most frequently and is incorrectly called a 'test' is practice. To use another sports analogy, imagine a little league baseball player. At some point in his short baseball career he was given training in the basic mechanics of how to swing the bat to hit the ball. Through trial and error and 'testing' various grips and postures he learned the most effective way to do so. Later, to improve and expand his abilities, he 'exercised' his batting technique by introducing variation in pitches and learned how to hit an in-field grounder versus a pop-fly. And while there is a very fuzzy line between training, testing and exercise, the player does not neglect going back and practicing the fundamentals of simply hitting the ball.

In disaster recovery, just as in baseball, to repeat the same process over and over to get better and more comfortable with it is 'practice'. Practice should nearly always result in successful execution, but can perhaps be graded on a scale of success. In my experience, due to the demand for successful test execution, organizations often conduct 'practice', call it a test and present those successful 'test' results to management and stakeholders. However, if an organization is only practicing execution of their plans, and they are nearly always successful in doing so, that organization is sure to have developed a false sense of security in their apparent ability to recover while not prepared to manage through the variables that will inevitably occur during a real incident.

Conclusion

A business continuity / disaster recovery test and exercise program must consist of all three of these components. Further, objectives for each type will be different and must be defined within the overall program.

The objective of a 'test' is to validate that the basic, fundamental process actually works under ideal circumstances. The test fails if the process does not work and a new process should be developed.

The objective of 'practice' is continuous improvement. Practice should always result in successful execution, though it could be along a spectrum of success based on how a particular organization measures it. For example, recovering faster (closer to meeting RTO's) may indicate a higher level of success. Failure during practice would indicate something significant was missed during testing and require revisiting the recovery process.

The objective of an 'exercise' is to evaluate the limits of the recovery process and the people involved. In an exercise, people and processes are pushed to failure. Not successfully executing during an exercise does not necessarily imply failure, and should in fact be anticipated. An exercise as a whole, even if recovery failed, can be successful if information is obtained, lessons are learned and corrective actions are taken to improve performance next time.

---------

Disagree or have something to add? Comments are certainly welcome!

Leading through a Crisis vs 'Damage Control'

2010-05-01T07:05:00.002-04:00

Among an organization's most important and valuable assets is its reputation.

This applies equally to companies, departments and even project teams. Business continuity and disaster recovery planning is not just about mitigating loss and improving up-time, availability and maintaining customer service through an outage. It's not just about getting 'back to normal'. It's also not just about 'learning from the experience' to avoid the disaster or better-managing a similar event in the future.

No. The real value of planning ahead is in knowing how you are going to use the next unavoidable disaster or crisis to your advantage.

Beyond reaction and response, beyond triage or 'putting out the fire' and beyond minimizing the impact to the organization's reputation, leaders need to know how they will use a crisis to improve their reputation and enhance their standing in the eyes of the consumer, the user community or their B2B customers. If planned for properly, any crisis can be an opportunity for your team, department or company to grow your audience or your market and increase their level of confidence in you.

From the perspective of internal IT departments, it's a similar situation. From both upper management and the user community there is an unrealistic expectation of perfection: zero defects, zero downtime, zero risk... that forces IT architects and management to focus on avoiding those situations that might trigger interruptions. But there should be at least as much thought and effort put into how one will lead through a crisis, because it will happen eventually, regardless of the latest data protection or high-availability solution.

When faced with your next crisis, will you be a leader in the eyes of your customers or will you be apologizing, begging forgiveness and simply doing damage control?

UPDATE 6/15/2010: Here is a great article, How To Use Twitter to Avoid a Online Reputation Disaster, that discusses how to proactively use Twitter to catch smoldering issues before they become crises... and make your org look good in the process.

LinkedIn Q&A: Business Continuity & 100% IT Availability?

2010-04-28T13:30:00.002-04:00

Click here to read the entire thread on LinkedIn.

The following question was posted earlier today on LinkedIn:

how do you think this statement "I intends to have an IT business continuity plan that ensures 100% availability of organisational IT at all times"?

Continue reading to see my response (and please forgive my typo)

Another perspective to consider is: Are you talking about infrastructure and applications availability or IT service availability? In other words, are you referring only to the technical components or will you include in your 'guarantee' change, release and configuration management, support services, security management, etc?

I think a lot of times we tend to forget that a lot of the value and benefits organzitions realize from a solid IT function is not just the technology and systems, but also the processes and procedures that go into day-to-day support and management of those systems.

Also, I believe that in today's world of 'zero defect' and 'zero downtime', there is an unrealistic expectation of perfection that forces IT managers to focus on avoiding risks and outages instead of dealing with them and planning to manage through them. Your intention to ensure 100% availability is a good example.

IT managers should be pushing back some and instead of working toward 100% availability, should work toward 'predictable availability' where downtime (+ manual work-arounds) is associated with a cost and initiatives toward reducing downtime lower that cost.

Iceland Volcano Footage [Video]

2010-04-16T09:47:00.002-04:00

I found some really spectacular live footage of the volcano eruption in Iceland that is wreaking havoc with flights across Europe. The disruption to air service is not just an inconvenience for the airlines. The impact extends to business travelers who need to meet clients and make sales, shipment of critically important parcels, emergency supplies and organs for transplant.

This is a textbook case demonstrating how the impact of many disasters often isn't felt immediately, and there is little anyone can do to avoid the impact altogether. Instead, the impact grows exponentially over time and organizations need to prepare alternate means of achieving their most important, day-to-day objectives.

Letting Software Dictate Your Business Continuity Program?

2010-03-17T11:19:00.002-04:00

Years ago, in a conversation about ERP systems with the president of a Tier 1 automotive supplier, he said something that will forever stay with me.

We were talking about whether we (the company) should retire our legacy system in favor of SAP. He said that if he really had his choice, we should develop our own solution in-house. Puzzled, I pushed further and asked him what would drive him to reach such a conclusion with SAP, Oracle, our legacy product and a number of other industry-specific solutions available. He responded that he doesn't want to change the way he manages the business to make it fit with some off-the-shelf application according to how some software developer or any other company thinks his business should be managed.

He went on to tell me that too many people buy software under the impression that the software is going to make life better. They waste a lot of time listening to salespeople talk about various products, capabilities and features. In the end, they spend too much money on a product full of features they don't need and will never use and spend too much time re-engineering their existing processes to accommodate the software's interface, reporting capabilities or other limitations. Then he pointed out that a number of companies have been driven close to bankruptcy as a result of failed SAP and other ERP solution implementations.

What does this have to do with Business Continuity? Well, for now let's neglect the increased risk exposure due to ERP implementations and instead let's look at Business Continuity Management software. We've got LDRPS, eBRP, MyCOOP and I'm sure plenty of others. What do these have in common? They have in common with each other the exact same issues they have in common with SAP, Oracle and other ERP systems. While they are customizable to some extent, there is a management and planning methodology built-in. To get the most out of the software, you have to re-engineer your management processes to fit.

At first glance one might think that re-engineering the process to fit an industry standard is a good thing. Well, let me tell you that industry standards and best practices are guidelines. They are a starting point. They're not prescriptive, especially not for a mature program, and should not be read or used as such. Off-the-shelf BCM software is designed to appeal to and fit into, I estimate, 70-80% of the developer's market. And for those, it only fits 50-60%. Everything else the customer does has to be changed to fit the software or they have to opt out of using that feature.

So while none of the mentioned (and unmentioned, for that matter) BCM solutions are bad, the decision to purchase and implement any solution should be made with the understanding that software is, in fact, rarely a solution-in-itself. Calling niche software a solution is a misnomer. The software is, instead, a tool to help achieve a solution. It is therefore imperative to have your own measurable objectives identified and processes clearly understood, optimized and documented. Then, when looking at software, do not make adjustments to your objectives and performance metrics, and only consider adjusting your processes where the tool you're investigating provides an opportunity for automating something manual or gaining some other efficiency.

Don't let software dictate to you how to run your business continuity program.

Conducting a Simple Risk Assessment

2010-02-08T19:00:00.002-05:00

If you have never put much thought into managing risk in your organization, a risk assessment is the place to start. It can be an eye-opener for a number of reasons. First, you'll quickly see that no risk management methodology is going to allow your organization to avoid all potential loss. Second, if you have never done an assessment before, you may be shocked to find just how many threats exist to your organization and how vulnerable you are. Third, you may be equally surprised to find that there are likely several actions you can take in the near term, with little or no cash investment, to mitigate some of that downside risk.

So what is risk? Generally, we think of risk as a threat or vulnerability that could lead to potential loss. However, especially from a business perspective, it is important to keep in mind that risk refers to variance from the plan. That variance can be bad and lead to loss, but can also be good and lead to something positive. There are a few caveats before we get into the risk assessment. First, though this is a simple exercise that serves as a starting point, it is not a replacement for a comprehensive risk analysis or risk management program. This risk assessment method is purely qualitative, meaning we're not going to use any real budget numbers, loss estimates or historical statistics. Hence, your mileage may vary.

Second, this exercise will show you how easy it is to fall into "analysis paralysis". There is a point of diminishing returns when it comes to creating your first list of risks. Your list is ever-changing and growing. So keep in mind that, initially, we are going after the low-hanging fruit. Having an exhaustive list is unnecessary right now.

Step 1: Identifying Risks

Open a new Excel spreadsheet and start listing the threats to your organization. Don't worry about how big or small they are, nor how likely. We will get to that later. The first items you think of are probably going to be from the category I call "Natural Disasters/Man-Made Hazards". This would include things like fires, power outages, blizzards, tornadoes, hurricanes, floods, etc. In case you get hung-up on these, you can visit this list of categories I use to get your mind thinking about other business risks. Make sure you're thinking not just about physical threats to your facilities, but also threats that impact cash flow, your ability to make your product or perform your services, your ability to process and deposit receivables and pay bills on time and those things that might expose your company to costly litigation.

Again, don't worry about building an exhaustive list. You can always add to it later.

Step 2: Impact Assessment

With your spreadsheet open to your list, add a second column. To keep it simple, using a scale of 1 to 5, enter an impact value for each threat. Let 1 be the least impact and 5 be the most. For now, consider the worst case. So if "tornado" is on your list, consider the impact a worst-case tornado will have on your business. Keep in mind that this is a relative scale. The impact value you assign for any threat is relative to the other threats on your list.

Step 3: Probability Assessment

Now, add a third column. Using a 1 to 5 scale, determine the probability of that threat occurring, where 1 is negligible and 5 is very likely. This is going to be subjective. Again, consider the threats relative to the others.

Step 4: Prioritize

This is the easy part. Just multiply the impact by the probability of occurrence to get a "risk factor". Then sort your list with the highest-impact, most-likely-to-occur threats at the top.

Step 5: Plan

From your prioritized list, take the top 5. For each of those, ask yourself, "What can I do to either reduce the impact or reduce the probability?" I'll give you a hint: for big events like natural disasters, you're looking at business continuity planning coupled with insurance. If all of your top 5 are natural disasters, go to the next 5. You might find things like "New competition entering the market" or "Critical supplier fails to deliver raw materials". If these are near the top of the list, you should start thinking about how your business is going to respond when that happens.

Identifying Opportunities

Now to turn the tables just a bit, go back to your list of threats. For many items this likely won't make sense, but for those that do, consider the opposite of that threat. Go through the same process for each, identifying the positive impact the event might have on your business and the probability of the best-case occurring. Prioritize the list, then go through each and ask yourself, "What can I do to either increase the positive impact or increase the probability?" So, for example, if "Slow paying customers" is a threat, "Customers paying early or on-time" might be an opportunity that you can influence and take advantage of when it happens.

Summary & Next Steps

As I mentioned, this is a qualitative tool and not precise at all. After a few iterations, you will likely have dealt with the low-hanging fruit and this method won't be of much use as-is. At that point, you will want to throw in some actual dollar-value loss estimates to help you gauge whether mitigating that risk warrants spending any money. You will also likely dive a bit deeper into the scenarios and instead of evaluating just worst and best-cases, look at the spectrum in the middle taking into consideration just how much does a specific risk-mitigation measure affect the threat impact or likelihood.

Finally, this exercise focused on external threats and opportunities. But it also proves valuable with respect to big decisions and subsequent changes within the organization. Prior to making the decision or implementing the change, run through your list of threats and opportunities to see how that decision may affect them.

Business Continuity Planning and Managing Without Authority

2010-01-29T10:00:00.002-05:00

While this can apply to a number of different scenarios, it's especially appropriate to business continuity planning. As business continuity professionals, we are often tasked with meeting certain goals and objectives. Our success and the success of our programs depend on other people; people over whom we have no management authority.

The nature of our work and of our role within the organization requires that we get other people to do things for us like updating specific components of their plans, updating contact lists, filing out BIA questionnaires or preparing for tests. These tasks are often things they don't want to do and therefore fall to the bottom of their list of priorities. Even when the CEO sends an email explaining how important the continuity planning initiative is to the company and asking for everyone's cooperation, getting that cooperation can be like pulling teeth.

There are a number of different strategies and techniques one can employ to improve your chances of success. One of those requires that you change your own state of mind regarding your role.

If you are tasked with meeting some objective and doing so requires work or input from other people, this is a team. Whether your company formally recognizes it as such, it is a team. And you, the one ultimately responsible for the output from this team, are the team leader. When you change your frame of reference, the question is not so much, "How do I manage and get results without authority?" but instead, "How do I become a more effective team leader?"

First, be aware that there is a distinction between a manager and a leader. And while there is a distinction, the best managers are generally also excellent leaders. But management is not leadership, and leadership doesn't require one to be a manager.

A manager's role is to ensure that resources and budgets are allocated appropriately and to dole out work and assign responsibilities. Results are achieved by way of the manager's authority to make decisions, to rearrange priorities and to threaten repercussions for poor performance. Presumably, if everyone follows the manager's instructions and does what they are told when and how they are told to do it, the department would meet its deliverables. As a manager, it is easy to become frustrated or disappointed with the performance of others.

A leader, on the other hand, offers encouragement and focuses on the success of the team as a whole and its individual contributors. The leader does not rely on authority, but instead leads by principled example and instills a sense of ownership and pride onto the team members. The successful leader is the one that the team members want to follow. Leaders take full responsibility for the team's performance and results.

Taking responsibility is fairly easy when things are going well. When the team is working together and produces good results, the leader pats himself and everyone else on the back for a job well done. He gives credit where it is due, pointing out the exemplary contributions of specific team members who went above and beyond.

On the other hand, when the team is missing deadlines, work product is poor or is otherwise not delivering, there is a tendency to want to point fingers and place blame. Leaders recognize from the outset that this is not an option. Leaders recognize that individual team members do not fail, nor do they cause the failure of the entire team. If the team fails, the cause is solely poor leadership. A failure that results from the poor performance of an individual contributor is due to the leader's inability or unwillingness to identify and mitigate that risk ahead of time.

As business continuity planners struggling with getting others to deliver without having the authority to set priorities for them, the first step is to adopt the mindset that you are the team leader and ultimately responsible the team's success or failure.

Once you begin to approach your work with this state of mind, you can start thinking about leadership strategies for motivation, incenting desired behavior and drawing out talents. You are also in a better position to identify and address problem areas and risks that might impede the team's success.

It starts with thinking like a leader.

Greensburg, KS Tornado: Aftermath Photos

2010-01-15T09:01:00.002-05:00

I was cleaning up the photo gallery a bit when I came across some pictures that I forgot I had found after thinking I'd lost.

Did you follow that?

Anyway, the pictures were a few snapshots I took in April 2007 2008. I was driving out to Los Angeles for a project with IndyMac (now OneWest Bank) from Indiana.

On the way, I passed through, well, ALL of "fly over country". Bored while driving through Kansas, I searched my GPS points-of-interests for a place to stop and see something fascinating. It suggested I visit Greensburg, KS, home of the world's largest hand-dug well.

I was a bit shocked when I arrived to find the town nearly void of life. I did find the well, but it was fenced up and inaccessible. All around was rubble. I thought I had crossed into the Twilight Zone, so I took some pictures. It wasn't until later when I'd checked into a hotel for the night that I found that Greensburg had been hit with an F5 tornado in May 2007.

Technology: Not an end-in-itself

2010-01-12T10:14:00.002-05:00

You know, several years ago, back when the Palm Pilot first came out, I was all over it. I was an early gadget junky and had to have everything techie. Back then, I was the typical IT guy walking around with a cell phone (a big, bulky one), two pagers and my PDA hanging from my "utility belt". I was an IT super hero.

I bought the PDA thinking how much it was going to save my life in terms of productivity and ability to manage all my day-to-day tasks, my meetings and appointments and my contacts. And what did I realize? Probably the same thing many of you did; it didn't help at all. In fact, it was even more cumbersome because now I had one more thing to worry about.

This went on for a long while. As new models came out, I upgrading thinking the problem was with the technology. It wasn't until I finally gave up the PDA and went back to my trusty Franklin Planner that I realized the problem wasn't with technology. The problem was that I didn't have a good time and data management process. So I spent the next several months refusing to use a PDA and relied solely on my planner as I worked out a process that worked for me. After that, I was able to look more critically at the various technologies out there to find one into which I could incorporate my process. Today I can use the technology and not be a slave to it.

The moral of the story is that it's the people and the processes that drive most business and productivity. Technology is important and often facilitates, but for most of us, technology is not an end-in-itself.

So when it comes to continuity planning, why do so many invest so heavily in disaster recovery for their technology assets and all but ignore planning and building resiliency into their business processes?

10 Years Later: Remembering Y2K

2009-12-17T09:45:00.000-05:00

Yesterday I had the pleasure of sitting down and chatting with Larry Smith, President of the Institute for Crisis Management. Among the many valuable insights gleamed from that meeting was a reminder of the months preceding the feared Y2K.

Like many, I was an IT systems engineer at the time. The company I was working for had spent millions of dollars and countless man-hours in correcting code in the ERP systems, financial/GL applications, backoffice systems and even some of the products we designed and manufactured. Like everyone else, we watched the news and closely monitored the progress of critical infrastructure organizations like the banks, public utilities and oil refineries. We went so far as to issue a certification program for our critical suppliers to ensure they would continue to deliver raw materials, equipment and services after Jan 1, just as our OEM customers had required of us.

I clearly remember New Year's Eve 1999. Again, like many other IT guys that year, I spent it in the computer room. I was in our Northridge, CA location and on a conference bridge with my colleagues in Indiana, and in Europe and Asia. Most of the day was spent assisting our overseas counterparts in testing various components as their clocks turned over past midnight. By the time the year 2000 arrived on the east coast in the United States, we were resigned to the fact that this was decidedly a non-event. Midnight came and there were no power outages. Defense systems didn't fail. Banks didn't fail. There were no riots in the streets. And, as expected, none of our internal computer systems failed. It was a quiet night and seemed a lot of anxiety over nothing.

And that's exactly the way it was supposed to be.

You see, worldwide, governments, communities, businesses and individuals knew the event was coming. Through careful planning and preparation, the threat was contained and the potential for disaster was averted. But even today, ten years later, we occasionally hear business leaders argue against the value of business continuity planning by saying, "Look at all the hype around Y2K and nothing happened. Unfortunately, that's how continuity planning works. Ideally, if planned well, virtually all potential business disruptions become non-events.

The only real difference between Y2K and other disrupting threats business face today is that we knew ahead of time exactly when the incident would occur. But, just like Y2K, we know that these disruptions will occur and we know there is something we can do about it to reduce the impact, reduce financial loss and stay in business. We can plan. We can prepare.

The 5 Rs of Business Continuity & Disaster Recovery Planning

2009-10-08T09:16:00.000-04:00

Many SMB owners and managers realize the need to do more than just plan for protecting and recovering their data. But while they realize the need, they often don't know where to begin. Perhaps a good start is to consider what steps would be required in the event of a severe business disruption. Keep in mind that what follows is generic. Conceptually, it applies to nearly any organization, the devil is in the details and will vary between organizations and specific circumstances.

I've broken the timeline into 5 phases, and what you will do during each of these should be included in your plan. I call these phases "The 5 R's".

Response

This phase consists of the first seconds, minutes or hours after the event occurs. During this phase, you will evacuate the building or move staff to shelter. Think triage. The safety and security of employees is the first concern. Next, you will likely take specific steps regarding communications to senior management, and maybe customers if they will be impacted. You will also perform some level of damage assessment and weigh the results against some predefined criteria to determine whether to activate the plan or some components of it. Most organizations will also, at this point, assemble into pre-defined response and recovery teams to better manage the situation going forward and begin developing their situation-specific business resumption strategies.

Resumption

The resumption phase deals with, well, resumption of your most critical business processes and activities that are likely tied to revenue generation, cost-savings or qualitative objectives like customer service. You know, all those mission-critical activities identified in your Business Impact Analysis. Here you will, if necessary, relocate critical staff to their alternate workspaces. Then you will implement the manual work-arounds that keep your business going for the short term.

Recovery

If you have Tier 0 applications, they have hopefully automatically failed over, are running from the hot-site data center and are available. It is during this recovery phase that IT will work to get the supporting infrastructure operational and business applications and data available. As each application becomes available, the business users then recover their business processes.

Restoration

During all of the previous phases, a surprising amount of work has stopped and your organization has been working in a limited capacity for hours, days or even weeks. The restoration phase, then, is when, while still operating in a recovery environment, you will try to get things as close to normal as possible. Important but less time-sensitive activities such as hiring, paying bills, ongoing training, sales and marketing activities and other active projects can resume. It's also during this phase that the organization will plan for fully transitioning back to normal, including migration back to original or newly constructed facilities.

Return

While this phase is difficult to plan for in advance, it is important to be aware of it. Moving from the recovery site back to the original data center, if not planned and executed carefully, can be a disaster in itself.

---

Of course, to be complete, all of the above steps assume that you've pro-actively addressed the most important phase in any emergency response or recovery plan: PREPARE.