by J. Carlton Collins
Never mind how much product training you receive. Technology consulting is an on-the-job training business whose lessons are valuable only after they are learned.
Here are two examples of valuable lessons that I have learned while on the job.
Many years ago, I installed an accounting system for a construction company and instructed the office manager, Gwen, about the proper back-up procedures, which involved 20 diskettes. I strongly suspected that Gwen would not perform these back-up procedures as I instructed. Call it "consultant’s intuition."
However, to my astonishment, over the next six months, each surprise inspection of the client’s back-up disks revealed data files for the previous day. It appeared as if that Gwen was doing her job.
Six months after I had installed the system, Gwen encountered something that can best be described as a "vague technical problem with the computer" and the "guy" at the computer store where she purchased it instructed her to format the hard drive - which she did. (I was amazed that this computer store guy was able to determine the need for this procedure via a simple telephone call - I figured that he must be really smart). Gwen then called me to restore the system and data.
I reinstalled the operating system and accounting software just fine and then turned my attentions to the data files. The first diskette restored properly, however, the second diskette would not cooperate.
Upon closer review, I found the data files on the second disk and all subsequent ones to be six months out of date. When I asked her about it, Gwen replied in a thick southern drawl, "I only entered a few transactions so I thought surely that must have gotten it." Translation: "I started the back-up procedure each day as instructed, but then turned the computer off after disk one was full."
It gets much worse.
I was now forced with the task of re-entering the data into the accounting system from the paper records. The trial balance data entry proceeded without difficulty, however, there was something askew about the 334-page construction-in-progress detail report itemizing the $4.7 million costs related to 147 homes in progress. It seemed that the printer ribbon on the Okidata Streamline 193 printer became lodged, and on page three of this report, you could begin to see the printed data fade to braille.
The detailed data report was virtually unreadable. I considered my options carefully. I ruled out a crayon rubbing. I considered employing the services of an FBI cryptologist - but didn’t know where to find one. I thought about strangling Gwen. In the end, I asked Gwen for a key to the offices and sent her home. I then pulled an all-nighter, wading through 147 file folders in an effort to reconstruct the data.
In the end, I realized that the problems I encountered were of my own doing. I learned a valuable lesson that day.
On that day I learned to make secret back ups to clients’ data, and to test both the first and last back-up diskettes in a stack. I learned the hard way just how important proper back-up procedures are, and it seems that most people who have learned this lesson have learned it the hard way, too.
In another engagement, also a few years back, I was assisting a large architectural firm with a troublesome accounting software installation. The company had been trying for months to get the system running, but the time and billing data just would not properly flow to the job-costing module.
After several days of effort, I had exhausted the obvious remedies based on my knowledge of the system, and I was forced to turn to vendor support. Unfortunately, vendor support from this particular vendor amounted to waiting on line via a long distance phone call for a couple of hours before an operator would take my name and number, promising a call back later. In this case, "later" usually meant three days later.
Undeterred, I awaited the support, explained the problem and received a patch that promised to rectify the problem. I returned to the client’s offices, installed the patch but found that the problem persisted.
Back at square one, I repeated my original steps. I called support, waited online, gave them my name, returned to my office, explained the problem again three days later, received another patch, installed the patch, tested the results and determined that this stubborn problem would not fade away.
This became a little game. Like an endless loop, I re-traced this procedure a total of four times over six weeks. At the end of six weeks, my client put a halt to this endless loop by firing both me, and the controller - claiming that neither of us knew what we were doing.
Years later I met with an employee of this accounting software vendor. I mentioned to them the problems I had encountered in trying to integrate the time and billing module with the job costing module. Without skipping a beat this long-time employee retorted "Oh, that never did work, that’s why we got rid of our time and billing solution." Astonished, I explained that a person had gotten fired over that bug, and that I had lost significant consulting fees related to that bug. This person explained that the support department was simply buying time hoping that the known problem would be resolved.
The lesson I learned is to recommend and work with only those products whose publishers provide good end-user support.
