I want to outline briefly some ideas I’ve had recently about our fundamental models for understanding IT management.

In 1968, Melvin Conway proposed an insightful law, basically stating that our systems are copies of our communication structure (how we interact as human beings). And while this law is often applied in discussions of computer program structure, his intent was broader, including any human created system.

In the broad system of IT management, we often hear of the basic three stages, “Plan-Build-Run.” We make plans for a new IT system, we construct it, and we run it. IT organizations structure themselves and communicate to a large degree along these lines. I’ve used them myself in any number of writings. However, increasingly I have come to believe that that as a basic structure for understanding IT management, “Plan-Build-Run” (which I’ll abbreviate PBR) has seen its day.

While it pervades IT management thinking, and can clearly be seen in the structures of frameworks like ITIL and COBIT, PBR is ill suited for the demands of 21st century IT management. Here are some of the problems I believe that the plan/build/run paradigm causes:

  • PBR encourages waterfall thinking, the idea that a complex system just needs to be designed, constructed, and operated. Agile trends turn this from a one time effort into an ongoing cycle, and this cycle is accelerating, challenging traditional IT organizations and methods.
  • Demand is split across the PBR phases. Because we don’t focus on integrated demand our customers have to knock on multiple doors to get the services they need.
  • PBR results in systems being built in isolation from one another. We thus lose opportunities to implement shared services and ensure architectural consistency across the IT estate. The result is complexity that is difficult to move to Cloud sourcing as an IT supply option.
  • Because we don’t see execution as one problem we are unprepared for DevOps, our people are multitasking, and our failure to prioritize across queues is resulting in poor service to the business.
  • Because we don’t view supply holistically we manage IT staff and their talents poorly, with little overall understanding of the dynamics between technical talent, technology products, and IT services.

What should replace PBR? I propose a new triad: Demand, supply, and execution (DSE).

These are not novel concepts. Supply and demand stem from fundamental economics and operational management. Execution is a widely accepted industrial term that covers the translation of supply and demand into value, via detailed resource and capacity management, dispatching, process monitoring, and performance analysis. The Wikipedia article on Manufacturing Execution Systems isn’t bad. I’ve also gained some insight from this article on ANSI/ISA-95.

The DSE concepts are distinct from (some might say orthogonal to) PBR.

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. 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 value, scope, risk, and other parameters, 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 boils down to the fundamentals of “atoms, bits, and cells”: hardware, software, and people, under various ownership and sourcing models. 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 occasional passersby. 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!

The DSE model is not intended not as a criticism or replacement of ITIL or COBIT or any other framework, but rather as an overlay, or perhaps an underlay. Well established IT process areas such as project, release, incident, change, and so forth are important and will continue, but a DSE approach can counteract the tendency to form functional silos around each, 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 therefore, 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.

This post was originally published on the Nimsoft Modern IT blog. Reprinted by permission.

Enhanced by Zemanta