Demand Management Is An Oxymoron

I was delivering a presentation recently to a group of IT executives and one of the CIOs asked “The Integration Factory sounds great, but how do you manage backlog?” My response was, “There is no backlog so there is nothing to manage.” In lean terminology, a backlog of projects or change requests are work-in-process inventory and are considered waste; essentially an inventory of unmet needs. A lean factory strives to minimize WIP by using just-in-time techniques.

The term “demand management” suggests that the demand for IT solutions and business information can somehow be controlled by the supplier. The reality is that IT requirements are driven largely by uncontrollable factors such as government regulations, competitor actions, consumer market trends, business process improvements, mergers and acquisitions. It is unrealistic to presume that IT can somehow manage or control the demand for information solutions that are created by these events.

Demand management presumes that IT is a constraint and results in a process to prioritize projects and allocate resources. There is indeed a practical limit for how much change can safely be made in a complex enterprise application portfolio, but viewing IT as a constraint sets the stage for an inherent conflict between business users (information consumers) and IT staff (information suppliers). There is a better way.

Don’t manage demand – manage supply. Mature Integration Competency Centers or other IT groups follow three essential elements to eliminate demand backlog.

  1. A chargeback model. In other words, the person or group asking for the change pays for the change. Many IT organizations are a centrally funded cost center with fixed resources (determined by an annual budgeting process) with no chargeback for individual change requests; in other words the work is “free”. It is a fact of life that anything that is free (if it’s any good at all) will be over-subscribed.
  2. Efficient job costing. When a request for change arises, IT must quickly provide an accurate cost estimate – sometimes based on only high-level requirements. To do this requires a detailed inventory of IT assets, an up-to-date metadata repository for impact analysis, an organizational discipline around metrics management, and a custom estimating tool. This is not easy, but it can and has been done.
  3. Scalable delivery processes. If processes are generally manual (like they are in many IT organizations) and a request for a big project is approved, it is virtually impossible to add a large number of staff quickly.  Sure you can contract them quickly from a global systems integrator, but getting a large number of people to be productive can take months. The solution is to standardize IT processes, adopt a model-driven approach and automate routine activities to reduce scale factors.

If adopting these practices throughout IT seems like a daunting task, then just start with the integration function. As I mentioned in Why Integration is HOT, a factory-style integration competency center is the best place to begin since integration patterns lend themselves to reuse and automation which delivers benefits quickly and reduces the overall project cycle by removing integration from the critical path.

This entry was posted in Business Impact / Benefits, CIO, Data Integration, Governance, Risk and Compliance, Integration Competency Centers, Operational Efficiency and tagged , , , , , , . Bookmark the permalink.

4 Responses to Demand Management Is An Oxymoron

  1. David Eddy says:

    John -

    re: “a detailed inventory of IT assets, an up-to-date metadata repository for impact analysis”

    Do such things as an up-to-date inventory and metadata repository actually exist?

    My experience shows that over about 40 years, the metadata repository has had a less than 5% survival rate. Many try. Most fade into oblivion.

    Am I just looking under the wrong rocks?

    - David

  2. Gene Vilain says:

    Great question, John!

    It really helps to highlight a chargeback model, efficient job costing and scalable delivery processes. Those are table stakes, aren’t they?

    But even with those, aren’t there factors that keep IT constrained: limited development and delivery resources, change and configuration management constraints (such as bundling and scheduling sets of changes according to dependencies and priorities), and as you say, capacity to absorb change? Won’t we always have a queue of requests to prioritize and schedule?

    Thanks for your thought leadership! Cheers,


  3. John Schmidt says:

    David, up-to-date metadata repositories do exist, but you are right that the quality and ultimate survival rate is low. I don’t have any formal survey data, but my sense is that it’s not as low as you think and the success rate in recent is clearly getting better.

    The primary difference between successful implementations and those that aren’t is generally not due to technology issues. Successful metadata implementations have figured out how to measure the business benefits of the repository and have a dedicated team of resources to sustain and continuously improve on the value.

  4. John Schmidt says:

    Gene, thanks for your comment. Development and delivery resources are only limited if you restrict yourself to your permanent staff. If you have a variable staffing model and are able to tap into the resources of external contractors, staffing is not a constraint. But as I mentioned in my post, it is more important to have processes that can scale so that you can quickly get new staff productive on a specific task.

    That said, you are right that change and configuration management constraints may also be roadblocks to eliminating backlog. Loosely-coupled architectures and more frequent/smaller releases can help. In the final analysis, totally eliminating the backlog may not be practical, but it should nonetheless be an aspirational goal.

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>