Systemic Triage

By Peter de Jager

The sad fact of the matter is that for some, it's already too late to solve the Year 2000 problem in a coherent and satisfactory manner. For whatever reason, an unreasonable number of companies have just left it too late. The recriminations, finger pointing and lawsuits will begin in a year or two, to no avail; the damage has been done.

It's time to play the Last Post and chorus... Some companies will not pass over into the next century because their mission-critical systems will crash against the inevitable wall of '00.' Consider it a lesson learnt. In the future let's design systems for what will and might happen. For now, let's concentrate on those who can survive.

We can minimize the damage. What percentage of organizations will fail? With some small bit of fickle luck and a large dose of careful and prudent planning, we can keep the number of fatalities to a bare minimum.

In the medical profession there is a concept of "triage." The dictionary defines it as follows: "The sorting and allocation of treatment to patients, especially battle and disaster victims, according to a system of priorities designed to maximize the number of survivors." The idea being, that if there aren't enough medical resources to save everyone, you prioritize to save as many as possible. Setting these types of priorities involves making some very difficult decisions.

Some companies are going to have to perform triage on their systems. It won't be easy, it'll be resisted, and it's going to hurt. It may be the only way get through the 00 barrier with enough systems intact to print an invoice, ship a product and pay the bills.

At its simplest, during medical triage you sort the casualties into three groups. First, identify those who'll survive if they get no medical treatment. Next, find those who if they get medical treatment, have a good chance of survival. Lastly, those who, even if they get medical treatment, are unlikely to survive.

You then ignore the first and last groups and concentrate all your efforts on those who have a good chance of surviving if you get to them in time. When we take this concept and apply it to systems we modify it slightly, because we're not trying to save the individual systems, we're trying to save the organization relying on those systems, to perform 'business as usual."

We first identify mission-critical systems. Those systems upon which the very heart of our business depends. Those systems that we've pointed to, every time we've had to justify our existence. Mission-critical systems are those handful of applications supplying the motive force behind the business.

The next group of applications are those which we could live without for a while. Perhaps for ever. Their loss would severely affect our ability to conduct business ... but we could get by, hobbled by the loss of key functions, but shipping product and providing basic services. Albeit slowly, expensively and inefficiently.

Finally, identify those systems you run, but don't really need. At first you might respond, "We need everything we run! Otherwise we wouldn't be running it!"

My response is that Pareto's 80/20 Rule likely applies to computer systems more than it does to any other human endeavor. Eighty percent of the benefit arises from 20 percent of the effort. Looked at from the hind end ... 80 percent of what you do generates less than 20 percent of the benefit. The truth hurts. Chin up! It's going to get worse.

Guess which ones we're going to ignore? Everything but the first group. Everything but the mission-critical systems is dross. If you do not have enough resources to save everything then, all your efforts, all your resources, all your attention must be focused on getting those mission-critical systems operational. Anything else would be poor project management and worse yet, poorer judgment.

Even those mission-critical systems contain non-essential functionality. An example springs to mind. I was once told there are 50,000 ways to cut an airline ticket. In other words, a multitude of special deals, discounts, charter programs, group rates, stay over Saturday, bring your own meal, bring a meal for the pilot, fly back on a day that doesn't have a "Y" in it, etc., etc. Are all these options necessary? Admittedly, the airline must have the capability of cutting a ticket, but does it have to do so in so very many creative ways?

One way to reduce the effort in getting your systems Year 2000 compliant is to reduce the functionality of the system. "Sir, we have tickets in two prices. Do you want to sit in the front or the back of the plane?"

One response is that those extra features are necessary, otherwise the competition will gain customers, because customers like choice. This is where triage becomes difficult. The basic assumption is that you don't have enough resources to do everything in the time remaining. So ... what will you do? What core of your systems will you save? You're right, there's a gun to you head ... and we put it there by not addressing the Year 2000 problem earlier. So choose. What functionality do we keep? And what to we let slide?

So we make the tough decision and slim down the code and functionality and revert to bare-bones bits and bytes in order to survive with some semblance of a system. Remember, triage is Hobson's choice.

Naturally not all systems can be "slimmed" down without involving an entire re-write of the system, and this is NOT the time to be re-writing systems. At least not from scratch. Beware of the Year 2000 compliance strategy that has you writing on a new hardware platform or software environment for the first time. You're "risking the organization on the roll of the dice" to paraphrase some all but forgotten Canadian politician.

One of the key components to the decision-making process for any systems department when planning for the Year 2000 conversion is their historical track record for meeting deadlines. On budget is of little consideration. You can run over budget on this project and still be left with a viable company. You cannot miss the deadline by three months and ask for forgiveness. There'll be no one around to dispense absolution.

What systems are candidates for the slimmed down approach? Accounting comes to mind. If you can't fix your entire system in time, then perhaps it's time to look at an off-the-shelf product. D&B and Great Plains Software have both announced their products are Year 2000 compliant. Perhaps they offer a way out of the quagmire we find ourselves in?

The trouble with packages is they never meet all your requirements. (Only custom software does that ... and if the truth be told, most times it does it poorly.) You're lucky if an off-the-shelf package does 80 percent of what you want. The question you have to ask is, does it do 90 percent of what you need?, where need is defined as the core functions required to run the company.

If many organizations are to survive, then they'll have to make these types of decisions and make them soon. When push comes to shove, when your project to 2000-ize your accounting application is three months behind schedule and it's the last quarter of 1997 you must make what is called an executive decision. (Those are the ones that justify the high salaries we get paid.)

Will the project team make up those three months in the time remaining AND increase productivity to the point where the project is back on track? Given your progress so far, where does your hope come from? Or will history repeat itself again and you're looking at yet another project out of control? And this time it really matters.

Do you switch gears and give up trying to fix the broken system and instead, go out and buy a new one? When will you make that decision? Because it takes time to install a new accounting system. Time is the thing that's in short supply (that and the courage to make the decision to act ... which is why we're in this time crunch in the first place.)

Years ago we were faced with the same type of decision. Do we start fixing the Year 2000 problem now? The decision to fix the problem wasn't easy, it was resisted, and it was going to hurt. So many companies held off doing the right thing. The question of triage is our second and last chance to save the company. Will we make the same mistake again?

Or, instead will we create hard and fast "points of no return"? Where if a project is late, we have a contingency plan that kicks in automatically, no matter how much it hurts to do so?

Once upon a time, we could afford to tread gently on the Year 2000 topic. Time does not permit social niceties anymore. Time has run out for many companies if their plan is to convert all their systems. Now they must perform triage and decide which systems they'll try to save and which they'll sacrifice on the altar of expediency.

Triage is a nasty choice. It's a choice of last resort. It's the type of choice we should have done everything to avoid. For many it may be the only choice remaining.

Once upon a time we had the time to do this right. We could have converted everything at our leisure. (For starters, we could have written systems correctly in the first place.) No muss. No fuss. And I'd be writing more enjoyable articles.

On the Year 2000 Internet discussion list, Jordan Wouk from Merck-Medco Managed Care, based in Montvale, N.J., suggested the time has come to find a balance "between urgency and panic." As you can tell, I'm having some difficulty in finding that balance.

The situation is gloomy. Unless of course, you've been proactive and have already fixed your systems. Can you imagine the competitive advantage you'll have when you can offer an airline ticket in 50,000 flavors and your competition can only offer vanilla?

Peter de Jager is featured at DCI's Year 2000 Issues and Answers Conference.