I love Excel! It is a program with so many different faces. So many different ways to use it. Truly the Swiss Army Knife of desktop software.

On the other hand, that very flexibility gets us into so much trouble. We start with a small worksheet to track jobs. We add a bit of fancy formula work to make the data entry easier and to help maintain data integrity. Before long the little worksheet that could is now the giamungous workbook from hell! You can’t kill it, because your business depends upon it. You can’t fix it because you don’t have the resources to make it better or maybe you just don’t know how.

Having been guilty of this spreadsheet feature creep in the past, and having just been shown a classic case, I thought it would be worthwhile tearing down this case, and building it back up again.

Value Analysis

Before we commit to spending time to improve the tool, let’s ask the questions:

• is the task the tool is used for necessary?
• do we really get a good value out of the tool?
• is there potential for more value in the tool with a minor modification?
• are we using the right tool?

Yes, you say,

• the tool fits a critical need.
• there isn’t anything out there that quite meets our requirements.
• the value is there.

We have to fix this thing.

Requirements Analysis

First, we need to remember that there is no such thing as a short term solution. I wrote one once (at least one) that was supposed to bridge a six month period.  It was still in use six years later.  The project that would bring in the final solution was cancelled!

There are two sets of requirements: the business functional requirements, and the support requirements.

Stay tuned – we will discuss the support requirements in our next post.

Today, while doing some research on a different topic, I stumbled across an item to do with Business Continuity. What blew me away, was that it was classified under the topic of a Business Resiliency Program.

Such a brilliant concept. 

Everybody wants their business to survive an unforeseen event. Most businesses have a disaster recovery plan for their computer systems. They might even test it once in a while. When you take the disaster recovery plan a little bit further, you start creating business continuity plans. The business continuity plan gets outside of the computer room. It looks at all of your business processes and you create plans that are more encompassing. Continuity plans take into begin to take into account the effects of the weather, the impact of a flu epidemic. But Business Resiliency? Now that takes the concept to a whole new level!

Planning for a disaster like a flood, an earthquake, or a server failure – we all understand that. Making contingency plans to cover snow days or power outages. As I said, these are the next logical level.

Putting in place a resiliency program, now that is great! The word conjures up images of stuff bouncing off of a wall. The resilient business is built to deflect all adversity. The resilient business has the plan built into its operational processes. The resilient company doesn’t react to stuff when it happens because its processes have developed to include the stuff handing protocol. In the resilient business, invoking the contingency plan would be like declaring a disaster in another business.

Brilliant!