April 21, 2007
Change Management and the critical+++++ AnomalyThe severity of the reported anomalies is likely to be a major driver of your maintenance organization.Francisco Torres
Real-life examples of what can go wrong with your change management system -- and hard-won advice about what you can do about it.
Francisco works for GMV Aerospace and
Defence as project manager, lately involved in several projects and studies for the European Space
Agency. He can be contacted at francisco.to@gmail.com.
Running a maintenance organization isn't easy. It is usually a balancing act to get the most out of limited available manpower, and prioritizing is the name of the game. In this article, I share some real-life examples of what can go wrong with your change management system, and offer some hard-won advice about what you can do to prevent it.
Back in the late '90s, I was doing maintenance of a large mission-critical software system. Users would use a database to enter the anomalies they found in system operations, which would then be faxed to us as an "anomaly report" (AR). I remember there was one single field in the AR that was of most interest to us -- the severity. Default-allowed values for this field were:
Clearly, this field would determine the acceptable response time to fix the anomaly, and in turn the priorities in our maintenance organization.
Which is why we were shocked one day when such an AR came out of the fax machine and the severity field read "critical+++++." There was no doubt. This had to be a real showstopper (and it was). But at that moment, it was also apparent that users had been abusing the critical category in the past. So that when they came across an actual blocking problem, critical was devoid of its intended meaning and they had no other way to step up a notch than to use "critical+++++" for such an anomaly. In this article, I outline some of the reasons why this misuse of AR severities happened, and what can be done to prevent it. 
|
 |
|
|||||||||||||||||||||||||||||
|
|
|
