Jaa

When demand management is confused with alignment…

  • Artikkeli

One of the most common, and reasonable, mechanisms for achieving clarity on the roadmap for a single platform is “demand management.”  It is also one of the areas of IT that is both rapidly evolving and poorly defined.  I’d like to offer an opinion about what demand management is, and is not, and how it meets some, but not all, of the planning and governance needs of IT.

Caveat Emptor: In the post below, I’m sharing my opinion, which will probably differ from yours.  I ask that you follow along with an open mind, and consider the possibility that we may be using the same words in different ways, before pointing out how “wrong” my thinking is.  That said, I would love to hear feedback from others, and to improve my own thinking in this space.  Please share your thoughts.

Assertion 1: IT Demand Management is poorly defined.

In the book “IT Success: Towards a New Model for Information Technology” author Michael Gentile provides a reasonable description of demand management… or at least he starts to.

Using the fundamental premise that not all demand from the business will be approved—because of business priorities on the one hand, and IT resource and scheduling constraints on the other—the best way of representing demand would be via a funnel. Demand from the business enters at the top, follows one or more decision-making processes, and then either exits at the bottom as approved work to be executed, or remains in the pipeline pending further evaluation. – Michael Gentile, “IT Success: Towards a New Model for Information Technology” as excerpted in CIO magazine (link)

This is a reasonable explanation of what demand management is.  As a more formal definition, IT Demand Management is the practice of collecting together all of the demands that will be fulfilled by a particular IT group, team, or organization, and balancing all of those demands with the limited supply of resources in order to produce an ordered list of activities, on a specific timeline, for that group, team, or organization to fulfill.  

Assertion 2: Demand management does not deliver alignment

Unfortunately, if the article in CIO that I cite above is any reflection on Mr. Gentile’s book, he goes wildly off the rails, describing demand management as the process by which IT achieves alignment and delivers value.  That is an interesting notion but it is fairly easy to disprove. 

What proof do I offer?  A counter-example.  Microsoft IT has been performing the kind of demand management that Mr. Gentile describes for well over a decade.  At no time did demand management deliver alignment.  When alignment was achieved, it was achieved in spite of, or regardless of, the maturity of the demand management process, and not because of it.

Alignment happens when a team or group of people decides to build the right solution, instead of building the solution right.  But more importantly, alignment occurs when a team decides NOT to build something, or to build something less than was requested, or in a different order than requested, because it meant that the business was more able to deliver on strategic goals. 

Mr. Gentile and I agree on this understanding of alignment.  We disagree that demand management gets you there.

Assertion 3: Alignment processes occur BEFORE demand management processes

Starting with demand is important and useful… if you already have a solution, and that solution has demand.  Once you have a solution, you have to manage the demand against that solution.  You don’t have infinite resources.  So if there are four teams within your company that want to use your public website to meet their goals (let’s say lead generation, ecommerce, customer support, and investor relations) but only one team that can manage the public website, then you will need to use demand management.  You need to collect the requirements from different teams, go through a rational and mature process for prioritizing those requirements, create a roadmap showing which requirements to meet in which order, communicate that roadmap, and track to it.  That is demand management.

However, if you THINK you need a solution to a problem, and you are a business leader, your request could go into a demand management “funnel” and come out the other end producing a solution to a problem that you did not have.  That is misalignment, and demand management will do little or nothing to prevent it.

Alignment requires a different process, one that examines the goals of the business, rationalizes them, finds common impact areas, and FRAMES THE DEMAND.  Alignment decides what demand is rational.  Alignment occurs BEFORE the demand management process does.  To accept all demand against IT without performing alignment activities first is an anti-pattern.  Demand management practices lend an air of “officialness” to the resulting roadmap, and once that roadmap is produced, it is very difficult to come back to the project teams and point out that the hard-won priorities don’t align to business strategy!

Discussion and Conclusion

These are tough assertions for many IT folks.  This is one of the major reasons, in my opinion, that Enterprise Architecture is often unwelcome within IT, but well received outside of IT… because Enterprise Architecture attempts to achieve alignment in spite of the often well established practices of IT demand management.  Without clear understanding of the dependency that demand management SHOULD take on alignment, the processes will conflict.  Demand management will produce a list of things to do, and alignment will produce a different list.  The only way to reconcile this is to perform alignment activities first, and then demand management activities, to produce the ultimate roadmaps.

That is my perception, anyway.  I know that some folks will assert that demand management is a larger process, and it includes the “alignment” activities that I speak of.  That may be an interesting matter of semantics.  However, if this were true, then the “funnel” metaphor breaks down, because any demand management process that includes alignment activities would not resemble a funnel.  In a funnel, all of the stuff goes in the top and the stuff coming out of the bottom is a direct reflection of what went in the top.  Alignment assumes that most of the stuff going in the top is wrong, and that a lot of stuff is missing. 

The “funnel” metaphor for demand management is accurate, as long as demand management doesn’t deliver alignment… and it doesn’t.

Your thoughts?

Comments

  • Anonymous
    August 12, 2010
    The comment has been removed

  • Anonymous
    August 12, 2010
    The comment has been removed

  • Anonymous
    August 13, 2010
    Nick, I agree with your assertions in principle. For me, the key issue is with Gentile's definition of demand management. The quote defines it as a reactive capability - more as demand response. If the definition included demand generation (which for instance Wikipedia's definition of the term does), the assertion that demand management provides alignment would be more plausible.

  • Anonymous
    August 14, 2010
    Hi Jiri, If Demand management included demand generation, that would cover part of the problem.  That would insure that there was no "missing" demand, but it would not insure alignment.  Alignment requires many things.  One (that you hit) is generation of demand.  Alignment also requires that Overlapping demand is rationalized.  It also requires that some demands are REMOVED from the queue for reasons of business strategic alignment, policy alignment, and future state architectural alignment.   Demand generation, by itself, would not sufficiently improve Gentile's definition to the point where demand management would deliver alignment.  There is simply not enough information in that "funnel" to make the right decisions and produce an aligned output. --- Nick

  • Anonymous
    August 18, 2010
    Nick, I agree that alignment happens before demand. Most of the times I used to hear the buzz word "pipeline" as you mention "funnel" and that is highly invisible. I can think of some options (forgive me, I am a Project Manager material for quite sometime now hence my EA concepts are pretty new)

  1. Can governance address these issues? For instance, your organization already embarked on mega multi miilion dollar projects, is there any real bandwidth for the demand? Then comes the alignment
  2. Can tools like readiness assessment, portfolio biz value/risk assessment be deployed to have an objective view of how we can align demand and alignment? For instance, there may be few projects taking up resources and locked up thus an optimization is required. I know several services organizations (IBM, ACN, CapGemini, Infy, TCS) do it very efficiently?
  3. More than demand and alignment, what is the model used to forecast the demand. Alignment usually takes place with existing demand but what about forecasting demand. There should be methods to address how change can be managed? I liked your thought since most of times I've worked in such environment where alignment occurs and we struggle to manage demand and we go back to drawing board again.
  • Anonymous
    August 18, 2010
    Nick, I agree that alignment happens before demand. Most of the times I used to hear the buzz word "pipeline" as you mention "funnel" and that is highly invisible. I can think of some options (forgive me, I am a Project Manager material for quite sometime now hence my EA concepts are pretty new)
  1. Can governance address these issues? For instance, your organization already embarked on mega multi miilion dollar projects, is there any real bandwidth for the demand? Then comes the alignment
  2. Can tools like readiness assessment, portfolio biz value/risk assessment be deployed to have an objective view of how we can align demand and alignment? For instance, there may be few projects taking up resources and locked up thus an optimization is required. I know several services organizations (IBM, ACN, CapGemini, Infy, TCS) do it very efficiently?
  3. More than demand and alignment, what is the model used to forecast the demand. Alignment usually takes place with existing demand but what about forecasting demand. There should be methods to address how change can be managed? I liked your thought since most of times I've worked in such environment where alignment occurs and we struggle to manage demand and we go back to drawing board again.
  • Anonymous
    August 25, 2010
    Hi Nick, It is a good post and very enlightening. I have been doing research on ITDM, BRM, and Portfolio Management for some time and I can understand your assertions here. However, I could not quite agree with your 3rd one, which is talking about the alignment. I believe the concept of ITDM is borrowed from the traditional DM in the supply chain management and one of the main purposes of applying this into IT is to balance the supply with the demand and enable the IT senior leaders such as the CIO to present the situation more effectively to the business leaders and so that the IT leaders and business leaders can co-monitor and co-manage the balance. Of course, prioritization is also key in the traditional DM concept and also plays an important role in ITDM. However, there is one key extension of the ITDM from the traditional DM is the "alignment" and this "alignment" has been interpreted by several leading books on IT as at least two parts: "build the right things" and "build the things right". The 1st alignment should be handled by ITDM and the 2nd should be handled by ITSD (Solution Delivery). I am quoting part of your paragraph above for easy explanation: "However, if you THINK you need a solution to a problem, and you are a business leader, your request could go into a demand management “funnel” and come out the other end producing a solution to a problem that you did not have.  That is misalignment, and demand management will do little or nothing to prevent it." The fact here is that the misalignment is not caused by ITDM and should be handled by ITSD and, yes, ITDM can do little if not nothing to prevent it because ITDM focuses on "build the right things". In addition, I very much agree with your words on "interesting matter of semantics" of ITDM and I do not think ITDM is as simple as a "funnel" process. ITDM should include the "build the right things" alignment value proposition and more. BTW, I need to mentioned that so far I only focus on the traditional manufacturing industry, which might see the ITDM process differently from your angle. ---- Xu