Jul 262011

Take a number?

You don’t manage demand.

You can’t manage demand.

It’s not a powerful question to ask because it’s not within anyone’s capacity to carry out.

When our customers line up and take a number to make their requests of us, demand simply is. Though we may have processes in place to manage our limited resources, we should never be confused that we’re actually managing demand.

As long as people have concerns to care for, there will always be demand. As long as technology can help take care of some of those concerns, technologists will never have enough capacity to take care of everyone.

Demand management and portfolio management

Demand management is a philosophical orientation toward IT governance, mostly about portfolio management.

As we inventory all the projects we mighttake on, we call that a portfolio. As we decide what we’ll do, set priorities and allocate resources (human, financial, equipment and other forms of capital), we call that portfolio management. It is an important and powerful management practice that aligns with the most basic constraints we face.

Where “demand management” enters into the picture, it represents a philosophical shift from our real constraint to the external market. IT claims to “manage demand” because our resources are always insufficient, and we know that we have to say “no” to some requests that come in. By saying “no”, we say we are managing [read constraining or governing] demand.

Only we’re not. The demand is still there. We’re just saying it’s beyond our capacity to cover. We put management-speak around our philosophy, perhaps so that it’s less confrontational or makes us feel better?

Fundamental mechanisms of demand

Rather than jump to the opposite extreme and suggest we stop saying “no”, let’s first make some assertions about demand and our capacity to handle it:

  1. IT resources are always limited, relative to demand
  2. Outside of strategic capital investments in IT, working to “keep the lights on” (email, hardware, software, infrastructure, service desk, phones, etc.) consumes much of the IT budget
  3. Customer needs do not go away just because we can’t handle all requests

You can't argue with fundamental mechanisms

You see, customer demand also originates in similar fundamental mechanisms: everyone needs help, they also have limited resources, and eventually if they don’t take care of their own concerns they start to suffer until they take action… and that action might not involve us in the way we prefer.

If you add to these the concern that rapid technology shifts overtake some IT professionals, causing them to gradually either 1) focus on smaller domains, 2) become generalists or 3) lose competitive advantages as the market drifts, it strains our capacity to consistently keep up with customer demand more every day.

As a result, a notion that we can manage demand seems both reasonable and attractive. It is important, however, to stay grounded in the fact that we can’t do everything and we aren’tdoing everything… so if the demand is high enough, our customers will look elsewhere for the help they need.

Those environments where IT believes they manage demand but also work to prevent customers from going outside for help create “the perfect storm” for marginalizing the value of IT and prompting quick business responses to outsource the function.

How demand management impacts trust

I have written of trust in many other places. Remember for the purposes of this blog that we distinguish trust as “an assessment of our sincerity, reliability and competence to hold our promises […for as long as we need to].” I also shared the observation of a marketing expert who said they have been waiting for an IT project that has been three months from shipping for over 18 months!

It happens. It isn’t pretty. But what does it say for sincerity, reliability and competence?

If we believe the answer is demand management, and demand management ultimately means cutting back on the work we promise to do, then maybe we hope to increase trust by making fewer promises? That would make sense if it were the end of the story.

You see, if IT has a history of failing to deliver, we break trust… and if we make fewer promises, we lose opportunities to build trust. AND if we do both… we lose on both ends.

So what do we do?

The rational answer, it seems to me, is to first accept that demand management is a philosophical orientation. It is not right or wrong, but it shapes how we think and act with regard to our customers and our “competitors” (those to whom they turn when we say “no”, as we must).

Next we need to look for a more effective philosophy that focuses on what we CAN do.

Don't confuse this with the power of positive thinking...

We have to start by making make sure to hold our promises while ALSO making as many as we can keep. We make them clearly, and we work to build a new tradition with our customers of saying yes and delivering – consistently, recurrently and with optimal business value… all the time. Rinse, and repeat.

When we say “yes”, we don’t say yes to everything (which breaks trust), but yes to what we can do with our limited resources.

Let’s change the philosophy from “managing [governing or constraining] demand” to “managing [taking responsibility for] the value we produce”.

We can’t manage demand anyway… we can only manage the promises we make and what we deliver with the resources at our disposal.

  16 Responses to “How do you manage demand effectively?”

  1. On LinkedIn Group “SCRUM Practitioners”, Alan McKellar wrote:

    Ken, request you expand on your thoughts on “so what do we do?” While I agree with your insight that we cannot control demand I think the problem is more than saying yes to as much as we can to give ourselves opportunities to deliver and build trust.

    I think the core issue is that most groups do not understand their organizational capacity. Folks make commitments with intentions to deliver but they truly do not know what their capability is. And when they are over committed they fail at some of the promises they’ve made.

    Customers respond to this phenomenon in different ways including asking for more than they actually need to negotiate to the core set of things they absolutely need. And I have spoken and worked with customers who felt it was necessary to push a team even though they knew the other party could not deliver…to get as much as they could. Over time I dramatically improved communication and built trust…but it took time.

    I think to build trust we must track metrics. Size, Productivity, Time, Effort, Quality From the data we can speak more intelligently and make smarter decisions on commitments.

    Being open, I’m a “no” guy. I think scope control is critical to project delivery. The nice thing about scrum is it systemically forces the team and I to respond to changing demand.

    • My response:

      @Alan, I accept your request to expand on my thoughts… though I figured this was going to be like a novel so I should split it up a little at a time (or nobody would read it). The various comments I am receiving are awesome, and I will expand a little more as we go so it can be more of a conversation.

      I love your observation, “I think the core issue is that most groups do not understand their organizational capacity.” How can we know what we can or cant’ handle if we can’t get a handle on our capacity?

      This is where the “art” of software development messes with solid operational management principles like ToC or Lean… I am careful here to say it does not nullify them, it can just make them a little fuzzy.

      If we were planning production in a manufacturing plant, we can say with solid grounding what the capacity of a robot or machine can be for performing a given task. Even with human operators, we can speak of statistical averages that help us understand capacity.

      Estimating development effort, testing and so on in a software project is not always as easy, so knowing our capacity is a great question to ask. (Another comment left on a LI group was about analyzing demand… the two would be GREAT to have together, right?)

      One direction I am heading is toward a conversation of agile, which you clearly connected with this topic, and I do too. Even our measures of team and individual velocity, story estimation, sprint and release planning, and retrospectives are helpful in narrowing down some means of get better at estimating and managing throughput.

      There… I said it – we can’t manage demand… what we manage is throughput, in my assessment, and agile not only helps us with that management, but it gives us tools for prioritizing that need to be addressed as well.


      • Alan McKellar replied:

        Ken, thanks as I think you have helped me solidify my thinking here…it is the prioritization. Because we manage throughput and it is a finite world, we are constantly making trade-offs. The key is to periodically and often revisit the priorities and ensure our understanding of the customer need is the same. If it has changed then we must re-examine if we need to change what we are working on.

        And the customer determines the value. Just because we as engineers think it is cool does not automatically make it cool.

        • …and my response:

          You are welcome, Alan. I should also thank you for your insights not only questioning capacity, but also what you are saying that really speaks to mutual trust and respect between producers (IT) and consumers (our customers).

          Prioritization is at the heart of a solution, and it is a standard practice in portfolio management whether or not we adopt the philosophy of “managing demand”.

          I wonder also if institutional memory is a key… does everybody remember how we originally set priorities, and if we need to steer the ship (priorities change), do we have mechanisms that allows us to steer the ship (like recurrent release or sprint planning) so we don’t “stiff-arm” our customers?

          • And another from Alan:

            I definitely think institutional memory has impact. And if a group does not have the tools or processes to review feedback from customers it will hurt you. Conversely, with these tools and processes we can make better decisions based on what customers value.

            With this in place, the product owner has an easier time working with the team during sprint planning.

            I find that even very short comments as to how a decision was reached are very insightful months or years later as user stories are evaluated. It is very interesting to see how thinking evolves over time.

  2. On LinkedIn Group “Chief Information Officer (CIO) Network – The Group for CIOs”, Eric BREMOND wrote:

    I should say that managing demand is not really the role I like to put myself in.
    I don’t share the idea that the main role of IT is to fulfill the need of other departments.
    Of course every day we say yes or no to specific demands on specific projects but that’s the small part of the picture.
    IT is part of the business of almost every company today and “managing demand” is the role of the executive committee, it’s the place where the decision of taking or not a project should be taken. Ressources allocation should follow if the project has a strategic impact on the company. If it has not forget about it or outsource it.
    I think it doesn’t matter if your customers look elswhere for the help they need as long as the project concerned is not strategic for your company.

    • And my response: @Eric, I agree with you. I think users, at some point, have to go outside IT to get some of the help they need. There are people who are experts in certain domains that we are not… there are commodity tasks that may not be valuable or strategically coherent for us to do in-house… and they have peaks and valleys in demand that prevent us from producing a perfectly balanced system, from a capacity perspective.

      So if customers have to go outside IT for some things, what things does IT choose to work on? How do we set priorities (possibly, as you have said, with the help of an executive team)?

      In working that way, I don’t think we are managing demand… we are managing the throughput of our team – what we CAN do, and not really what we CAN’T do.


      • Then @Eric replied:

        In my opinion IT should work on any project that directly support the business. What brings the most value take the highest priority. I mean for example CRM doesn’t qualify because it brings value to the sales force who brings value to the business but it’s not a direct link.

        Could sound a bit simple but it’s a rule of thumb.

        Besides when speaking about users going outside, I’d prefer that the IT department takes the project and outsources it by itself. There is no need to invest on non-strategic competences but it can help to assure a good integration.

        • @Eric, I agree – it would be EXCELLENT if IT made the offer to business to handle the outsourcing, since we are the ones competent to make assessments, at least regarding the technologies and their potential for integration and support.

          Too often in “demand management” situations, IT says it doesn’t have the capacity and business stakeholders outsource without that collaboration or governance. Renegade projects and “crappy little apps” spring up and become an IT nightmare eventually, and we might have headed it off if we coordinated it (or helped coordinate it) in the first place.

          And if we are involved in the outsourcing coordination, we are not “saying no” or “managing demand”… we are part of the answer, managing throughput of business value using flexible capacity.

          [To be fair, budgeting and chargeback mechanisms (financial governance) may also constrain us from getting to this kind of a state…

          • Eric’s response:

            Ken, We all experienced those “crappy little apps” and you’re right, handle the outsourcing means we are saying yes. A third solution is to let customers outsource the project with only a IT member involving in the process. It’s probably what you mean by outsourcing coordination but in this case it is not a real “yes” to the project and it needs only little IT investment.

            Different levels of IT commitment are possible depending how risky it is to let the project go away. And assessing this risk is our responsablity as CIOs.

  3. On LinkedIn Group “Agile Alliance”, Valentin Tudor-Mocanu wrote:

    Nice point of view. It is true; we shall always have a match with what want to “contract” with our capabilities on long, medium and long term. And not just “sign the contract” and just later “manage” somehow the project. In this last case it is similar to going to a sport competition without being trained and prepared, and just hoping that we will handle somehow the problems (“do our bests”??). Imagine that will be a boxing competition…

    There is more: we shall improve our capability in time and if we want to take more from the business opportunities we shall be ready and prepared for that.

  4. On LinkedIn Group “Creative Product Managers”, Robert Jablonski made an AWESOME observation:

    Biggest problem in my arena is not the communication with our customer but with their ultimate customer driving demand. Short timeframes and the real threat of we can get it somewhere else.

    • My response:

      Wow! @Robert, I have been in the same situation more often than I can count. I ran teams of consultants writing custom software for a client… and they were an interactive marketing firm who sold our [unwritten] products to their customers.

      There is not much to do to manage demand in that case, right? Demand simply “is”, and we are truly insufficient to meet it.

      It’s a shame you don’t always have the autonomy to just turn… and run.

  5. On LinkedIn Group “Lean IT Enterprise”, Nick Spanos wrote:

    @Ken, I understand the point that you are making and I agree with your assessment. It is my nature to play “devil’s advocate” so I will offer a counter-argument … you can manage/affect demand but you can’t necessarily control demand. Here are some things to consider with respect to demand management:

    1. You can’t manage what you can’t measure. Step 1 of managing demand is to measure it, analyze it, and understand the patterns and the reasons for the patterns.

    2. Based on the pattern analysis, you can take actions. These actions can impact your response to the demand. They can also increase/decrease demand.

    Examples: Electric companies reduce rates for off-peak usage. This rewards peope for using their washer and dryer in the evening (thus reducing demand during peak hours). Restaurants provide senior citizen discounts during non-peak hours to encourage seniors to avoid the peak hours so business customers don’t have to wait. When gas prices rose to $4 per gallon, demand was reduced. All of these are examples of demand management.

    Here are several IT examples: IT organizations run batch processes at night to balance the demand for system resources and avoid impacting online access during business hours. They archive older files to manage demand for storage. Finally, if IT implemented a chargeback system where business organizations had to pay for the IT capacity they utilize, it would definately have an impact on demand.

    The point is: If you measure and understand the demand, you can manage it. That doesn’t mean that you “control” demand but you can certainly “influence” demand. The same argument could be made about managing people (we don’t really control them but we do influence them).

    • And my (unfortunately too long) response:

      Ken Faw • @Nick, that’s a great distinction. I accept that you cannot control demand at all. I also accept that you can affect demand – for example, a massive PR mistake can negatively affect demand for your products… though demand in other areas might change in the other direction.

      I also accept how you ended your writing in saying you can influence demand, but to me there is a distinction between influencing and managing, just as you have said there is a difference between influencing and controlling.

      Where my interpretation differs is in proposing that what you manage is not demand, but your capacity to meet demand… and that the offers you make can influence buyer behavior.

      Though I speculate that @Nishi is not specifically expressing agreement with this thinking, in my assessment the notion of “distortion of Demand” could be restated as “influencing buyer behavior”… distortion is certainly a form of influence, so at a minimum her phrase is consistent with yours of “influencing Demand”. Such influences have been seen in overextended credit, the housing bubble, farm subsidies that upset food prices, etc.

      Because demand is external and represents the concerns of the market, you can supply it or not… The good news is that you get to design the terms of your offer… That, it is more powerful to work on managing your own offer(s) than attempting to manage an external and indirect variable. By managing your offer, you can predict how you can influence the external variable.

      Though electric companies and restaurants influence buyer behaviors, we still wash our clothes and we still eat. They are actually managing their offers in order to influence behavior. They influence the “system” of supply and demand, but don’t really manage demand. You might also say they can increase demand but can’t really reduce demand.

      That is a much more powerful posture to me, from an operations management perspective than what we call “demand management”. Even the gas price situation and your IT examples fit into this model. Higher gas prices don’t reduce demand, but the relative change in value of available financial capital reduces capacity to transact at the higher price. That is the fundamental economic principle of trade-offs at work.

      Meanwhile, the other IT situations that see demand as a direct variable we can control are misleading us into situations where we handcuff our customers, lose more of our new business budgets to just keep the lights on, and face year after year of conference speakers who talk about business and IT misalignment as our marketing customers go around IT to meet unsatisfied demands.

      The two points you have called out work equally well for an organization that focuses on the design of its offers as a higher priority than regulating demand… with a little modification:

      1. You can’t manage what you can’t measure. Step 1 of making valuable offers is to assess your markets, analyze them, and understand the patterns and the reasons for the patterns.

      2. Based on the pattern analysis, you can take actions. These actions can impact your response to demand. They can also influence your customers’ behaviors, positively or negatively based on how effectively you have made your assessments and designed your offers.

  6. […] not to mention that they could have gone straight to the web on their phone. Policies can help, but you can’t manage demand beyond a […]

Leave a Reply