IT Management: Moving from Plan-Build-Run to Demand-Supply-Execute

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.

Next week: The results of the EMA Unified IT Demand Management survey

Charlie Betz is Research Director at Enterprise Management Associates. His responsibilities include IT portfolio management, IT financial management, asset management, ITSM suites, and integrated IT management.

He has 20 years of experience across all aspects of enterprise IT practice, including 6 years at Wells Fargo as Senior Enterprise Architect and VP for IT Portfolio and Systems Management. He has also held architect and application manager positions for Best Buy, Target, and Accenture. He is author of the recent 2nd edition of Architecture and Patterns for IT: Service Management, Resource Planning, and Governance (Making Shoes for the Cobbler’s Children). Follow Charlie online via Twitter and Linkedin.

For more information, download Nimsoft’s free eBook: The Definitive Guide to Unified IT Management.

Facebook Twitter Linkedin Rss
This entry was posted in Modern IT and tagged . Bookmark the permalink.

10 Responses to IT Management: Moving from Plan-Build-Run to Demand-Supply-Execute

  1. rick parker says:

    The issue with IT Plan Design Build is that business changes, sometimes quickly, and plans and current plans and designs don’t or can’t. We can’t predict what business needs (demand) so we need to stop trying and design for the most scalable, agile design possible. With new technologies / services it’s possible to change the way we plan /design IT from application by application or data center by data center to design for a complete IT Architecture from the beginning or as a goal for maximum cost efficiency, reliability, scalability, and agility. We don’t need a new process, what we need is a better strategy. A Modular Hybrid RAID Virtual Infrastructure (Cloud) Architecture strategy is the solution

  2. Bob Deasy says:

    Quite interesting and if one steals the time to really review thought provoking. My first reaction is to revisit the Kanban principles of manufacturing ( check out http://www.kanban101.com/) The idea of making work visible, limit work-in-process and help work to flow. Where you mention systems being built in “isolation.” I see a lack of visibility of all that is demanded which, as you present, makes the business of IT easily ose sight of the customer and their needs. Thank you for the article. I certainly enjoyed it and look forward to more discussions

  3. Dave van Herpen says:

    Nice read! I strongly advocate your call for true agile organizations with ultimate transparency. Perhaps the biggest challenge I foresee in IT (and its value for the organization) is a smooth cooperation between its change & continuity roles; in other words, between dev and ops. Ultimately, I even see the urge to not only integrate the PBR chain, but also the DSE in that respect (multidisciplinary teams). But I agree with you that not the traditional PBR, but DSE is the best road to get there!

  4. Lee Freer says:

    Informative article and interesting concept! Especially in the dynamic IT world we are living in.

  5. Charles Betz says:

    thanks all for your comments. Agree that Kanban is a key technique; it presents the demand/supply/execution problem at its most fundamental. (Hey, there’s a new blog.)

  6. Gijo Mathew says:

    I really appreciate your thoughts on this topic. I especially like the idea of all things being a “human construct” which in turn really means that the people involved have to internalize these approaches to eventually become “common sense”. The obstacle I see is that PBR nature has been ingrained in current thinking. I was in a meeting a couple of weeks ago with a company that has clear organizational lines around PBR, they were talking about all the “demand” that they have and how they are struggling to stay competitive because they can’t address the demand in a timely fashion. It went unsaid at the meeting but the sentiment was that they can never be agile enough for the business the way they are organized. As someone who feels their pain and even though I work for an IT solution provider, I had to say that more “tools” are not going to solve the problem. They need a new way of organizing first and then look at their current tools to see if it will help them in this new paradigm. All I could offer was that advice along with some thoughts on whatever they do they need to leverage social collaboration and have a way to enable people to do more in a smarter way as they break out of their silo shells.

    • Charles Betz says:

      Exactly. It’s all about your mental model. If you limit the questions you ask, you limit the answers you get. But changing mental models is one of the most challenging endeavors we face in the human experience. Thomas Kuhn’s advocacy of paradigm shifts must always be tempered with Machiavelli’s caution: ” there is no more delicate matter to take in hand, nor more dangerous to conduct, nor more doubtful in its success, than to set up as the leader in the introduction of changes. For he who innovates will have for his enemies all those who are well off under the existing order of things, and only lukewarm supporters in those who might be better off under the new.”

    • Rob Bote says:

      We struggled at redesigning our small (<30) IT org around PBR and finally gave up stating "PBR is what we do and not what we are".

  7. Pingback: Fresh Links Sundae from David Lowe of Actionable ITSM | Actionable ITSM

  8. Pingback: » Re-engineering supply chain: Moving from Plan-Build-Run to Demand-Supply-Execute MODERNIZE

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>