Year 2000 Triage: The Interdependence between Software and Business
"He who defends everything, defends nothing." Frederick the Great
If you are reading this article, you are already aware of the threat that the Year 2000 poses to your software and ultimately your business. You are also aware time is short and skilled people and sufficient resources are scarce. Whether you are at the beginning of a Year 2000 Project or part way through you may have reached the conclusion that you cannot save everything.
So what does a Year 2000 Project Team do?
As the time before the Year 2000 slips away, the importance of conducting a "software triage" increases. A triage is a medical process where large numbers of wounded or injured are sorted and classified based on urgency. Some can be ignored. Others may be allowed to die because there is nothing to be done to save them. But the most difficult is deciding who amongst the rest will be saved because you have insufficient time and resources to treat them all. Some people have to be sacrificed so others may live. Your software may undergo a similar triage as part of your Year 2000 project because you cannot save it all. But a software triage is inevitably a business triage and it is this interdependence that can lead to complications.
The Year 2000 presents the clearest example of how intertwined business is with today's technology. Everyone has heard, "I'm sorry I cannot help you. The computer is down." Some people may long for the 'good old days' but modern businesses is done via the chip, and, pardon the expression, when the chips are down so are you.
Much literature on software triages suggest categorizing items into the following (or similar) three categories:
These three categories do not adequately address the interdependence between business and software. Who decides what is core? An essential software module may not support a core business function or vice versa. It can lead to conflicts between information technology managers and business managers, as they will each have a different vision of what is "core".
Here are some steps and associated pitfalls to guide you through the software triage process that recognizes the relationship between technology requirements and the needs of the business. Please note, it is assumed that an inventory has been completed of the software affected by the Year 2000 and their respective 'drop dead' dates determined. (Many programs will malfunction prior to the Year 2000) It is also assumed you do not have the time or resources to fix everything. Otherwise, you do not need a triage and should be enjoying your good fortune.
STEP 1
Having realized you do not have time and resources internally to fix everything, you may want to bring in outside help. If your business has enough money, your entire software (off the shelf and customized) can be contracted to an outside vendor, thus eliminating the need for a software triage. But it does put in place a de facto moratorium on future systems development until the vendor is done converting your systems. Any changes to the baseline software will incur additional costs from the vendor. Changes may also delay the schedule so a triage will become necessary. The moratorium will be particularly acute if most system enhancements are done in-house. It also places the entire future of your business in the hands of a vendor.
STEP 2
If you cannot buy a complete solution, you must initiate the software triage process. Define your main or core business without considering systems implications. This is not as obvious as you may think. For smaller businesses it is usually easier, but many large organizations have diverse operations. This is particularly true for public service bureaucracies. Most people believe what they do is essential for the business (just look at the justifications written around budget time). Defining the most important things a business does will inevitably threaten those that are not working in a core business area. They may be particularly sensitive if your organization completed a downsizing exercise. Expect resistance and/or rather elaborate explanations about why a particular function is core. The exercise is also a good litmus test for senior management. If they cannot agree on what their core business is, then your company has much larger problems than the Year 2000 to worry about. Business managers outside the Information Technology department should do this step.
STEP 3
Define the software components (programs, modules, etc.) that are essential and non-essential to keeping the data systems operating. It is very difficult, if not impossible to do this without any consideration to the business functions since the software's purpose is to support business. One approach is to ask the question to ask is, if this application or module were removed, would the remaining software still function? If not, what kind of 'patches' would be required for the remaining software to continue functioning? Any application or module that would require significant patches if removed could be considered essential. Of course, this approach is a bit simplistic. Another approach is to take the single core business function considered the most important and define the critical path of software applications and modules that support it. Those not on the path would be non-essential.
In steps 3 and 4, common sense must prevail. By drilling down into too much detail or using a broad definition of 'support', you my find yourself in too many angels dancing on the head of a pin type argument. Someone must have the authority to stop the process and draw the lines. Remember that time is short.
STEP 4
Using the results of Steps 2 and 3, you can now determine the relationship between the software and your business. Which software component is associated with the core and non-core business functions? Use the following matrix to categorize the software components:
Core Business I II Non-Core Business III IV Non-Essential Component Essential Component
It is obvious that software components placed in Quadrant II must be fixed. Also, Quadrant III represents software that can be safely ignored and picked up later if there is time and resources.
But what of Quadrants I and IV? Which should receive priority if you cannot fix both? For example, how do you inform a department to make alternate arrangements because their core business is attached to non-essential software components and will no longer function for a considerable length of time if ever at all? How do you justify that decision when a non-core statistics report will continue because it is attached to essential software? What of the Vice President's pet project that may not continue? These are hard questions and there is no set formula for answering them. The difference between Quadrants I and IV is a chicken and egg argument, the essence of interdependence. You can't have a system without a business nor a business without a system.
The process of the three categories listed above (core, important, nice to have) is not transparent enough to attain the balance a Year 2000 Project needs between systems operations and business needs. Ideally, you will want to make Quadrants I, II and IV Year 2000 compliant. If you do not have sufficient time, most solutions will be quadrant I and a mix of some software components from Quadrants I and IV selected on a case by case basis either for the greater good of the business or the function's ability to create alternate arrangements. In the process, priorities (which may be needed in Step 5) can be assigned to the software components.
A review team will have to be assembled for this step of the process. The review team will need to include a sufficient representation of the business with a realistic appreciation of the Year 2000 problem. They will also need the authority to make the decision. Do not make the mistake of creating a lengthy review and approval process for each choice made. You will not have time. The Project Manager will need significant input in order to maintain the effectiveness of the Year 2000 Project Plan. The review team will also need the unequivocal support of senior management (see Step 6).
STEP 5
Now its time to roll the results into the project plan and do the actual triage by following the decisions made. It is a good idea for your planning strategy to include multi-level triages. Unlike most projects, the Year 2000 has a rather inelastic deadline. If the plan is off schedule, then another 'triage level' can be executed. A group of software components assigned a lower priority are dropped to recoup the lost time. The greater the delay in the project the greater the sacrifices. The multi-level triage could occur at any point in the project. The multi-level triage also clearly demonstrates to any non-believers the urgency and importance of the Year 2000 Project.
Any software component and related business function dropped through the triage process would have to begin contingency planning immediately.
STEP 6
Get approval and support for the results of the triage from senior management. Anyone involved in a Year 2000 software triage is going to make enemies because somebody will lose in the process. Resistance to the choices made during the triage will continue throughout the project and you will need support. Being forced to change priorities due to internal pressures will greatly increase the risk of failure. Also beware of becoming a scapegoat. Without a clear, ringing endorsement from management it will be easier for someone like the Project Manager to be sacrificed for the good of the company if there is too much infighting.
STEP 7
The results of the triage must be communicated to everyone; particularly the affected parties as soon as possible so they may begin arranging alternatives to carry on. Perceived secrecy (even if it is just poor communication) will only increase resentment to choices made. The multi-level triage in step five may help since people will see clearly what will be impacted if the project is delayed and it may lessen some resistance to avoid further losses.
In conclusion, if you believe this sounds pretty grim, you are right. Waiting to initiate the Year 2000 project will leave many organizations facing rather unpleasant choices. The Year 2000 Project Team will not be terribly popular. If you are on one, you have to ask yourself if you have the personal resilience, negotiating skills and energy to carry out this kind of exercise. If not, then reconsider your position. If so, then the best of luck with your project.
This article was published at Pete DeJager's Year 2000 site www.year2000.com.