How do you manage demand effectively?

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 might take 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’t doing 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.

About ken
Creative insights, passion and technical adrenaline - strategist, agile coach and marketer, providing a good life for wife of 20 years & 2 awesome teenagers!

13 Responses to How do you manage demand effectively?

  1. ken says:

    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.

    • ken says:

      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.


      • ken says:

        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.

        • ken says:

          …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?

          • ken says:

            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. ken says:

    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.

    • ken says:

      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.


      • ken says:

        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.

        • ken says:

          @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…

          • ken says:

            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. ken says:

    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. ken says:

    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.

    • ken says:

      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.

%d bloggers like this: