I work as a system engineer in the travel industry. To save costs, the Suits on the business side are constantly engaging external contracting firms to develop applications and complete smaller projects. The owner of one firm, "Tom," had impressed them enough to be brought on to deliver and maintain a sales application.
My role was to provide two systems and turn them over to Tom's firm to complete the work. I completed my part, then handed the systems over to the contractors. Soon, the trouble started.
[ Get a $50 American Express gift cheque if we publish your tech experiences. Send your story of a lesson learned, of dealing with frustrating coworkers or end-users, or a story that illustrates a relevant takeaway to today's IT profession to offtherecord@infoworld.com. | Get a new tech tale delivered to your inbox every week in InfoWorld's Off the Record newsletter. ]
I received a call from Tom that a simple command was not working correctly. My immediate thought was that perhaps there was a hardware or connectivity issue. Tom was running a command to list files inside a particular folder, but no files were being listed. I did a quick check and everything seemed normal, then dug a little deeper and discovered the folder was empty. Tom did not know how the utility worked and assumed it would inform that the directory was empty rather than returning nothing. He apologized and explained that he was very new to this platform.
A couple of days later, I received another call from Tom. He informed me that the network connectivity was extremely slow between the two systems while copying files. We had seen network glitches before, so I approached the problem by reading the logs, checking the configurations, and doing the basic troubleshooting. Everything seemed normal. I questioned Tom some more. What kind of throughput were you getting? Did it just start happening?
After five minutes, I realized the problem.
The two systems were positioned right next to each other in the data center. Tom, however, was hundreds of miles away and accessed the systems over an Internet link to his home. Rather than copying the files from one system to another across the local connection directly, he was moving the files through hundreds of miles and untold number of routers between the data center, to his slow home connection, through his laptop, and back across hundreds of miles to the other system.
Over the next few months, it got worse. Tom, a purported expert in his field, would inform that system errors were causing delays in the schedule. Tom's firm was supposed to maintain the systems, but after exhausting their meager troubleshooting skills would call me or someone else in the group. The problems inevitably turned out to be because of Tom's lack of experience. I resolved one two-week-old problem that had stumped him by doing an online search for the error he reported and literally following the first link.
Most recently, Tom managed to delete the entire configuration of one system, causing two days of downtime.
At this point, the best solution is to fire the contractor and start from scratch, but so far our recommendations and concerns have fallen on deaf ears. The systems are now in such a sad state that they could not even pass our compliance requirements. Alas, the application is quite entrenched, so the systems cannot be brought offline to fix the dozens of problems. After repeated excuses from Tom and his employees, I've learned to keep detailed documentation. The sad part is that Tom's firm may be an "eternal" contractor through the lifecycle of the application and may never leave.
We've been pushed to run IT as a business. This approach may work for budgeting, but it falls apart quickly if not managed with a grasp of the technical aspects. IT's role is not only to engineer solutions requested by the business side, but also to tell them when a project is unworkable. That is, say no and say no loudly when the nonsense meter is going crazy. In this situation, I can only hope that eventually we'll be heard.
This story, "We're paying the contractor for what?" was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.