The greatest feat of Engineering ever was when Dr. Demming created his DMAIC method for increasing quality. His genius allowed the Japanese car manufacturers to dominate the industry (much to the chagrin of the Big 3 who spurned him).
The impact of Dr. Demming's method was to increase the importance of Metrics. Metrics is basically assigning numbers (to data) to represent quality "levels". By using the DMAIC method, you can change those metric numbers into "better" numbers - thus increasing quality ("better" can be higher or lower numbers depending on the meanings).
There are 3 issues associated with developing Metrics:
Most companies use a "trouble ticket" system where users that need help create a ticket that gets sent to the IT support team. The ticket is then updated by the support team until the issue is fixed and the ticket is "closed".
The ticketing system contains a wealth of data on timings and numbers and categories.All of this data is very attractive to use in Metrics. Ideally, by collecting ticketing Metrics and applying Demming's DMAIC process - you can improve your IT support. This is what IT Departments are aiming for.
But remember Rule #2 - meanings can be subjective. What happens is that the same Metrics are used in different ways depending on your level in the IT Department. Contract companies that provide 1st level support use number of tickets Metrics for how much they charge for their services. IT management of course, wants to lower the number of tickets so that they will pay less money.
So Rule #3 comes into the play when IT management sets goals/targets of reducing numbers of tickets. People's jobs and paychecks depend on these goals so there is lots of pressure to make those numbers (punishment for failure).
So what happens when there are punishments for using the ticketing system? Administrators stop using it (go around it). They (verbally) tell their customers/users to call them or email them or use some other communication OTHER THAN using the ticketing system for their problems - so the Admins can make their (artificial) numbers. The IT management (all the way up) keep an eagle eye on the numbers and report success (without knowing what the Administrators are doing). You have to understand that these numbers are EVERYTHING to IT management - they base everything they do around those numbers. Every meeting they have they discuss those numbers. They apply statistical analysis to look for trends in the numbers. But the numbers are useless!
Not only are the numbers useless for reporting, they are also useless for DMAIC. Without good data, how can you improve the quality?
In the end, the entire IT Department lives a lie while nothing can be done to improve the process - perpetuating the RatRace.
The impact of Dr. Demming's method was to increase the importance of Metrics. Metrics is basically assigning numbers (to data) to represent quality "levels". By using the DMAIC method, you can change those metric numbers into "better" numbers - thus increasing quality ("better" can be higher or lower numbers depending on the meanings).
There are 3 issues associated with developing Metrics:
- Metrics can be straightforward to calculate - but many are difficult to create.
- The "Meaning" of Metrics can be subjective.
- Creating (perverse) incentives for good (or punishment for bad) Metrics DESTROYS the meaning and utility of Metrics.
Most companies use a "trouble ticket" system where users that need help create a ticket that gets sent to the IT support team. The ticket is then updated by the support team until the issue is fixed and the ticket is "closed".
The ticketing system contains a wealth of data on timings and numbers and categories.All of this data is very attractive to use in Metrics. Ideally, by collecting ticketing Metrics and applying Demming's DMAIC process - you can improve your IT support. This is what IT Departments are aiming for.
But remember Rule #2 - meanings can be subjective. What happens is that the same Metrics are used in different ways depending on your level in the IT Department. Contract companies that provide 1st level support use number of tickets Metrics for how much they charge for their services. IT management of course, wants to lower the number of tickets so that they will pay less money.
So Rule #3 comes into the play when IT management sets goals/targets of reducing numbers of tickets. People's jobs and paychecks depend on these goals so there is lots of pressure to make those numbers (punishment for failure).
So what happens when there are punishments for using the ticketing system? Administrators stop using it (go around it). They (verbally) tell their customers/users to call them or email them or use some other communication OTHER THAN using the ticketing system for their problems - so the Admins can make their (artificial) numbers. The IT management (all the way up) keep an eagle eye on the numbers and report success (without knowing what the Administrators are doing). You have to understand that these numbers are EVERYTHING to IT management - they base everything they do around those numbers. Every meeting they have they discuss those numbers. They apply statistical analysis to look for trends in the numbers. But the numbers are useless!
Not only are the numbers useless for reporting, they are also useless for DMAIC. Without good data, how can you improve the quality?
In the end, the entire IT Department lives a lie while nothing can be done to improve the process - perpetuating the RatRace.
