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.

Advertisements

Does your IT salary depend on what makes you different?

"Rational people" think at the margin...

It’s Monday, and that means I take another crack at an economic principle and apply it to software development and IT. (Here is a link to the series so far.)

This week we are on principle #3 which goes something like this:

Rational people think at the margin.

I am going to put aside questions about whether (or which) people are “rational”, or whether I would be qualified to make the assessment in the first place.

Instead, I want to focus on the “margin”. (Perhaps that makes me “rational”, after all.)

In this context, the “margin” relates to an economics principle called “Marginal Utility“.

A summary of the concept (for our purposes, anyway) is that people will value two otherwise equivalent items against each other based on their “marginal” (or incremental) differences, positive or negative.

So we might pay more for one car based on its gas mileage or on its performance characteristics, all other attributes being pretty much the same.

Fundamentally, the market of buyers and sellers converges on a certain price at which a commodity might be bought or sold.

As long as a surplus of buyers or a shortage of supply exists, prices may rise… and the converse also holds.

Designing for marginal utility

Now, if a company wants to sell its products at a premium, you may have heard that it needs to “differentiate” them in the market.

More specifically, the company needs to name, find or design a marginal utility for its offers… an incremental change that drives a disproportionate increase in assessments of value (price).

Don't quit your day job!

My business teacher, Toby, used an analogy like this (the following numbers are illustrative only, and may not be accurate):

  • A “good” college basketball player, scoring 26 points per game, has no chance of becoming a professional…
  • A “great” player, routinely scoring 30 points per game, might get drafted at a league minimum salary…

While…

  • The “elite” player who always scores 34+ points per game might get a starting salary ten times higher (not to mention endorsement deals and other additions to income)

Looking at it that way, you could say that the difference between getting into the pros and not is 2 baskets per game.

You could also say that the elite player gets 90% of their income from the extra 2 baskets they make every game.

Bringing the topic back to IT

Since I thought it would be good to set up what marginal utility is and offer an illustration, it seems to me that we can spend a couple of weeks on this subject. We can speak about designing marginal utility at the individual, team and organizational levels.

So while we have the notion of salaries fresh in our minds, let’s start with you and me, shall we?

First, let me make my intentions really clear: I accept that people say money isn’t everything. People don’t have to slave and toil to get paid more. There is nothing morally ‘right’ or ‘wrong’ about wanting higher pay or not.

Remember that the topic is marginal utility in the domains of software and IT. So I am just speaking of the topic about how much we get paid. That’s all – I have no judgments and am not making any recommendations – “I’m just sayin’.”

I have nothing particularly witty to write this time - this is a piggy bank on a pile of money.

In the basketball analogy, good players don’t become professionals. There is nothing wrong with them – they’re good… just not valued highly enough to get in at that level of competition.

In my career, most of the IT people I’ve met are good.

They get paid what the market bears for their roles, which our industry declares clearly and consistently in job descriptions from one company to the next.

A Java developer is a Java developer, and they make a certain amount of money. They make a little more as a consultant, generally speaking.

A “senior” Java developer wants to get paid more, but the standard for assessing what “senior” means is not well established.

And don’t get me started on what an “architect” really is in all its various derivations… except they also expect to get paid more, and have higher expectations to live up to.

The point is: as long as what defines your capabilities and accomplishments is the same as everyone else, the market sets your rate pretty clearly.

In this situation, your income fluctuates with the market, and you are a commodity, in a sense. A business may see you as replaceable, you may struggle to find your next role and you may feel trapped in roles, feeling underpaid and undervalued.

On the other hand, when you find those strengths that you bring to bear – those things that makes you incrementally more valuable than someone else in your role – that could be marginal utility (your “2 baskets more“) for which you compel other to pay a premium.

Just be careful in thinking that what you value about yourself is what they value, and that you deliver enough that they will feel your premium is worth it.