Software

Responding to IT mini crises involving KFC, Lotus, Adobe, and a contractor

Business lessons can come from the most unlikely of sources, as evidenced by a mini work crisis because of this week's Kentucky Fried Chicken promo. Jay Rollins outlines the five stages of a mini crisis and describes four situations that he refers to as geek social fodder.

Business lessons can come from the most unlikely of sources, as evidenced by a mini work crisis because of this week's Kentucky Fried Chicken promo. Jay Rollins outlines the five stages of a mini crisis and describes four situations that he refers to as geek social fodder.

-----------------------------------------------------------------------------------

In IT, you occasionally have a mini crisis that will put a smile on your face -- once the dust settles and you can look back on it. But there are five distinct stages you must go through before you can reflect on the situation with amusement:

  1. Disbelief: "Someone actually thought this was a good idea?"
  2. Head banging: "Will I ever get all the bubble gum scraped off, and the kite string untangled from these systems?"
  3. Self talk: "It will be okay. Someday it will all be fixed. It will be okay. One day users will...."
  4. Acceptance/resignation: "This is what they pay me for."
  5. Geek social fodder: Chuckle and say, "No, I am not kidding. That actually did happen."

Tales from four IT mini crises

Here are four situations I've experienced that now fit into the geek social fodder stage.

Restricting e-mail capabilities post-KFC promo

How many of you had an employee send an e-mail to the entire company this week about the free food promotion at Kentucky Fried Chicken? To prevent this from happening in the future, we limited users to only e-mail to distribution groups they belong to. An additional precaution we took was to set the maximum number of e-mail addresses an employee can send to at any one time. Ideally, if an e-mail goes out to the maximum limit, we can intervene before it gets sent to the next group of individuals.

Moving off a Lotus 1-2-3 spreadsheet

In a previous company, we had a user whose entire job focused on calculating take out percentages from transactions (i.e., for every transaction, take 20%). It was done in a Lotus 1-2-3 spreadsheet. Needless to say, that was an enterprise-class function done on a non-supported desktop application. The user tried to import it to Excel once or twice, but it didn't work correctly. Because it was so important to the company, everyone told us to leave it alone. For that exact same reason, we had to get involved.

We had to convince management of the risks to the organization, which didn't take very long because the risks were pretty obvious. Next, we budgeted for a good developer to move it to a database application with enterprise-level transaction control. Again, this wasn't that difficult. The hardest part was getting the user whose job it was to manage that process to transition to the new system. The challenge posed by the user was that his job, which normally took eight hours a day five days a week would now take 20 minutes a day.

Licensing issues with Adobe 8 and Adobe 9

We recently had similar issues with Adobe. Apparently, forms created in Adobe Acrobat 8 Professional cannot be used with Adobe Acrobat 9 Professional. I'm not sure why that is the case, but it is not a smart move on Adobe's part. We ended up having a "the sky is falling" moment when we discovered that Adobe 9 licenses cannot be used for Adobe 8 installations. So we have two choices: hire an Adobe forms guru to transition the forms every time a new version comes out or transition to a Web-based SharePoint form.

I really dislike those types of licensing games some software vendors play. When vendors do not provide this level of backwards compatibility, it says to me that we will incur significant future costs if we stay with this vendor. My solution is to remove the vendor from the equation. Sorry, Adobe.

Putting a critical system in the hands of a contractor

At a previous company, a software package was purchased to manage a particular set of very important transactions. The software vendor had since stopped supporting the application. So every year, the company had to reach out to the original developer of the system (one person) to make changes and/or update features. This developer had a full-time job, so he could only work on the changes or issues after 5:00 P.M., and we had to work around his somewhat significant vacation schedule.

If this critical system crashed, IT had a service level agreement of two weeks to get the system restored and up and running and even that was questionable. Again, it was very easy to communicate the risks and get agreement that we need to make a change, but making the actual change proved to be a momentous undertaking.

Share your examples

I'm interested in hearing about your geek social fodder. Please share your stories in the discussion.

Get leadership tips in your inbox TechRepublic's IT Leadership newsletter, delivered Tuesday and Thursday, features blogs, white papers, and other resources for IT managers and CIOs. You'll receive advice on staffing, morale, dealing with day-to-day challenges, and much more. Automatically sign up today!
2 comments
Dave Stromfeld
Dave Stromfeld

Jay, Thank you for bringing this issue to my attention. I?m sorry for the trouble this has caused you. I?m not aware of any issues that would prevent a PDF form created with Acrobat 8 from being used with Acrobat 9. We try to maintain forward compatibility of all older PDF files. PDF files created with Acrobat 1 should open and behave correctly in our current Acrobat 9 version and we do extensive testing to maintain this. It would be great to get a copy of your form so we can take a look at it and see if we can help you determine what may be going wrong. I?ve sent you a separate email with my contact information. Sorry again for the inconvenience. Regards, Dave Stromfeld Acrobat Product Manager Adobe Systems

mdhealy
mdhealy

At my employers we sometimes would have an email cascade. Somebody would accidentally or intentionally send an email message to the whole company, which would be followed by replies saying to the whole company "please don't do this," followed by... Finally they put restrictions in place on who could send to the company-wide and division-wide mailing lists.

Editor's Picks