IE in IT Horror Stories

In the spirit of Halloween, here are a number of IT horror stories for your enjoyment.

Note: all of these IT horror stories are from my personal experience or observations working with a variety of organizations and clients.

  • “We will pay you $XXX to come down and run this critical report. The only guy who ever ran that report just had a heart attack and we have to have the results. If you can figure out how we can run it some other way ourselves, the price tag is XXX more.”
  • “The low cost software we installed is actually just the framework. You have to pay them to program it with the workflow. That’s extra.” “How much extra?” “More than the cost you paid for the software application in the first place.”
  • “Yes, we can use it for activity based costing, but we have to set up the resources in the application in order to use ABC. And no, the software setup does not include that already.”
  • “I need your help. I spent all day in training, but I don’t know how to log in.”
  • “The testing didn’t include that because we saved time running it through the happy path.” (Testing only included proper workflow and routing, not mistakes people were likely to make.)
  • “I think it will be in the manual. Here’s the manual,” as I was handed a 600 plus page book.
  • “The files are missing.” “Can you restore them from the backup?” “We think they were deleted before the last backup, so they aren’t in the latest backup.”
  • “In response to questions that came up in training, we’ve emailed out a copy of the user guide.” I opened it to see the rough outline I’d written and asked for the trainers to review.
  • “We can’t delay release due to errors found in testing, we can’t afford to delay the release again!”
  • “Can’t you drop more things from the test plan so testing can fit the schedule?”
  • “The guy they assigned to package it has never done this before.”
  • “I did read your tech support documentation on this issue, and it didn’t answer my question.”
  • “We imported the data and found X% have these character issues. Can you create a list of it so we can create a quick clean-up script?”
  • “I’m calling this phone number because your main customer service number only gives me a message to go to your website, but the problem with the website is that it is down.”
  • “This is outlined in the lessons learned in the knowledge database.” “You can’t expect anyone to read that.”
  • “The software release can’t go in that week because the only guy who can do it is taking that month off.”
  • “I have to email you personally, directly, because the general email to the tech support group bounced.”
  • “The user called; the file is there now, but it is upside down and backwards. So how do we fix that?”
  • “Before you refer me to your first level tech support for this issue, let me inform you that I work for tech support here, and this error I’m reporting isn’t for one user – it is for all of them.”

 

Knowledge capture and redundancy in critical skill sets, adequate planning for tests combined with thorough testing, redundancy in backing up essential data, thorough documentation of technical support accessible to as wide an audience as possible, project planning for IT that includes all necessary steps and multiple channels for reaching appropriate levels of IT support are all necessities to avoid horror stories like these.

Advertisements