On value streams, chains and life cycles

There is confusion among the three concepts of a value chain, a life cycle and a value stream. We see this both in feedback on my recent article on a value stream for service management and in many other places. I believe it is useful to treat them as different concepts, so I will try to sort them out here.

Life cycles

A life cycle is a series of time ordered phases through which a type of object or concept typically passes. These cycles have a span of an approximately fixed duration. At the end of that span, in the last phase, the object comes to an end and exists no longer.

Humans have a typical life cycle, starting with birth and infancy and progressing through to decrepitude and death. An automobile has a life cycle starting with its manufacture, a period during which it looks and smells like a new car, a period during which it is broken in and performing well, a period during which it starts to break down and finally its destruction and the possible recycling of its components.

Some objects can repeat at least certain parts of the standard life cycle. After a commercial aircraft undergoes an overhaul (a D check), it is often considered to be “good as new”. The cycle of use and overhaul may repeat until other factors lead the aircraft to reach the end of its life. Some people consider that humans may live through multiple lives, each of which has its own cycle of phases.

While there are exceptions to typical life cycles, these exceptions only serve to demonstrate the rule. We consider the events that lead to a premature end to a life, without having gone through all the cycle’s phases, as catastrophes (or blessings, as the case might be).

In the realm of service management, there is an egregious misuse of the term “life cycle”, namely the so-called service life cycle as defined by ITIL.^®. What that framework calls a “service life cycle” is, at best, a “service management life cycle”. It describe the phases of the life span of a service in only a most limited sense.

A service life cycle typically starts with a phase during which it is conceived and realized (what ITIL calls “Design” and “Transition”. In the next phase, a service is typically offered to a limited number of customers who are willing to take the risk to use the service. If and when the service proves its aptitude to be of benefit to customers, that service enters a phase of growth. It grows in terms of how often a single customer uses it and it grows in terms of how many different customers use it. This is a phase coupling high investment to rapid changes in load and in capacity. It is also generally associated with expansion of its usefulness, creating more and more benefits for its customers. When a service reaches a mature phase, the growth has largely leveled off, the churn in customers increases, the investments in the services and changes to its functionality decrease, because the existing customer base is largely happy with the service and do not want it to change too much. This is the cash cow part of the service’s life. But this phase cannot perdure, as it contains the seeds of its own, ultimate, failure. The service is progressively replaced by other services that are in their innovation or growth phases. Ultimately, the service enters its final phase, during which it is terminated and the service system used to provide and manage it is either terminated, too, or re-applied to other services.

As we can see, most of the phases of a service’s life cycle are subsumed by what ITIL calls “operations” and “continual improvement”. While ITIL is aware of the changes occurring and the use of various disciplines to manage those changes (service portfolio, finance, demand management, capacity management, etc. etc.), it does not recognize most of the service life cycle phases, per se.

Indeed, the final “phase” of ITIL’s purported life cycle, continual service improvement, is not a life cycle phase at all. The activities of CSI are not concerned with the service itself, but only with the ways in which it is managed.

To continue with an analogy to the life cycle of a person, we could agree that the marriage of two people might be a precursor to the birth of a person, their child. But that marriage is surely not part of the child’s own life cycle. Analogously, the definition of an organization’s strategies might occur before any service is conceived of or delivered. But it is not part of that service’s life cycle. Similarly, after having completed one’s formal education, a person might continue to take courses, undergo training and generally improve their skills. But these parallel activities are not a life cycle phase. And so it is for the continual improvement of services. We might readily want to make such improvements, but they are not a life cycle phase for the service.

Value Streams

When we talk about value streams, we are talking about a set of related activities in the flow of work performed to achieve a certain result. There is a value stream in cutting someone’s hair. There is a value stream in delivering someone’s mail. There is a value stream in fixing a service when it is broken.

Value streams describe the activities of an organization at the next to most detailed level. That most detailed level describes the precise details of how work is done in the instances of a value stream. We might call a value stream a mesoscopic activity. It describes patterns of detailed work, but does not provide a microscopic description of how that work is done.

The execution of an instance of a value stream results in some work item being delivered to a customer. If a customer asks for a new software application, the software development value stream delivers that software. If a customer asks for the repair of a broken product, the repair value stream delivers to the customer the repaired product.

I will talk more about value streams below, when I contrast them with value chains.

Value Chain

The description of a value stream provided above sounds suspiciously like the definition of a value chain:

a set of activities that a firm operating in a specific industry performs in order to deliver a valuable product or service for the market (https://en.wikipedia.org/wiki/Value_chain)

On the basis of that formal definition, I would not insist on there being any difference between streams and chains. However, if we look at how these two expressions are generally used, a clear difference between value chain and value stream emerges.

Value chains are generally described at a macroscopic level for a business or for an industry. They delineate, at the highest level, the principal activities of a single business or, in general, of a sector of business. IT4IT purports to provide a value chain for Information Technology as a whole. Michael Porter’s original value chain, Inbound Logistics – Operations – Outbound Logistics – Marketing & Sales – Service, describes the work of a business unit at its highest level. At this level, we can easily see the difference between the high volume, economy of scale approach to business and the lean approach to business. In the first approach, the business model is to make things and then figure out how to sell and support them. In the second approach, the business model is to wait until a customer commits to acquiring a product and then creating and delivering that product.

I would contrast this macroscopic level of analysis with the mesoscopic use of value streams. While a value stream must be aligned with the value chain, it focuses instead on managing the flow of work of teams or individuals and on eliminating waste from that work.

In the simplest and smallest of organizations, where work is limited to doing exactly one thing, the value chain and the value stream for that organization are likely to be the same thing. In such cases, the concepts are congruent. But in organizations that have reached a higher level of ramification, or functional differentiation, the difference between a value chain and a value stream becomes more apparent.

For example, a company might have a business line that manufactures computers. The value chain might look very much like Porter’s, or might look, instead, look like “Marketing – Customer Order – Inbound logistics – Build – Outbound logistics”, and so forth. But within the business line, a multitude of different teams may each have their own value streams. A marketing team might have a value stream to hold a marketing campaign. A purchasing team might have a value stream for ordering and receiving components. A manufacturing team might have a value stream for assembling a finished computer.

Value networks

The term “value network” is used in diverse ways by various authorities. I will not attempt to integrate the term into this discussion, as it is used in manifold ways. That being said, the concept is typically used to reflect an even higher and broader perspective than the value chain. Some would say that a value chain is too pure a concept, and that a non-linear network is an more accurate model how organizations work and work together.

It would make sense to me to use “life cycle” to describe the historical changes of system components; “value stream” to describe the highest level of activities of teams, which activities cannot stand alone and be economically viable; “value chain” to describe an economically viable series of activities of an organization; and “value network” to describe the relations among organizations in an entire market space, or even an entire economy. But that is a discussion for another occasion.