Tip of Iceberg
Home Up Tip of Iceberg GroupWare Comparison


Subject: PC iceburg: PC spreadsheets and databases

A week ago we started checking PC spreadsheets and databases using <a vendor's package>.  I have mixed emotions about the results. One one hand the package seems to work very well and provides some detailed assessments of the PC files. On the other hand, it has uncovered some monsters under the ice.


If our continuing assessment plays out like the trial on this tool, we're in deep trouble!!! The sheer volume of suspect PC files could overwhelm our ability to review, not to mention upgrade, all of them. Some of these systems have been around for quite a while and some are very new.  Some developers are simply computer-literate business folks and others are professional programmers.   So far, it hasn't made much difference who built what.

Message: Look REAL CLOSE at your PC applications. It may change your whole perspective on the depth of the Y2k problem.


Let me make a few comments to consider about your pilot.

First, have you looked at how recently each spreadsheet and database were last accessed (I did not say last "saved" date, I said last "accessed" date) before you run your scan? If you run the scan first, you will lose this information because the date of your scan will become the last accessed date. Hopefully you find some that have not been opened for the last year or so and you may be able to reduce the quantity of files you have to remediate that way. Be careful with this, opening the files in read only mode (or even just copying the files) may update the last accessed date. The largest problem I found was that my backup programs updated the last accessed date. You also need to make this decision in consultation with the user, maybe he has some spreadsheets that are only opened for end of year processing or something.

Second, have you considered further abating your efforts by reducing the quantity of duplicate files that you have to remediate?  This can safely be done by identifying duplicate files before you remediate and then distribute copies of the remediated spreadsheet to PCs having identical copies.  How many times do you want to remediate the same spreadsheet in your efforts? Again, you have to be careful here - duplicate files do not necessarily have the same name, size, or date, but they may still be duplicates.   Successful spreadsheets are especially susceptible to being created on one PC and emailed to coworkers - multiplying your iceberg by many times over.

Third, you can further abate your efforts with some high level planning. If you remediate spreadsheets that are structurally identical together, you will find that your effort will be less because you will find the same things in each batch of spreadsheets.  For example, if you have a spreadsheet that is updated monthly with the current month's sales statistics, they are all structurally identical - only the numbers and dates have changed.   What needs to be done to one, needs to be done to all of them.

Forth, how are you testing your spreadsheets? It is my understanding that some tool manufacturers are telling people to re-run the assessment tool to "test" the spreadsheet and that is it. Larry, you have been in the Y2K remediation business for some time now - how many mainframe applications have you been willing to declare fully tested by merely re-running your assessment tool?  What was the reason for that?  Do you think the same thing applies to mission critical applications that happen to be located on desktops?

Vic Fanberg