In the previous post, we discussed the limitations of a Plan/Build/Run mental model to IT management. But what should replace it? I propose a new triad: Demand/Supply/Execute (DSE).
Go back to these pictures:
When the delivery cycle accelerates and the boundaries begin to break down between Plan/Build/Run, what emerges? First, one starts to see that work has common characteristics across Plan, Build, and Run.
We might observe that a common workflow or kanban system can be utilized across planning, building, and running activities. We might also notice that smaller teams require people to cover more responsibilities ("generalizing specialists"), especially when the boundaries between planning, building, and running are blurring.
We see that distinctions between "incidents," "problems," and "user stories" become increasingly arbitrary when it is the same team that needs to respond to any. Certainly, there are differences between proactive and reactive work, but as forms of demand both compete for the same supply of resources, and when tracked in different systems cause overburden, uncoordinated effort, and bad multi-tasking.
We also see that continuous improvement activities (which are kind of a middle ground between proactive and reactive) are "just more demand" and also compete for resources with purely proactive and reactive demand.
As we consider all this, the question arises: What, in fact, *is* the IT work, in the general case? The irrevocable meeting of demand with supply, with intent to generate value. Same in IT as in the rest of industry.
These are not novel concepts. Supply and demand stem from fundamental economics and operational management. I also want to add Execution, which is a widely accepted industrial term that covers the ideally optimal translation of supply and demand into value, via detailed resource and capacity management, dispatching, process monitoring, and performance analysis.
As an aside: I am not in favor of naive approaches to equating IT delivery with manufacturing. But, as Eric says in The Phoenix Project,
“You think IT Operations is rocket-science compared to manufacturing. What absolute baloney...From where I’m sitting, the people in this [manufacturing facility] have been far more creative and courageous than anything I’ve seen come from you IT guys so far.”
Demand management starts from the premise that regardless of the size of the implied work, all demand on IT resources should be understood in a unified manner (as popularized in the Phoenix Project). From a new mobile device to the day’s incident reports and change requests, to a strategic initiative implying a $10 million projects, it’s all “just demand.”
Different techniques come into play depending on planning horizon, value, scope, risk, and other parameters - more on this to come. Some demand signals contain others, or have complex interdependencies - e.g. an Incident that generates a Change, or a Project that contains multiple Service Requests. But if we understand demand as a unified entity we position ourselves to provide much better service to our stakeholders while at the same time giving our IT staff a saner existence.
Supply represents the fundamentals of “atoms, bits, and cells”: hardware, software, and people, under various ownership and sourcing models (e.g. Cloud). The CIO is responsible for increasingly complex IT sourcing and contract management strategies, and understanding one’s baseline supply is key to evaluating new supplier options for technology products and people with the skills to exploit them.
Finally, next generation IT execution management starts with demand and supply generally, and looks for optimal (or at least satisfactory) means of delivering value. “Projects” and “tickets” are seen as part of a unified management structure, not as the respective domains of "builders" and "runners." The availability of resources is always considered before releasing work, and ongoing scenario-based forecasting is employed to identify emergent constraints. And time tracking is completely transparent, relying on intelligent automation to determine what people have actually been working on. No Friday afternoon time reconstruction!
So, Demand - Supply - Execution. Here is a graphical representation emphasizing the continuous nature of this mental model:
(I may post further on some graphical elaborations.)
Well established IT process areas such as project, release, incident, change, and so forth are important and will continue, but I think a DSE approach could counteract the tendency to form functional silos around each -- or around a particular PBR cycle and its inputs and outputs -- and instead promote a whole-systems approach to IT management.
To summarize Keynes, “even the most practical man of affairs is usually in the thrall of the ideas of some long-dead economist.” Basic conceptual structures like plan/build/run and demand/supply/execute have consequences. When widely adopted to the point where they are just “common sense,” they define our social relationships, operational thinking, problem solving, and more. And thus, while we may think that “plan/build/run” is some form of IT natural law, it is a human construct that can be adapted or even discarded if we no longer find it useful. I think it's time.
Next: some elaboration, discussion of the graphical depiction, and mapping of existing constructs onto this new foundation.