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:
- Disbelief: "Someone actually thought this was a good idea?"
- Head banging: "Will I ever get all the bubble gum scraped off, and the kite string untangled from these systems?"
- Self talk: "It will be okay. Someday it will all be fixed. It will be okay. One day users will...."
- Acceptance/resignation: "This is what they pay me for."
- 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.
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!