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.


Building trust with your customer

Trust means we can depend on future action

It is common to speak of building trust within a project team.

We debate ways to build trust, how we break trust and to what extent this “trust notion” is important anyway.

I have written about trust building with regard to noticing the implicit promises we make each other, and how very “real” they are to us in terms of consequences even though we don’t know they exist.

I know some cynics who say that trust does not exist… but I also accept that is how a true cynic might see it, and I move on.

So in this post, I want to talk about the trust we build with our customers… something relevant to every technology leader. (Actually, the core reference for my post above had to do, in part, with a marketer’s perspective of software developers.)

Revisiting components of trust

I have introduced a distinction for trust as:

An assessment of sincerity, reliability and competence to hold our promises for long horizons of time

You might use a different distinction, but I offer this one as the basis for the rest of this post. It is a standard distinction produced and taught by The Aji Network, which you know if you follow me is an educational discourse of business professionals with whom I have learned and grown professionally.

Actually, when I say “long horizons of time”, it is more specific to say “as long as needed”. If you trust me with a promise not to tell about a surprise birthday party… I am off the hook for that promise after the event.

So what is our task?

You can't keep any promises you don't make

Given that distinction for trust, we only build trust with our customers when they assess we are:

  1. Sincere – we mean what we say
  2. Reliable – we recurrently do what we say
  3. Competent – we’re not claiming a skill we don’t have

AND… we have to hold our promises [for as long as needed].

The thing is, if we don’t make any promises, we can’t build trust.

Now, I’ve heard some people adopt this as an intentional strategy – if we don’t make promises, they can’t distrust us. Actually, the opposite is true — if we don’t make promises, our customers WILL grow to trust us — to NOT take care of them.

We can’t hide demand by ignoring it exists (or saying “no” to everything), and we can’t build trust by saying “yes” and failing to deliver. So what is left for us to do?

The natural human planning cycle: 90 days

Here are two examples from domains outside software projects:

These books have at least one thing in common – they both refer to the human psychological implications of 90 days as a powerful window for planning.

Things change a lot in our business lives, and in the business lives of our customers. That is one reason we gravitate toward agile, or at least to short-cycle projects. Here we have two examples of other domains that suggest a familiar theme – give yourself space for feedback and time to adapt… and don’t pretend to know everything.

So let me offer this natural human planning cycle as consistent with a powerful move to build trust with our customers. Don’t delay a release unless something drastic has happened. Communicate clearly and confidently about what will be “in” the release, but don’t miss the ship date.

Over time, your capacity to recurrently hit ship dates (reliability), with solid features (competence) as you have said you would (sincerity), you create the opening to change the moods and attitudes of customers who might have great reasons not to trust due to historical patterns.

One strategic purpose for building trust with customers

There are many reasons to build trust with customers, but I will leave that to another post.

Today, I just want to link back to a past article I wrote about the role of project managers to hold customers to their end of the bargain – that they take receipt of our products. Not every team has this problem because they have their customers’ trust.

Some teams don’t have the problem because they have psychologically strong coaches who can force acceptance on their customers regardless of trust. (I haven’t directly observed this, but I leave open the possibility that it might exist.)

For the rest of us, not having your customer’s trust means they may become over-demanding, asking for more because they know they won’t get it all. They may get beaten down and stop asking for your help. Or I don’t know if this is worse, but they may take their budgets and look elsewhere for help.

They are not “wrong” in acting that way… but you can get ahead of them by investing in building their trust. Find promises you CAN make, if you can’t do everything. (Who can?)

…and deliver on those promises, consistently, competently, sincerely and recurrently… for as long as needed.