It starts with a basic question: What is a closed-loop system? Before answering this question, you might respond by asking, "That sounds a bit technical. What does the concept of a closed-loop system have to do with an article about ITIL lifecycle adoption? What does a closed-loop system have to do with ITIL, period?" The answers might surprise you. To avoid a technical answer, we need a little background and four definitions drawn from ITIL v3.

First, we need to establish a frame of reference: Typically attempts at implementing ITIL processes or doing ITIL fail. One of the purposes for this article is to make that point clear. For now, ITIL v3 isn't about process (though there are clearly more than 20 processes documented in the five core books). This makes it easy to fall into the mental trap thinking that ITIL is merely doing or implementing the documented process. That's only a very small part of the much larger picture. ITIL isn't the end. Implementing or doing ITIL suggests it is. No, the real goal isn't ITIL! ITIL is a descriptive framework that describes best practice for IT service management (ITSM).

ITIL v3 takes everything in prior versions of ITIL (plus processes and functions that existed in many organizations but weren't formally documented in v2) and reorganizes the information around the concept of lifecycles. This recognizes the realities that services are conceived, created, transitioned into operation, and eventually outlive their usefulness only to be retired. Existing services are subject to change either to correct a problem or to add (improve) functionality. From the time the service is approved and chartered, it's subject to potential improvement.

Processes support services ― not the other way around. This is an important point. ITIL isn't the goal, it's the use of the ITIL best practice processes that allow an organization to work toward IT service management; with ITIL processes supporting IT-based services.

Just to make the point, ITIL processes don't exist in isolation. For example, Demand Management (documented in the Service Strategy book) works with and feeds information to Capacity Management (documented in the Service Design book). Demand, as the Service Strategy book suggests, pulls capacity. In fact, the book contains the following sentence: "Demand and capacity are far more tightly coupled in service systems even when compared with just-in-time (JIT) manufacturing."

In other words, ITIL is about ITSM. The processes it describes are not the end, they are set in the context of understanding service lifecycles. But this raises questions about four specific areas; the four definitions we need to understand the closed-loop system: service, service management, lifecycles, and service management lifecycles.

Let's take them one at a time:

ITIL v3 defines a service as: "A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks." What does this mean?

Twenty-five years ago Peter Drucker wrote in the book Innovation and Entrepreneurship, that "[q]uality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for." A bit later in the book is this sentence: "Customers pay only for what is of use to them and gives them value. Nothing else constitutes 'quality'."

According to Drucker it's the customer belief (or perception) of quality that's important. This means IT needs to understand the outcomes, including appropriate levels of service that customers want/need IT to facilitate. What the customer values is the link to quality. In fact, the ITIL glossary defines quality as: "The ability of a product, service, or process to provide value."

What about the costs and risks part in the definition of service? Consider you arrive home and it’s dark. You enter the house and flip the switch and expect the lights to come on. You don’t care about what your electric utility had to do to generate, distribute or get into your home. You just want light when you flip the switch. If there happens to be a power failure it’s their responsibility, not yours. IT customers view IT as a service provider, in exactly the same way you view your electric utility. They just want to push (or click) a button and have things work.

ITIL defines service management as: "A set of specialized organizational capabilities for providing value to customers in the form of services."

Again, there's the concept of value.

What about the, "specialized capabilities" part, what does that mean? Among other things, it refers to crafting a cohesive, coordinated and controlled mechanism to discover, understand, and deliver services that facilitate the right outcomes while removing constraints (costs and risks) for customers.

Consider the earlier comment about the link between Demand and Capacity management and what it suggests is that the, "specialized capabilities," include this type of communication and coordination between processes. The concept of specialized organizational capabilities also precludes process silos, processes that exist in isolation, processes that are implemented as discrete processes devoid of any lifecycle considerations, even if they use ITIL as the source.

This is one of the reasons I suggested that implementing processes isn't the goal for ITIL. The same types of relationship discussed about demand and capacity management exist between every other ITIL documented process.

Moving on ― the definition for a lifecycle: "The various stages in the life of an IT service, configuration item, incident, problem, change, etc. The lifecycle defines the categories for the status and the status transitions that are permitted."

The lifecycle definition suggests a degree of control (defined categories, status, and status transitions). In other words, we see the concept of control inherent in both the concepts of service management and lifecycle ― a type of referential integrity.

We're almost ready to get back to the closed-loop system question but we still need the definition for service management lifecycle: "An approach to IT service management that emphasizes the importance of coordination and control across the various functions, processes, and systems necessary to manage the full lifecycle of IT services. The service management lifecycle approach considers the strategy, design, transition, operation and continual improvement of IT services."

Now we have it explicitly. When considered across the lifecycle, service management includes coordination and control between functions (teams or groups of people and their tools), processes (structured and measurable sets of activities designed to produce a specific outcome for a stakeholder), and systems (one or more related things that work together in a connected way to achieve an overall objective).

It starts with a basic question: What is a closed-loop system? Before answering this question, you might respond by asking, "That sounds a bit technical. What does the concept of a closed-loop system have to do with an article about ITIL lifecycle adoption? What does a closed-loop system have to do with ITIL, period?" The answers might surprise you. To avoid a technical answer, we need a little background and four definitions drawn from ITIL v3.

First, we need to establish a frame of reference: Typically attempts at implementing ITIL processes or doing ITIL fail. One of the purposes for this article is to make that point clear. For now, ITIL v3 isn't about process (though there are clearly more than 20 processes documented in the five core books). This makes it easy to fall into the mental trap thinking that ITIL is merely doing or implementing the documented process. That's only a very small part of the much larger picture. ITIL isn't the end. Implementing or doing ITIL suggests it is. No, the real goal isn't ITIL! ITIL is a descriptive framework that describes best practice for IT service management (ITSM).

ITIL v3 takes everything in prior versions of ITIL (plus processes and functions that existed in many organizations but weren't formally documented in v2) and reorganizes the information around the concept of lifecycles. This recognizes the realities that services are conceived, created, transitioned into operation, and eventually outlive their usefulness only to be retired. Existing services are subject to change either to correct a problem or to add (improve) functionality. From the time the service is approved and chartered, it's subject to potential improvement.

Processes support services ― not the other way around. This is an important point. ITIL isn't the goal, it's the use of the ITIL best practice processes that allow an organization to work toward IT service management; with ITIL processes supporting IT-based services.

Just to make the point, ITIL processes don't exist in isolation. For example, Demand Management (documented in the Service Strategy book) works with and feeds information to Capacity Management (documented in the Service Design book). Demand, as the Service Strategy book suggests, pulls capacity. In fact, the book contains the following sentence: "Demand and capacity are far more tightly coupled in service systems even when compared with just-in-time (JIT) manufacturing."

In other words, ITIL is about ITSM. The processes it describes are not the end, they are set in the context of understanding service lifecycles. But this raises questions about four specific areas; the four definitions we need to understand the closed-loop system: service, service management, lifecycles, and service management lifecycles.

Let's take them one at a time:

ITIL v3 defines a service as: "A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks." What does this mean?

Twenty-five years ago Peter Drucker wrote in the book Innovation and Entrepreneurship, that "[q]uality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for." A bit later in the book is this sentence: "Customers pay only for what is of use to them and gives them value. Nothing else constitutes 'quality'."

According to Drucker it's the customer belief (or perception) of quality that's important. This means IT needs to understand the outcomes, including appropriate levels of service that customers want/need IT to facilitate. What the customer values is the link to quality. In fact, the ITIL glossary defines quality as: "The ability of a product, service, or process to provide value."

What about the costs and risks part in the definition of service? Consider you arrive home and it’s dark. You enter the house and flip the switch and expect the lights to come on. You don’t care about what your electric utility had to do to generate, distribute or get into your home. You just want light when you flip the switch. If there happens to be a power failure it’s their responsibility, not yours. IT customers view IT as a service provider, in exactly the same way you view your electric utility. They just want to push (or click) a button and have things work.

ITIL defines service management as: "A set of specialized organizational capabilities for providing value to customers in the form of services."

Again, there's the concept of value.

What about the, "specialized capabilities" part, what does that mean? Among other things, it refers to crafting a cohesive, coordinated and controlled mechanism to discover, understand, and deliver services that facilitate the right outcomes while removing constraints (costs and risks) for customers.

Consider the earlier comment about the link between Demand and Capacity management and what it suggests is that the, "specialized capabilities," include this type of communication and coordination between processes. The concept of specialized organizational capabilities also precludes process silos, processes that exist in isolation, processes that are implemented as discrete processes devoid of any lifecycle considerations, even if they use ITIL as the source.

This is one of the reasons I suggested that implementing processes isn't the goal for ITIL. The same types of relationship discussed about demand and capacity management exist between every other ITIL documented process.

Moving on ― the definition for a lifecycle: "The various stages in the life of an IT service, configuration item, incident, problem, change, etc. The lifecycle defines the categories for the status and the status transitions that are permitted."

The lifecycle definition suggests a degree of control (defined categories, status, and status transitions). In other words, we see the concept of control inherent in both the concepts of service management and lifecycle ― a type of referential integrity.

We're almost ready to get back to the closed-loop system question but we still need the definition for service management lifecycle: "An approach to IT service management that emphasizes the importance of coordination and control across the various functions, processes, and systems necessary to manage the full lifecycle of IT services. The service management lifecycle approach considers the strategy, design, transition, operation and continual improvement of IT services."

Now we have it explicitly. When considered across the lifecycle, service management includes coordination and control between functions (teams or groups of people and their tools), processes (structured and measurable sets of activities designed to produce a specific outcome for a stakeholder), and systems (one or more related things that work together in a connected way to achieve an overall objective).

It starts with a basic question: What is a closed-loop system? Before answering this question, you might respond by asking, "That sounds a bit technical. What does the concept of a closed-loop system have to do with an article about ITIL lifecycle adoption? What does a closed-loop system have to do with ITIL, period?" The answers might surprise you. To avoid a technical answer, we need a little background and four definitions drawn from ITIL v3.

First, we need to establish a frame of reference: Typically attempts at implementing ITIL processes or doing ITIL fail. One of the purposes for this article is to make that point clear. For now, ITIL v3 isn't about process (though there are clearly more than 20 processes documented in the five core books). This makes it easy to fall into the mental trap thinking that ITIL is merely doing or implementing the documented process. That's only a very small part of the much larger picture. ITIL isn't the end. Implementing or doing ITIL suggests it is. No, the real goal isn't ITIL! ITIL is a descriptive framework that describes best practice for IT service management (ITSM).

ITIL v3 takes everything in prior versions of ITIL (plus processes and functions that existed in many organizations but weren't formally documented in v2) and reorganizes the information around the concept of lifecycles. This recognizes the realities that services are conceived, created, transitioned into operation, and eventually outlive their usefulness only to be retired. Existing services are subject to change either to correct a problem or to add (improve) functionality. From the time the service is approved and chartered, it's subject to potential improvement.

Processes support services ― not the other way around. This is an important point. ITIL isn't the goal, it's the use of the ITIL best practice processes that allow an organization to work toward IT service management; with ITIL processes supporting IT-based services.

Just to make the point, ITIL processes don't exist in isolation. For example, Demand Management (documented in the Service Strategy book) works with and feeds information to Capacity Management (documented in the Service Design book). Demand, as the Service Strategy book suggests, pulls capacity. In fact, the book contains the following sentence: "Demand and capacity are far more tightly coupled in service systems even when compared with just-in-time (JIT) manufacturing."

In other words, ITIL is about ITSM. The processes it describes are not the end, they are set in the context of understanding service lifecycles. But this raises questions about four specific areas; the four definitions we need to understand the closed-loop system: service, service management, lifecycles, and service management lifecycles.

Let's take them one at a time:

ITIL v3 defines a service as: "A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks." What does this mean?

Twenty-five years ago Peter Drucker wrote in the book Innovation and Entrepreneurship, that "[q]uality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for." A bit later in the book is this sentence: "Customers pay only for what is of use to them and gives them value. Nothing else constitutes 'quality'."

According to Drucker it's the customer belief (or perception) of quality that's important. This means IT needs to understand the outcomes, including appropriate levels of service that customers want/need IT to facilitate. What the customer values is the link to quality. In fact, the ITIL glossary defines quality as: "The ability of a product, service, or process to provide value."

What about the costs and risks part in the definition of service? Consider you arrive home and it’s dark. You enter the house and flip the switch and expect the lights to come on. You don’t care about what your electric utility had to do to generate, distribute or get into your home. You just want light when you flip the switch. If there happens to be a power failure it’s their responsibility, not yours. IT customers view IT as a service provider, in exactly the same way you view your electric utility. They just want to push (or click) a button and have things work.

ITIL defines service management as: "A set of specialized organizational capabilities for providing value to customers in the form of services."

Again, there's the concept of value.

What about the, "specialized capabilities" part, what does that mean? Among other things, it refers to crafting a cohesive, coordinated and controlled mechanism to discover, understand, and deliver services that facilitate the right outcomes while removing constraints (costs and risks) for customers.

Consider the earlier comment about the link between Demand and Capacity management and what it suggests is that the, "specialized capabilities," include this type of communication and coordination between processes. The concept of specialized organizational capabilities also precludes process silos, processes that exist in isolation, processes that are implemented as discrete processes devoid of any lifecycle considerations, even if they use ITIL as the source.

This is one of the reasons I suggested that implementing processes isn't the goal for ITIL. The same types of relationship discussed about demand and capacity management exist between every other ITIL documented process.

Moving on ― the definition for a lifecycle: "The various stages in the life of an IT service, configuration item, incident, problem, change, etc. The lifecycle defines the categories for the status and the status transitions that are permitted."

The lifecycle definition suggests a degree of control (defined categories, status, and status transitions). In other words, we see the concept of control inherent in both the concepts of service management and lifecycle ― a type of referential integrity.

We're almost ready to get back to the closed-loop system question but we still need the definition for service management lifecycle: "An approach to IT service management that emphasizes the importance of coordination and control across the various functions, processes, and systems necessary to manage the full lifecycle of IT services. The service management lifecycle approach considers the strategy, design, transition, operation and continual improvement of IT services."

Now we have it explicitly. When considered across the lifecycle, service management includes coordination and control between functions (teams or groups of people and their tools), processes (structured and measurable sets of activities designed to produce a specific outcome for a stakeholder), and systems (one or more related things that work together in a connected way to achieve an overall objective).

Let’s summarize where we are, and then we're ready for closed-loop.

Everything wrapped up in the concepts of service, service management, lifecycles, and service management lifecycles revolves around the organization developing the communication, coordination, and control for understanding and delivering on the quality/value proposition to the customer. How that is accomplished is what leads to understanding closed-loop systems.

The Service Strategy book says: "Control processes in which the value of the outcome has influence (with or without some delay) on the process input in such a manner as to maintain the desired value are closed-loop."

That's a bit tough to understand. A bit later in book is this: "Closed-loop solutions, however, are based on compensating feedback." This helps a little, but it's still not totally clear. So, let's try a historical reference.

Writing in his book, Cybernetics, Norbert Wiener said: "(We) came to the conclusion that an extremely important factor in voluntary activity is what control engineers term feedback. … It is enough to say here that when we desire a motion to follow a given pattern the difference between this pattern and the actually performed motion is used as a new input to cause the part regulated to move in such a way as to bring the motion close to that given by the pattern."

Applying the two we get this: By continually monitoring and measuring outcomes, it's possible to use feedback to make adjustments (to compensate, to make corrections) in the same way a thermostat keeps the temperature of a room relatively constant.

The outcomes and expectations for service with regards to both functionality and reliability (in ITIL speak, utility and warranty, see How to Measure ITIL Service Utility and Warranty by Hank Marquis for more information) are recorded in service level agreements (SLAs). The SLAs describe what a service does (utility), what customers can expect with respect to how it will be delivered and supported (warranty), and the responsibilities of the parties.

Crafting SLAs requires input from customers (users) and the people who have the ITIL process-responsibility, for example, to understand the impact of this new (or changed) service on existing capacity and demand. It also means the parties need to understand the existing configuration items (i.e., services and the supporting infrastructure) and the relationships between them.

The service management lifecycle concept imposes a requirement for communication and feedback. In other words, the specialized capabilities of service management are really about developing the appropriate feedback mechanisms that lead to improving organizational maturity. That is what the concept of a closed-loop system has to do with adopting ITIL.

David Moskowitz is a principal consultant at Productivity Solutions, a Philadelphia, PA-based consulting firm that helps its clients thrive in an ebusiness, Web-based economy. He is a certified ITIL Expert, accredited instructor, and ITSM consultant. In these capacities, he has guided many successful projects. The goal for his efforts is to improve both the efficiency and effectiveness of IT organization at the same time that the business recognizes IT as a strategic asset. His focus working with clients, for more than 25 years predating the formal naming, has been IT service management. David can be reached at davidm2@usa.net. Follow him on Twitter: DavidM2 (http://twitter.com/davidm2).