Standards-Based, Process-Driven Continual Service Improvement

Written by Paul Fordiani

originally published on HDI.

One of the recurring issues consultants experience during their long careers, is the eventual abandonment of Continual Service Improvement (CSI) efforts. There seems to be a point at which CSI crashes from lack of progress. In Gartner’s Hype Cycle, this is the “trough of disillusionment,” where initial giddiness at success rapidly plummets to extreme anguish. All too frequently, CSI efforts are abandoned at this point.

One of the significant factors influencing this decline is the difficulty in answering the question, “What now?” In other words, you’ve hit your initial targets, but what you’ve done so far doesn’t become integrated into normal behavior. Your improvement “project” has become a thing unto itself. Once you hit your initial success, the project ends. So, by not integrating improvement activities into “normal” operations, you stop getting better. As a result, you have failed!

My guiding principle for CSI efforts is to be clear and precise: If you can’t properly define, you’ll never be precise; if you can’t be precise, you can’t be efficient; if you can’t be efficient, you’ll never improve.

Clearly define requirements, clearly define activities and tasks, clearly determine desired outcomes, and precisely measure performance.

In this article, I will outline an approach to mitigate the most common factors for abandonment using a standards-based, process-driven methodology. In this method, the standards define a requirement, and the process describes the methods taken to meet the requirement. The standard says, “You shall,” and the process answers, “We will.” Although there is very little flexibility in the standard, there is tremendous flexibility in how you can organize your activities and tasks to meet the standard. We incorporate some aspects of CMMI, ISO 20000, ITIL, and some Agile-like implementation aspects in our method.

A “gumption trap” is an event or mindset that can cause a person to lose enthusiasm from starting or continuing a project. Author Robert M. Pirsig created this term in his novel, Zen and the Art of Motorcycle Maintenance. The top CSI gumption traps are:

1. CSI is hard—it’s at CMMI Level 5
2. CSI efforts lack clarity and precision
3. Success “not baked in”
4. Organizational inertia
5. Improvement implies poor performance

To overcome these gumption traps, we leverage standards and processes to make a CSI program successful and sustainable. In the CSI world, we refer to “sustainment” as “keeping the momentum going.” We want to continually mature, both in the scope and in the span of control. The scope refers to the projects, programs, or processes subject to CSI. By the span of control, we mean the level to which management behavior is exhibited in implementing governance over the organization’s activities. We keep the momentum going by modifying the intermediary targets and the specific activities and tasks that are performed, but not the requirement to get a little better every cycle.

The overall approach is to design a phased implementation—capability-based milestones rather than calendar-based milestones. A vision or a goal statement is recommended for each phase. For example, “At the end of this phase, we will have a documented procedure for recording all incidents and will have evidence of compliance with the requirement to do so.”

The issues or challenges listed above are related. Fortunately, the solutions described below are also related and mutually supportive.

CSI Is Hard

The primary reason CSI is so hard is the scope of activities seems to expand with progression. It appears that everything has to be controlled, managed, measured, and improved. This becomes overwhelming. The focus often devolves into spending too much time putting controls in place and not enough time figuring out organizational behaviors and management activities. ISO 20000 provides very concrete requirements—specific “shall” statements—for management and integration activities. By making things concrete and by choosing a phased approach, new activities can be integrated easily, and ongoing activities can be optimized based on capabilities. This last bit will also help you gain successes, so that if progress in one area is slower than expected, your overall program isn’t threatened.

These are the key characteristics of each phase, per ISO 20000-5:

• Phase I: Immediate fix and stabilization efforts
• Phase II: Begin to anticipate future situation based on trends
• Phase III: Sustain and continually improve performance (operations and process)

The primary benefit of a phased implementation is your organization gains experience and confidence over time by implementing new things according to your proven ability to achieve them. This allows you to scale up the difficulty as you progress. In keeping with the scope and span discussion earlier, a Phase I check might be “I have completed the task, and the evidence is a completed ticket.” A Phase II check might be “I have completed the task and subtasks, and the evidence is a completed ticket.” A Phase III check might be “I have completed the two tasks and subtasks, and the evidence is a completed ticket, problem record, and known error record.” By this method, you expand the scope of the activity as you improve the span and quality of control.

From a development and implementation perspective, you can organize as an Agile-type project. The standard is used to define requirements, processes, and procedures—to include metrics, and reporting—as user stories added to the product backlog.

CSI Efforts Lack Clarity and Precision

CSI efforts bog down because they don’t know what to do next. Gartner’s “Hype Cycle” explains a lifecycle of technology adoption as a sine-wave-like curve through five phases. The initial phase is a sharply-upward reaching curve that they label the “peak of inflated expectations.” The second phase depicts a similar downward curve labeled the “trough of disillusionment.”Initial efforts at improvement are generally targeted at mitigating pain points. That’s not only acceptable, but it is also preferred. In fact, according to ISO 20000-5, reacting to service disruptions—pain—is the key characteristic of Phase I.

Once the pain is mitigated, improvement targets are not so clear. Let’s say you want to improve a service restoration target—everyone does—or an availability target. These aren’t the types of improvements that lend themselves to sustainment. They are other forms of pain points: one-off tasks that don’t change organizational behaviors. To keep the momentum going, you have to describe the target clearly and precisely define the improvement requirements. Without clarity and precision to define and measure the next activities, regression normally occurs. In many situations, the organization has decided that its approach is to define processes and then buy an ITSM tool. Once the tool is in place, improvement stops. But all you did with your tool is automate your processes.

ISO 20000-5: Exemplar implementation plan for ISO/IEC 20000-5 is a fabulous resource. It lays out the objectives and characteristics of each phase and lays out the line-item process activities and tasks into each phase for implementation. I call this the “small bang” implementation. Your improvement starts with the critical parts of an integrated and sustaining process reverence model for performing activities and tasks. As your capabilities grow as demonstrated by compliance with the requirements, you expand scope and span. Part 5 is clear and precise, and, because of this, its implementation can be relatively straightforward. “You shall” followed by “We will,” plus evidence.

Success Is Not Baked-In

This gumption trap is directly related to the last. If you consider executing CSI to mean “implementing ITIL,” you have a simple issue:  ITIL is not prescriptive; you can’t be “compliant” with ITIL. ITIL doesn’t say, “Do that.” Most efforts don’t build success criteria into their programs. Few efforts present a picture of the definition of success or the “definition of done.” Most CSI efforts use a big bang rollout of processes. For example, incident management, followed by change, followed by problem, followed by the other 30 individual processes. This approach ignores the required interfaces between processes. Doing this means you’re baking-in process failure because critical dependencies are not addressed. A lack of good problem and change practices means that your incident management practices never really improve and sustain. Even though you have written the very best incident management process, the volume and severity of incidents never abate.

This issue is closely related to the clarity and improvement issue. The conditions that must be met for the organization to be successful at each phase need to be clear and precise. Using a standards-based approach ensures that the maturity roadmap is clearly defined at the start of the effort. Identifying the conditions as requirements means that as you build towards a compliance model, you are “baking-in” the desired success criteria.

Once requirements and success criteria are defined, and way-points for phased implementation are created, building for continual service improvement becomes much easier.

Organizational Inertia

This usually means resistance based on the “not the way we do it here” fallacy. Tradition is not a reason; it’s an excuse or lack of a reason. Standards provide the reason for doing things. They define the operational requirements of the organization. If you gain consensus and acceptance at the start, then you can keep the momentum going by questioning the rationale behind subsequent actions. “Does doing this help us meet the requirement?” By continually and programmatically questioning the rationale for actions, you can continually and programmatically improve. In many respects, problem management techniques are used to overcome inertia.

We often use the Five-Whys method for problem management investigations: “Why did this occur?” “Why did that occur,” and so on, becoming more granular into the root cause of the issue. Similarly, when implementing the phased approach, you rationalize each step at the level required by the phase, to include how you measure.

Moreover, the standards are written in clear, unambiguous language. As we addressed with the clarity and precision topic, having a well-defined statement of objectives from top to bottom of your improvement model reduces the inherent anxiety in organizational change efforts. Another buzz phrase I use is “No one likes change, but everyone loves progress.”

One other benefit of the previously mentioned small bang phased approach is that all of the relevant stakeholders are engaged concurrently and continually. This includes a laundry list of management responsibilities. In successful CSI efforts, a monthly top management review from both a service and process basis is a great tool for overcoming inertia. Especially when we are building and executing towards unambiguous targets, this keeps enthusiasm high. High enthusiasm is a major contributor to sustained success.

Improvement Implies Poor Performance

This is human nature 101: if you say “improve” to someone, they are going to think you are criticizing them. This usually causes an emotional response, and, as we know, overcoming an emotional response is exceedingly difficult. You might see some resistance, some foot-dragging, some defensiveness. If you say someone has to improve, they perceive that they’ve always been a poor performer. This is a big gumption trap.

Again, our guiding principle is clarity and precision. For example, if you have a clear goal that at the end of Phase II the entire organization will be able to “anticipate service disruptions and provide a reliable service,” quoting from ISO 20000 Part 5, you have shifted the dialogue from individual performance to organizational performance. This subtle shift usually becomes a team-building event. Once the performance dynamic changes to the team rather than individual performance, you get a foundational drive for excellence. By definition, this keeps the momentum going. Then, all you have to do to sustain is adjust targets and incentives over time.

Overcome the Gumption Traps

Use these five key takeaways to overcome the gumption traps:

1. Understand that true continual service improvement is difficult because of complexity, scope, and scale. Use specific requirements based on unambiguous and irrefutable standards, and implement the key components over time.
2. Be clear in your identification of requirements, gain acceptance from the stakeholder community, and be precise in your measurements. “You shall, and we will.”
3. Reinforce the prior two items by writing to the requirement using ITIL and a delivery approach like Agile. Ensure line-item accountability and measurement.
4. Overcome tradition by gaining acceptance that the shall statements are valid and worthy as improvement targets. Include all stakeholders to gain consensus. Build capability over time and introduce “change” as “progress.” Include management review at critical way-points.
5. Take personality out of the equation. Focus on team goals and performance targets rather than individual targets. Layout the road map for success, and progress according to demonstrated capability.