Management Toolkit

My nine biggest blunders as an IT pro

Tags:
Career,
IT,
Blunders

Becky Roberts Tech Republic

Published: 18 Jul 2006 13:00 BST

We've all had at least one or two embarrassing moments on the job, whether they involved inadvertently wreaking havoc on a system, making a social gaffe, or mishandling a project. IT pro Becky Roberts decided to come clean and share her worst career moments — along with the lessons she took away from each experience.

Over the past 16 years of being paid to make computers and people work together in perfect harmony, I have collected a number of incidents that make me wince and blush in embarrassment when I think of them. The mistakes I've made fall roughly into three categories: technical, political and career management. Here, in no particular order, are my most outstanding screw-ups and the lessons I have, I hope, learned.

#1: Accidentally deleting the vice president's files without having a backup
I don't even remember how I did this. Not only did I delete the files, but it wasn't until the format was in process that I realised my mistake. I spent a nervous 30 minutes deciding how to deal with the situation. Should I lie and try to shift the blame? I couldn't blame any other person, as I was the whole IT department. Should I just return his computer and act dumb? "Well, the files were there when I gave the computer to you." Nothing I could think up felt right. In the end, I simply walked into his office, handed him his computer and confessed, "I have screwed up. I deleted all your files and have no means of getting them back. It was completely my fault." Silence. Then: "Okay. Please be more careful in future." That was it. That was all he said. I could've kissed his feet, my feeling of relief matched only by the feeling of abject stupidity and incompetence.

Lesson learned? BACK UP BACK UP BACK UP. Never delete, move, modify, upgrade, update, patch, flash or format without making at least one backup. I have never knowingly lost a file since.

#2: Modifying the payroll program so no one received overtime
This was at a ceramics factory in the Midwest. Payroll consisted of a Basic program on a minicomputer. A new rule for calculating overtime was to go into effect, and I was given the assignment of making the appropriate modification. I made the required change on a copy of the live program and did a walkthrough. The logic seemed flawless. I showed the program to my boss and he gave it his blessing. He said that he would put it into production at the start of the next pay period. Alarmed, I asked if we had a test system. I had been working for the company for just two months and was not familiar with the infrastructure. He grinned and said we didn't have one.

Two weeks later, a virtual riot broke out as the employees opened their checks to discover the awful truth: no overtime, none, nil, nothing, nada. My boss said I could go home early as I was looking horrifically pale.

Lesson learned? This is a tough one. Obviously, I had made a programming error and needed to improve my skills. But should I have realised that my abilities as a programmer weren't up to the task and tried to refuse the assignment? I did express my qualms about putting an untested program into production, but perhaps I should've done so more forcefully. Probably the most important lesson I learned from this incident is to ask very detailed questions about the infrastructure when interviewing for a new position and try to identify and avoid companies that don't support best practices.

#3: Going live on a demo copy of Exchange
I was a new hire into a two-person IT department and given the project of installing MS Exchange. The company was using a text-based freeware email system, but it was so difficult to use there was no mail to migrate, so this could be a simple install.

I obtained a demo copy of Exchange, installed and configured it, and selected a small group of test users. I set up training for all users who were interested and soon expanded the "test" group to include all the employees. As days turned into weeks, the amount of data being stored grew rapidly. Users created folders and archives and entered their contacts. I ordered the appropriate Exchange licences, assuming that they could be applied to the demo version. Finding no way to apply the licence, I called Microsoft only to learn the heart-stopping truth that there was no way to apply it and, worse, after 90 days the demo system would simply cease to function. This was day 88. Needless to say, I spent the next 48 hours on the phone with Microsoft tech support setting up a new server to replace the demo one, migrating data and changing client configuration. It was one big, panicky mess. The only good to come out of this situation was that it turned into a great opportunity for learning.

Most salient of the many lessons learned?

Don't go live on a demo application without first checking that it doesn't self-destruct on its expiration date.
Make a project plan and stick to it. I should not have expanded the test group to the whole company.
Improve communications with the users. They should not have been allowed to use the test system to the extent that they became dependent on it.
Insist on being allowed to attend training before assuming responsibility for a new system.

#4: Taking backups for granted
Server backups were my sole responsibility. I set up the backup server and religiously changed tapes every day. The very first time a user needed a file restored, I discovered that the folder containing the file had not been successfully backed up for more than three months. Worse, the particular file in question had never been backed up. Suppressing the urge to blame the failure on a software fault rather than my own negligence, I went to the user and apologised. He was not at all impressed.

Lessons learned?