Deming's 7 Deadly Quality Diseases

Often, when we talk about implementing IT Service Management we refer to one of the Founding Fathers of the Quality Management movement, Dr. W. Edwards Deming. Most people focus on the Deming Cycle of Plan-Do-Check-Act. Perhaps lesser known but just as important is the fact that Dr. Deming spoke of the changes needed within an organization’s culture to make the Deming Cycle work to its greatest effectiveness.

Dr. Deming wrote and spoke of Seven Deadly Diseases that infect an organization’s culture and prohibit it from truly succeeding in achieving quality for the customer.

• Lack of constancy of purpose: You must remain focused on doing the right things because they are the right things to do for your customer and to achieve quality. ITSM is not a fad it is a way of behaving.
• Emphasis on short-term profits: Cutting costs can bring short-term profits and are easy to achieve. But cutting costs can only go on for so long, before you have cut to the bone and have nothing left to cut.
• Evaluation by performance, merit rating, or annual review of performance: Management by objectives ends up focusing on the objectives and not on the management. It is about “hitting the numbers” and not improvement.
• Mobility of management: When management changes jobs constantly there is no continuity or constancy of purpose. Each time a new leader comes in, the efforts of quality go back to square one.
• Running a company on visible figures alone: Everything that can be counted does not count, everything that counts cannot be counted—look for hidden information
• Excessive medical costs: Ensuring that workers are healthy to help deliver quality helps control costs.
• Excessive costs of liability: Lawyers are part of the problem not part of the solution according to Deming

Each of these Seven Deadly Diseases can destroy a company’s ability to focus on quality and to conform to the requirements and needs established by the customer. These Diseases also reflect on the need to focus on Value on Investment (VOI) as an umbrella over Return on Investment (ROI). We must maximize what the customer gets back for what they put into the delivery of service. The Diseases also reflect Dr. Deming’s belief that strong leadership and well built processes are the most effective and efficient way of achieving quality.

When we put long-term thinking and focus on value before short-term thinking and returns then we can achieve quality and increase customer satisfaction. When customers are satisfied with your delivery of services then they will continue to seek you out as a provider. When you focus strictly on the bottom line, you will have a tendency to forget that the customer is really the key to your success. If no customers desire your products or services or see no value in them, they will be unhappy. Then your customers will seek other mechanisms (your competitors) to fulfill their needs.

As much as anything (and perhaps more) ITSM is about changing our thinking and our behavior to focus on the needs of customers, the value they seek and the quality needed to deliver on their requirements. The Seven Deadly Diseases show what happens when we take our eyes off the customer and focus on ourselves or strictly on the bottom line.

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket?

I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system.

With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?

Thanks, René W.

Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to describe a problem that has a documented root cause and a workaround. A “problem” is the cause of one or more incidents. It is understood that you may not know the cause of a known error or have a workaround initially.

ITIL suggests creating known error records “as soon as it becomes useful to do so.” What’s important to keep in mind is that a known error record, like any other record, can have any number of statuses. For example, a known error record could have a status of “detected” when it is first logged. A status of “informational” could be used to reflect that the known error is being investigated but neither a workaround nor a root cause has been identified. A status of “diagnosed” could mean you know the cause but do not yet have a workaround. A status of “resolved” could mean you have both a documented root cause and a workaround. A status of “closed” could mean that you’ve implemented a permanent resolution via the Change Management process. It’s up to your organization to define statuses as needed to reflect the activities within your Problem Management process.

An important benefit of logging and tracking known errors is a reduction in the time it takes to handle incidents. Whether the decision is made during testing to release something with known errors into the production environment, or the errors are detected after the system/application is live, the known errors should be logged and made available to Incident Management so that any recurrences can be more quickly diagnosed and fixed. Without such an interface, it is likely that you’ll waste effort re-diagnosing and re-resolving incidents.

As you are suggesting, you can also define statuses within Incident Management that reflect the relationship between problems/known errors and incidents. For example, some organization use a status of “resolved” when a workaround is delivered to “stop the clock” relative to service level reporting and to reflect the fact that service has been restored to the customer. These organizations often have a field or a link that they use to point to the actual known error record to minimize the rekeying of details. Some then use a status of “closed” to indicate the customer is satisfied. A status of “closed-unresolved” could be used; however, you would still want to ensure that your customer is satisfied with the information or workaround that you have provided. You would also still want to be able to report on those incidents as the number and impact of those incidents should, over time, influence how you are prioritizing the handling of your problems/known errors.

I hope this helps Rene. Please let us know if you have additional questions.

Service Desk Metrics

Earlier in my career I had the pleasure of managing a Service Desk. This function is the unsung hero of IT support!

We had a multitude of measurements and metric that were taken every day and then meticulously charted, reported and analyzed. At the time it’s what we did.

I recently had the opportunity to visit my old Service desk and found to my horror, that many of these metrics were no longer being used. I also was informed that customer satisfaction had not dropped significantly and that some of the KPI still being measured were well within an acceptable range. Now that I no longer am in the thick of it, I took some time to really think about what was it we were measuring and what did it really mean. As an organization we did all of the industry best practices measurements.

• Speed of answer
• Call duration
• Number of calls per day/week/month and analyst
• Abandoned calls
• Number of tickets opened versus number of tickets closed
• Percentage 1st call resolved
• Customer satisfaction survey

 After talking with my former staff, what began to emerge was that with the limited resources that were now available for the management of this process it was decided to limit these KPIs to what really impacted the customer. How was it decided what impacted the customer? They asked and not through a survey sheet but by talking with each and every customer that called or emailed. From the this response, reporting was boiled down to several core KPIs that really mattered to the customers. In this difficult business environment, with seemingly less and less resources we must review what it is we do and ask “Does this provide value? Does this enhance the customer’s experience? Is it important to the delivery of our services? Communication and a willingness to continually ask do I provide value is the key to ongoing success.

Managing Data

Data is a critical asset of every business. It needs to be managed properly in order to deliver services effectively. If we do not manage our data, we will be maintaining and collecting data that is not needed. Data quality, integrity and security of information may be compromised. We are painfully aware of identity theft and the risk of unprotected data to our business. To effectively manage our information we must be able to answer the following questions:

• What data do we currently have, how is it classified, what if any are the security constraints?
• What data needs to be collected or created to support our business?
• What are our current and future needs for data storage and maintenance?
• Who will access the data, how will they access it?
• What are our disposal considerations, how long does the data need to be kept?

 In the ITIL Service Lifecycle, during requirements gathering, answering these questions is essential for the implementation of new or changed services. I have seen many new services fail because the management of data has not been addressed during Service Design. Best practice advice is to have a Data Management process that establishes policy and standards, provides expertise and makes it easier to handle the data aspects of new service. After all, our goal is to reduce risk to our business and to add value to the services we deliver to our customers.

The Service Design Package

I have gotten many questions about what value does the Service Design Package provide?

We first must understand that all design activities are triggered by changes in business needs or service improvements. In order to design and deliver IT services that meet the changing needs of the customers and the business, clear, concise and unambiguous specifications of the requirements must be documented and agreed.

The SDP is where we document and agree to

• Requirements – What the business wants and how they plan to use this new service. Define who all of the stakeholders are
•  Service Design – Functionality of this new or changed service (SOR). Service levels to be delivered (SLRs, SLAs). Operational management requirements (OLAs, Contracts). Overall design and topology. Defined outcomes and deliverables. 
• Organizational Readiness Assessment – Do we have the financial, technical, organizational resources and capabilities to meet the needs of the business? Have we assessed the business benefit this service will deliver?
• Service Lifecycle Plan – Overall plan to cover the five stages of the service lifecycle including details for transitioning, operation and CSI of the new service.
• Service Transition Plan – Overall transition strategy. Define objectives. State policy and do risk assessment.
•  Service Operational Plan – Overall operational strategy. Define objectives. State policy and do risk assessment
• Service Acceptance Criteria - Document to ensure that the service meets its expected functionality and quality. The service provider is ready to deliver and support the new service.

With this document in hand we can insure that the service delivered will meet the agreed needs of the customer and the business the first time with minimum of rework and interruption. It will insure that availability, capacity, security and continuity can be assured thereby delivering value to the business.