ITIL Demand Management misunderstood

Demand Management is a ghost practice that doesn't get mentioned as often as some other ITIL V3 practices. When it does get mentioned, the understanding of it is often wrong. It is a key operational practice, not some strategic activity left to the executive management. I look forward to seeing how it is reworked in ITIL V3 2011

Demand Management is a much misunderstood practice (not "process"). I've seen it refered to as a gating mechanism to the Service Portfolio. Not so. That would be Portfolio Management. If you (bravely) read Service Strategy, it is in fact an operational process conducted by the business to control user demand for service transactions, NOT customer demand for new services.

Here is an interesting exercise: what does the Official Introduction to The ITIL Service Lifecycle say about "Demand Management"? Nada. Not even in the index, though it shows up in a few diagrams and a bullet list on p25.

Service Design does mention Demand Management in the place where you would most expect it to do so, Capacity Management, on p84. But of course more people claim to have read the five books than actually have (many millions of people were reportedly at Woodstock). I still see Demand spoken about as management of demand for new services. I'm particularly sensitive to it because I did it a lot before the penny dropped for me.

So if Demand Management is about modulating user demand for a service not customer demand for new services, then where might we expect to see it. In Capacity Management, as noted. In Financial Management, and yes as noted Service Strategy understands it. Service Operation discusses feedback loops but it focuses on measurement of IT-centric metrics and leaves "service quality" metrics to CSI. Apparently this includes measuring how busy the system is, how many transactions are being executed, because I can't find anything about load in Service Operation. Continual Service Improvement does reference Demand correctly, on p120.

One of the primary service reporting metrics needs to be load. If load is approaching the limits of capacity then - in some businesses - immediate action is required to reduce demand. Less often, the reverse is also true: when demand falls, something needs to be done to stimulate demand to ensure utilisation. This could be a daily or even hourly activity for some, not just the output of a monthly or annual capacity planning review. We get all worked up about CPU and storage but I don't often see transactional load monitored as a capacity issue in its own right. We can adjust the tech stuff by finding more kit, but the load issue needs to be escalated to the business to deal with by adjusting price, entitlement, availability, desirability or some other variable to reduce (or increase) demand.

Comments

I don't see Demand

I don't see Demand Management as an operational, reactive activity to be triggered when maximum capacity is about to reach a certain threshold, and only to constrain resource usage.

Demand Management is in the "Strategy Management" book for a reason.For example, a Telco company will usually charge more for a call at 11:00 a.m. than for a call at 11:30 p.m. They will even release marketing promotions so encourage customers talking during nights and weekends. And this is a strategic decision, not just operational.

Why? Because they want to encourage people to talk more during the time when their networks are less used, to get more money from this infrastructure that is being underutilized. They want to get more return of investment from this fixed asset, during typically unused time.

On the other hand, they are discouraging users from talking more during the peak hours of network utilization, because otherwise they would have to make non-optimal investments to grow their network. This is an investment related, strategic decision.

In the other hand, maybe a telco has reached 99% of penetration in a market. In this case, they want to encourage growth by introducing new services, not selling more mobiles to new users, which might not exist in this market. This would be a new market space, that will encourage new patterns of demand and different actions for demand management. In this case, for encouraging more demand for new services (like data services, media content, push-to-talk, etc). So Demand Management is not only about restricting demand, but can also be about encouraging demand to make more money or reinvent the market.

Operational reaction due to load monitoring is at resource capacity level. Demand management is at business and service capacity level, not resources capacity. Without forgetting, of course, how there are related among themselves.

The way I see it and way I

The way I see it and way I teach it is exactly the way explained by Horacio.

Demand Management is about understanding demand and influencing it.

This is done 100% at the strategic level. That's why it is at the Service Strategy book.

Skeptic, what you are calling "demand management at the operational level" for me is part of the ITIL Capacity Management sub-process called Business Capacity Management.

I have a crazy theory on how

I have a crazy theory on how Demand Management evolved in ITIL v3.

Demand Management used to be part of the v2 Capacity process/capability.
Before ITIL v3 was being worked on, Demand Management was used in all kind of other contexts (such as Sourcing Governance, Business Information Management), with possibly different meanings.

Before ITIL v3 books were written, a rough sketch was drafted, in which Demand Management was explicitly taken out of Capacity Mgt, and sent to Strategy for reasons mentioned above.

The authors of the strategy book were different than those who created the rough sketch, and when they ended up at this chapter, they took a bit from v2, a bit from the other contexts and a bit from their own. Hence you got the v2 explanation (chapter 5.5.1 - challenges in managing demand), patterns of business activity (which is highly focused on in exams) and Service (level) Packages, which sounds more Product Management type and could just as well be included in Catalog or Portfolio Management.
Alltogether a bunch of related, but not connected concepts.

Maybe IT'IL be fixed in ITIL 2011?

I agree demand mechanisms

I agree demand mechanisms are decided at the strategic level, and designed into the service. What I was getting at, but didn't say well, is that it is ALSO an operational mechanism. For most folk reading this blog, it impacts mostly due to its integration with capacity.

And as I DID say in the post, yes it can be a positive and/or negative mechanism

two faces of demand management

From 2007. The large outsourcer mentioned in this blog is Accenture.

http://www.erp4it.com/erp4it/2007/01/the_two_faces_o.html

There is plenty of precedent that demand front ends the service portfolio, ITIL notwithstanding.

Charles T. Betz
http://www.erp4it.com

Demand Statement? Nailing processes to lifecycle jelly?

In my experience working as a product manager with a worldwide product portfolio with revenue targets in excess of $20m, I had to create 'demand statements' and a 'demand plan' developed form research of market trends and assumptions developed by my marketing research folks. The demand statement was key input to the product planning activities that called into play financial estimates of the cost of operation/support of the product.

The accuracy of the demand statement hinged heavily on understanding what activities prospective or actual customers would perform, from what locations, with what frequency and so on. Traditionally, this has been a skill resident in 'capacity management' functions, and particularly 'finite capacity scheduling' skillsets of manufacturing fame. There is a bridge from Finance to Capacity, you just cannot succeed at financial management of resources without this capability. There is also a vital bridge between capacity and continuity planning - and I would suggest the latter has challenges without information on various demand positions.

The movement of demand management to Strategy in ITIL V3, seems to make sense but illustrates the challenge the authors set themselves trying to nail 'processes' in stages of the lifecycle. They don't easily fit, because they can play a role anywhere along the lifecycle! This was exactly the proposal we tabled to the requirements team in 2005 - yes write a lifecycle book if you must be please respect existing product development methodologies that have more than addressed this topic. Remember, a service is a type of product.

As for the lifecycle itself, it does not even reflect the dated thinking of service management circa 1975, when the elements of a service management 'system' were first proposed. One clue, there is currently (Edition 2011 may address this) no real-time 'service transaction' processing component to reflect the fact that 99.999% of service requests are processed outside of the service lifecycle.....

Way back then they realized that customer activity and how they interact with products and services, and the service provider organization, DRIVES INTERNAL WORK EFFORT and costs. They created the term 'outside-in' to distinguish thinking from the customer perspective. They developed a service system concept to tackle the challenge. So far, ITIL has completely missed this and continues to speak inside-out. I look forward to seeing how the extreme makeover authors untangle the lifecycle/process nailing debacle...

Syndicate content