y2k countdown: Schedule Pressures?
Don’t surrender to schedule pressure! Why not? Many crisis points have pastthe most recent being Year 2000 fiscals in New York and Canadaas small blips on the radar screen while the media stood by and nothing happened. Certainly they must have done things right, foretelling easy sailing for all.
How might one get into some of those scheduling problems which turns Blips into Blobs?
At times, status reports are made to appear a little better then life truly is, in the hopes that we’ll catch up next week. Who wants the Boss to yell? Suppose the boss tweaks your report a bit more positive and their boss does the same. Great world and no costly Year 2000 project looms in the shadows. Then out of the blue comes a set back, with unexpected costs and perhaps less trust for MIS.
Somehow we manage to fall prey to our best visions and intentions by underestimating or allowing ourselves to be sidetracked to other efforts. Then there is an unqualified set of trusts -- maybe we do not expect other problems or matters to pull us away from this key project. Management to the needs of daily operations and change might be overlooked, leading to unrealistic expectations. All this could come from poor communications resulting in insufficient management commitment.
Some Recent Occurrences
Obviously, starting too late, wasting time or being side tracked, are all easy pick-ins. To overcome this, one might apply the Triage theory and fix only what needs to be fixed and ignore the rest entirely. Triage must eventually address the whole business. No stopping, just proper sequencing, priorities, timing and follow through is a must pre and post 2000!
Case 1 – A vendor is not willing to hand over source code for key modules so you can remediate the remaining application code and interfaces to your other applications and modifications. While waiting infinitely is not a reasonable option. What can you legally do to overcome this matter?
Take some time to try to better understand the vendor’s side and perhaps come to some agreement. If this is not possible, look into alternative solutions and the vendor’s liabilities to you. Don’t wait too long, continue on a forward path and evaluate the added costs and risks to on-time completion. You have to manage the risk carefully and assess the value of the vendor. If the vendor is out of business or cannot be located, you must ask yourself whether you can do source recovery at a reasonable cost.
Case 2 - The lack of one set of remediation standards. What happens here is varied forms of date compliance through expansion [one for the Century or two], compression, encapsulation, and/or windowing. Windowing could have its own subset in this grouping. Different pivot dates, methods of calculation, and fixed or sliding techniques. Multiple remediation techniques are an accident waiting to happen.
Managing or Not Managing Risks
Short cuts or failing to test are NOT options. Think compliant! Remember, close only counts in horseshoes, hand grenades and atom bombs. Is it foolish to accept application code, as being so well done, it will not fail beyond manageable levels? Perhaps, you should test it and use it against all the business processes, top to bottom. Testing as you did in the past is an incomplete choice.
Establish a baseline and repeatable process. This will allow use of the data aging and date comparitor tools.
Even if you do not use tools, you have to be able to measure the tests at about 16 to 18 different key dates during 19xx, 2000, and 20xx. Remember to cover period ending and other special Year 2000 dates
Contingency Plans should be formulated all through the process from start to finish Introduce a few errors too. Look at them as a likeness to your disaster recovery (DR) plans. If you have a DR plan you have a year 2000 contingency plan head start. You understand the priorities of normal DR efforts and have to add those items that are discovered as related to Year 2000 in specific nature. It would not hurt to go through these with your management teams and update documentation and priorities to today’s requirements.
You should take a risk evaluation review as a precaution to preventing errors and the introduction of failures during production and the need to invoke contingency plans through independent quality assurancemore commonly recognized as IV & V Reviews, or Audits. Historically, such reviews by independent parties uncover errors that even testing had not seen.
Bottom line: There is little room for short cuts. Automation and proper methodology and a fully committed management team are the keys to success.
Don’t become a casualty -- exercise good Risk Management! Help make Y2K just another day
Glenn Ericson is president and founder of Phoenix Consulting LLC, in East Elmhurst, NY. He specializes in Year 2000 and risk management issues. Glenn-Ericson@att.net.