Fire Drill

Yesterday it was a fire drill to problem solve one of the web pages. The site was obviously down and an SA and supervisor were negotiating the level of problem solving necessary to get the system back up. As this chaos carried on a customer of the IT support group called a technician for support. One individual stated, rather bluntly, "It's not my job to fix your html code." The person on the other end said something and the support person responded, "I don't know who does that for you. You'll have to deal with that in your department."

The next day, it got even more interesting. One SA was on the phone describing a system that was apparently undergoing an upgrade. He stated that, although he's not familiar with the system and doesn't know what it does, he's seen "parts of it" around for a long time. He alerted the party on the other end of the phone that if an upgrade is done to one box, based on what he's found, the same upgrade must be done on another box. But he doesn't have access to the "other" box to
do the upgrade and has no idea who does have access. In the course of the conversation, this SA described what the upgrade is "apparently" intended to do. There were also conversations about who owned the box, in the context of, "So and so's name is all over this...is he the one to contact?..."

Shortly after this exchange, the supervisor of this same SA asked what was done yesterday to fix (yet) another problem they dealt with previously. Apparently the fix was not documented and was just "top-of-mind" in the SA's memory. Now, let's think about this for a moment. What would have happened if that SA had been off work? Can you spell, "r-e-w-o-r-k"?

Later that same day a group of support folks gathered around to discuss the above upgrade(s). One technician stated that he would stay around after the upgrade was implemented to see if there were any problems...something to the effect, "...In case anyone squeals..." Five or six folks were dscussing the change and not one of them seemed to have a definitive understanding of what might happen once the change was implemented.

In the four paragraphs above we've touched on:

• Configuration Management
  
• Change Management
  
• Incident Management
  
• Problem Management (and Structured Problem Solving)
  
• Release Management
  
• Service Level Management
  
• Service Desk, escalation, communication and basic customer service

Such a scenario is all too common in IT today but it goes to process capability of the people-process-technology evaluation. An assessment would certainly prove the process component is "ad-hoc" at best.

The purpose of an assessment is to:
1.) Establish a baseline and
2.) Provide the data required to build an implementation based on the positive aspects of the current processes.

But, given the sub-optimization in evidence here, any baseline would vary significantly
depending upon the group engaged in the assessment exercise. Thus the need to target a higher level sponsor to realize the benefits of an implementation.