So, here is my first graphical representation of the Demand/Supply/Execute model for IT service organizations.
The intent of this model is to provide an alternative to Plan/Build/Run and its sequential, waterfall, and Taylorist connotations. It is also intended to support modern Agile methods and philosophy which emphasize iteration, fast feedback, flow, and especially (per Don Reinertsen) managing queues, limiting Work in Progress and supporting small batch sizes.
Bottom to top, this diagram tells a story of demand and supply as they progress through increasingly refined understandings to the very specific execution of work and delivery of value.
We have markets and regulations, which define and constrain the potential demand for an IT-centric product. Markets are met with strategies and product offerings, which lead to programs of work, projects, and platform decisions. These in turn lead to identifying user stories, writing software, configuring platforms, and executing changes, service requests and work tasks.
This is NOT a methodology. These constructs can be as light or heavyweight as needed and value scenarios can originate at any point; there is no contradiction with Lean Startup and Agile principles of architectural iterations and minimum viable products. The existence of "Project" as a concept in the model does not mean that all work happens via Projects.
That finer and finer grained demand stream parallels a finer and finer grained supply stream. Large blocks of capital are translated into strategic technology choices and vendor relationships and investments in skilled people. More detailed budgets and planning culminate ultimately in the availability of people, hardware, and software for given assignments, e.g, an empty slot on a Kanban board.
Again, the journey can start anywhere, with a large block of traditionally managed programmatic capital or a small round of seed funding translated directly into a two-pizza team with maximum autonomy.
Ultimately the deployed IT service system is available for fulfilling transactional service demand which can be measured in terms of quality, availability and performance. When demand and supply irrevocably combine, that is my definition of execution.
I had a number of requirements driving this model.
First, it needed to be a graphical representation that could not be read as a sequence. That is the flaw of any model which is too easily reduced to a linear format, such as Plan/Build/Run. Circular models are a popular alternative, but repeating a sequence is not enough.
My primary reservation about value networks is their lack of a goal. What is to be done? How do I develop an action plan without some sense of the network’s purpose? (More here.) But the value network critique of naive sequencing is right on.
While the names “Plan/Build/Run” and “Demand/Supply/Execute” are similar in format, they are very different structurally. It is not usually possible to fully inventory demand and only THEN turn to considerations of supply. Forecasting is inherent in the relationship between the two, which both must operate continuously and simultaneously.
So, if we are trying to shift the IT mental mental models from sequential to network my proposal is that we start with the simplest non-sequential, non-linear concept, a vertex, two simultaneous vectors converging on a point.
This model retains a sense of execution, of a clear goal, while also introducing the reality of simultaneous flow - not step by step change, the fatal flaw of Plan/Build/Run (or Strategy/Design/Transition/Operate/Improve, for that matter).
I experimented with various orientations. First, I put the V on its side with execution on the right.
But this was still too tempting to read as a simple sequence, too much like Plan/Build/Run.
Then, I put the V with the vertex at the bottom.
But this still seemed too hierarchical and Taylorist, with the more abstract and larger grained "strategic" concerns “above” the detailed execution activities. This also brought back memories of the software development “V-model” that I did not want to invoke. In the spirit of servant leadership, I thus inverted the V, putting the most strategic, executive level concerns at the bottom.
Furthermore, because the inverted “V” approximates human legs, it reinforces the feeling of simultaneous action. Both legs must exert effort simultaneously.
The gap between the legs of the V is filled with the "Fog of Forecasting."
With the lower level, larger grained abstractions it is more difficult to understand demand and supply, especially when product development (e.g. novel software engineering) is involved. As demand and supply converge to the point of execution, a finer and finer grained awareness is created of the impending work and whether it is likely to be successful - that is, if demand will effectively and efficiently be paired with supply. (Notice how the fog lifts as you get closer to actual execution.)
We only start to really get a feel for how execution is going to work when we get down to team and individual level assignments across all queues and ultimately actual Kanban slots or their equivalent (e.g. assigned and accepted work orders).
Finally, I propose a new way of understanding the system architecture: Work Items and Configuration Items converging into an IT Execution Management System (IT-EMS).
The bold, supply-side terms tranditionally are handled in the CMS as CIs. The italicized, demand-side terms should be understood as as WIs. (On the supply side, notice that the CMS doesn't handle the supply of money or people's time, another major gap in integrated IT management systems.) This dimension of the model needs more work, but I include the concepts as food for thought. More to come on that front.
Turning to the choices of terms - the words inhabiting each leg (Asset, Release, Strategy, Team, etc):
Most of the nouns are things that may be found in various IT management systems (Incidents, Assets, etc), or at least deliverables & leadership conversations (Strategies, Programs). Roughly speaking, they go from larger grained and more abstract at the bottom, to smaller grained and more specific at the top.
Governance, Risk and Compliance (GRC) is included – one thing I appreciated about the Phoenix Project is that GRC is seen itself as a form of demand. Laws, regulations, and risks translate into policies, controls, and ultimately audit findings to be remediated, and all of this is also demand.
Finally, a few random notes and caveats.
As noted above, there is still a risk that each leg will receive too sequential a reading. A value scenario can start anywhere. There is NO methodology proposed or assumed. As elsewhere, the framework simply represents frequently used IT terms, including some of my explorations of service semantics.
This picture is not overly concerned with functional boundaries (legal and/or internal). These can appear in many ways. The primary boundary is between the service act vertex (inside-out) and the service outcome vertex (outside-in). But additional org boundaries might be found between demand side and supply side functions (IT Demand Management vs. Asset Management), and/or between different abstraction levels (Project Management vs. Incident Management).
Here is how feedback works. It can happen along different time frames, always originating with the point of execution.
Finally, this is an IT-centric representation. The framwork might be more broadly applicable to other domains, but I will leave that to others for now.
In closing: I think this mental model is a more accurate reflection of IT practice as it is evolving. It avoids sequential, linear and waterfall thinking as well as command and control Taylorism. It accomodates well known ITSM functional concepts, but aligned along a different fundamental structure, a structure better aligned with economic principles.
I will post some applications of this model next, starting with a reading of how it supports a Lean Startup approach.