|
Every y2k project ought to have a contingency plan. The Army has several. The trouble is, they are crap-shoots. Entire systems may go down.
See if these fall-back positions constitute workable options. Yet they do appear to be the only positions possible.
On the allocation of resources necessary to compete a y2k repair project, see the
California White Paper.
* * * * * * *
Figuring a contingency plan is essential to any project but specifically to the Y2K program. Year 2000 is a fixed date with no exception criteria allowed. Year 2000 epitomizes the principles of risk management, project management, and configuration management. If the system is not fixed before the earliest event horizon, strange data will result and abnormal ends to system processes will occur. Contingency planning is comprised of two steps.
The first step is to establish a point in time on the schedule where if a renovation strategy cannot be carried out as planned, another solution should be tried. At this point, the second step is to address a series of what if statements which guide the planning and ultimate decision making for the contingency plan. The contingent solution usually will fall into one of three categories; 1) manual work around, 2) backup suppliers of hardware or software, or 3) additional pool of resources (people and money are required). Some examples of what if statements are:
What if the supplier is overwhelmed by the onset of the Y2K crunch and cannot deliver on time? Then have a backup supplier available.
What if the correction time was underestimated and more resources are required? Then have a backup plan to resource up or scale down the correction effort (this may include a manual work around).
What if all of the components and processes requiring corrections cannot be worked? Then have a plan to contact the users and describe to them what manual work around they should employ.
What if the operational testing does not get completed before deadline? Then implement entire patch without full test or implement portions of correction that have been fully operationally tested.
What if correction is completed and does not work? or new problem is introduced that wasn't planned for? Then look at alternative solutions analyzed during the trade-off analysis (second best preferred solution, which may cost more) and rearrange plan.
The second step is to rearrange the plan. When activities start moving, the impact on other activities will ripple throughout the project. The effect of one correction not taking place on time must be analyzed and reported accordingly, which leads to the second part of step five, setup reporting structure.
|