Demand Management does not mean what you think it means

So can we stop mangling the term in the same way people have destroyed the word “theory” over the last 50 years?  A theory is not some cockamamie idea you thought up 5 minutes ago but a rational, supported, tested explanation for a large body of verified observations and experimental outcomes.  Oh, sure, you can find the cockamamie definition in the dictionary right under the proper definition but only because the lazy got tired of saying “hypothesis”.  Can we not do that to Demand Management?  Pretty please?

Demand Management is NOT the same thing as Capacity Management, all management buzzword usage to the contrary.  I participated in a rather agreeable all-day workshop with a client and several vendors yesterday where the topic du jour was “Capacity Management”.  For the first three hours I thought I might have stepped into a semi-Orwellian doublespeak language seminar (my deepest apologies to the venerable legacy that is George Orwell).  The problem: this client has not the least bit of control over their enterprise storage capacity, even from a basic “how much do I have?” perspective.  Coincidentally, the client had to postpone the start of our workshop to address the uncomfortable fact that one of their primary data centers completely ran out of storage to provision for critical applications.  The solution: we should all talk about this as a Demand Management problem until somebody’s head explodes.

ALL STOP.  Head asploding.

I like to keep things simple, so when I had the floor for 30 minutes I decided to hit this issue head on.  Capacity is the stuff you have, whether it is storage, paint or tickets for your theme park.  Demand is the thing that consumes the stuff you have.  Those are data, painters or visitors.  Managing capacity happens because of demand.  If you are running out of storage or paint, you buy more.  Capacity management tells you when to buy more, how much more to buy and when you are likely to run out again.  If you are running out of space at your theme park you can add more rides or buy more land, except when you cannot.

We are unlikely to ever run out of actual space to buy more storage or house more paint except against the almighty budget.  At a theme park the problem is more acute: you only have so much space to build rides and host guests before the fire department shuts down your trample factory.  What is the budding Walt Disney to do?  Enter Demand Management.  When capacity is inelastic (fixed) but demand is not the theme park has to employ methods to directly influence that demand.  They do this by raising ticket prices or offering a tiered pricing package to encourage attendance on days and at times when demand is normally low.  This is why annual passes have blackout dates.  If you want to avoid those blackout restrictions the park is happier to charge you more for the privilege.  Everybody wins, so long as the demand management techniques (price increases in this example) are not so draconian as to send the ever important customer to someone else’s theme park.

There is a catch: until you have completely (or very nearly) mastered Capacity Management you cannot begin to consider demand management.  There is no point, really.  Back to our bursting theme park, if you are not able to report on how many guests show up, what rides they prefer, when they arrive, when they leave and so forth you do not have the most basic information to guide a Demand Management approach.  This is a calculus of give and take that demands you have one more tool at your disposal, too.  You need to have a carrot or two, not just a stick.  For our theme park the carrots are pricing and wait time reduction.  If you come on a slow day for our park we will charge you less.  If you agree to postpone your visit to the roller coaster for an hour we will give you a fast pass to avoid the lines.  Now we can use our capacity more efficiently and get more use out of the same investment.

There is nothing whatsoever different about this concept when we start tracking our IT resources.

To implement effective Capacity Management you must understand the demand just as in our example above, but that is not synonymous with managing the demand.  Capacity Management is just demand reporting with the addition of forecasting and some event triggers.  Most IT shops have no business talking about Demand Management until we have some Capacity fundamentals in place and the ability to influence our consumers through chargeback or service level agreements.  I have a theory about why these practical Capacity Management discussions so frequently metamorphose into philosophical Demand Management lectures but the research has not been peer reviewed and is largely anecdotal.  I will leave you with my hypothesis, instead:

We are too embarrassed to admit we have not got our IT capacity needs under control even as growth is rocketing, so we try to elevate our language and sound more mature than we really are.  That just avoids solving the problem.  Words have meaning.  Let us not redefine the terms and prolong the pain.  The dictionary is pretty full as it is.

This entry was posted in Future of IT, The Nature of IT, This is Why We Can't Have Nice Things and tagged , , , , , , , , , , , , . Bookmark the permalink.

2 Responses to Demand Management does not mean what you think it means

  1. Robo says:

    Pete, I like this write up a lot… it’s really a two headed management snake: Demand & Capacity. While I totally concur that in order to become GREAT at Demand Management, you must first become GREAT at Capacity Management, because so much of the standard functions of CapMgmt (process, data/tools, predictive forecasting & deployment execution) needs to be set, in order to carry the process forward to early in the project lifecycle for Demand Management (they are intertwined disciplines with connecting process & data).

    However what I would diverge from your point a little is to consider fixing the problem more pragmatically… a pincer move if you will. We need to fix both domains simulatneously using crawl-walk-run thinking. As we nail down an ecosystem for CapMgmt capability, we can at the same time begin to control DemMgmt, and patiently mature each space over time… building the railroad tracks so they can meet in the middle eventually.

    The benefit? While we fix the “problems” of lacking CapMgmt on the back end of the shop, we can at the same time begin to improve the End User experience with small but important incremental improvements in DemMgmt… and use some of the carrots you speak of … start your planning for NEW projects 12-9 months in advance with us and we will guarantee you will have your resources on time and if you dont, we wont. As we mature this, another carrot: we will offer the resources at a lower cost if you comply with our new process & standards. Support that with rudimentary early planning/forecasting tools… while on the backend building the ref architecture standards, the service packages and the service catalog.

    Your points are spot on – Im just adding some thinking around a more dynamic “move forward” approach for IT shops facing this dilemma you so clearly articulated 🙂

  2. Peter says:

    @Robo: The elephant in the room I assiduously avoided discussing was the fundamental problem of IT cost recovery. Implementing “Proper” demand management means having to run IT as a business, which means chargeback. I talked about some of the issues with that, here: http://www.practicalpolymath.com/?p=988

    That said, IT rarely has control over pricing, so the secret sauce is in building a carrot/stick model (like you describe) that accommodates that restriction while still figuring out how to throttle demand without destroying customer satisfaction. It’s tough, hence my hope to keep IT focused on the first order problem, first, while those creative models are developed in parallel. It’s the whole “we fund our infrastructure on a project by project basis” model that needs to be shattered. The folks doing ITaaS or IaaS presumably have done that already. There are some great examples I wish I could share on the blog but I can’t because of client confidentiality.

Leave a Reply

Your email address will not be published. Required fields are marked *