When I agreed to do that segment with Kevin Devin from In the Trenches, he sent me a list of possible questions, so I would have a pretty good idea of what he was looking for. There were a number of those questions that I wanted to answer, and take advantage of the opportunity to make a point about working in IT, and we discussed many of them. Upon further review, there was one question Kevin didn’t ask that I wanted to talk a bit about here tonight.
The question was “What was your most memorable moment in your IT career?” For me one of the most memorable moments was a Monday morning in Sept. 2000. We had planned a network upgrade the previous weekend. Unfortunately, when I and a couple of consultants we brought in for this project started in on it early Sat. morning, we soon discovered that the wiring closet was not at all what our documentation indicated it should be. Despite the fact that the whole building was wired with Cat5 High speed Ethernet cable, most of the network wiring was plugged into the internal analog telephone lines, and therefore was not going to see any performance increase from the new equipment. This simply had to be corrected, so we made the decision to pull the entire panel and re-wire the closet. Needless to say, this put the project’s timeline is serious jeopardy, but it simply had to be done.
Se we worked for many, many hours that weekend. (I think we worked something in the area of 10AM until 11PM Sat, and similar to that Sunday.) We got the new server installed, every office’s Cat5 connection tested and documented, the new switches put in place, and almost all of the re-wiring done. Unfortunately, we ran into an issue with the panel and had to wait until Monday to get a part in to actually allow the network to be up and running.
On Monday morning, while our consultants were out getting the part, I got to attend our Monday morning staff meeting and explain why the network wasn’t up and running yet, and why we hadn’t even started rolling out the new desktops yet. I tried my best to explain the issue with the wiring, and how the wait would be worth it, because now everything would be wired properly, and that would give us increased performance across the board, how things would be more stable and easier to troubleshoot going forward, how much good this slight delay was going to bring us, and even how long we had been at this over the weekend. No one cared. All they saw was that the network, and the Internet connection with it, was not available. Another 12 hour day on Monday, followed by an 8AM until 2AM workday on Tuesday/Weds morning got us to the point where the project was completed, everyone had their new PC’s, the network was available to them, etc. but all anyone remembered was that it wasn’t done when they came back to work. (And yes, I was back there at 8AM Weds. to troubleshoot any last minute items and answer questions. I left at about 2PM for the rest of the week..*L*)
Why was this memorable? Because it taught me two valuable lessons about tech projects. The first, always verify your documentation, especially when it was done by someone who had your job previously or by an outside consultant. An outside firm had done the original network wiring, and did not follow the documentation laid out. I could have saved a lot of unexpected delays if I had gone in, pulled the patch panels out and verified those cables went where they were supposed to.
The second lesson, no matter how much good you think you’re doing, or how much time and effort you put in to a project or fix, users only care about one thing, using the technology. If it’s not available to them, all the talk about increased performance, ease of use and future benefit is in one ear and out the other. Your job, to them, is to make the technology work. When it doesn’t, you have failed in their eyes. There’s no use trying to change the situation, all you can do is make getting them back to using their tools as high a priority as possible.
Both of these lessons have served me well over the years.