A New Model for IT Demand Management

Why do so many IT leaders do such a terrible job of running their departments like a business? Because they put too much emphasis on supply and not enough on demand.

Excerpted from IT Success: Towards a New Model for Information Technology by Michael Gentle (John Wiley & Sons, October 2007), $35.00.

In order to manage planning, production and delivery, any properly run business has to be able to balance orders for its products and services (i.e., demand) with its ability to produce them in terms of resource and scheduling constraints (i.e., supply). Otherwise it might produce too little of what is required, too much of what is not required, or deliver late, or have problems with product quality or customer satisfaction.

IT Success

The average IT department, though not a business from a profit and loss perspective (the exceptional IT profit-center notwithstanding), has a resource base comprising highly paid specialists, produces highly complex products and services, and has an annual budget of anywhere from two to 10 percent of annual revenue. Yet it does a very poor job of managing—when managing at all—basic supply and demand. It generally has very little understanding of its demand and supply chains, and would have a hard time being able to answer fundamental questions like, "What is currently in the pipe?" or, "What do we have to deliver over the next 6 months?" or, "What is our projected resource utilization for the next quarter?"

It can also end up delivering products which don't correspond to what the customer really wants—or, paradoxically, products which do correspond to what the customer wants, but did not yield the desired results, even though built close enough to spec.

In short, when it comes to supply and demand, IT is unduly focused on the supply side of the equation, or the how (project management, software development and managing physical assets like hardware and networks)—to the detriment of the demand side, or the what (capturing and prioritizing demand, assigning resources based on business objectives and doing projects that deliver business benefits).

At the risk of exaggerating the point, it's almost as if once IT has a green light to deliver a project, it couldn't care less about whether the project makes sense or will deliver business benefits—it's only objective from here on will be to deliver it to spec, on time and within budget, and manage the underlying physical assets. Put another way, IT is only concerned with building the system right, not with building the right system. The criteria for success is defined as the delivery of solutions on time, within budget and to spec—like a building contractor—instead of the delivery of solutions which deliver business benefits.

However regrettable this tunnel vision may be, it is totally understandable, because that's how the traditional IT business model and its client/vendor relationship works. IT focuses on managing supply, because that's its mandate; managing demand is unclear, and in the absence of proper governance, it defaults to a business problem on the customer's side. Projects are therefore usually approved based more on business sponsor influence —or putting it less charitably, decibel management, or catering to those executives who shout the loudest—rather than on any rational decision-making process. This might appear to be a rather harsh indictment of the demand chain in the average IT department today, but unfortunately it corresponds to reality. Far from being the rational and structured process we would like it to be, demand management is usually a nebulous combination of decibel management and organizational politics, significantly amplified in international organizations when country politics and cultural differences are thrown into the mix.

Once projects have been delivered, the absence of rational demand management becomes even more acute. While you can usually count on business executives to obtain the funding to launch projects, the same is rarely true to fund the resulting applications after delivery. This is usually because the executive sponsor has either moved on (often as a result of the project's success—or failure) or is far less motivated to go and bat for operational funding, which doesn't have the same visibility and organizational rewards as launching a new project—especially when, as is usually the case, the magnitude of the ongoing funding was not part of the original business case.

For example, a marketing director at a pharmaceutical company had little problem obtaining significant funding for a sales force automation (SFA) project. A month after the implementation however, he moved on as part of a company reorganization. In the absence of a business sponsor, the maintenance budget for the following year was next to nothing, which seriously impacted usage because significant further enhancements remained to be done—which, needless to say, was not part of the original business case.

So demand management is clearly the missing link in most IT departments. Yet any successful business model by definition has to be built on the effective management of demand as well as supply.

Using the fundamental premise that not all demand from the business will be approved—because of business priorities on the one hand, and IT resource and scheduling constraints on the other—the best way of representing demand would be via a funnel. Demand from the business enters at the top, follows one or more decision-making processes, and then either exits at the bottom as approved work to be executed, or remains in the pipeline pending further evaluation.

The first stage (or gate, or stage gate) of the funnel represents "ideas" or opportunities, which comprise only high-level information and estimates for timescales, costs and benefits. Ideas generally represent work intake that IT has not yet had the chance to evaluate in detail, but which needs to be acknowledged as having entered the pipeline.

As part of a filtering and screening process, these ideas then move down to the next stage, called "project requests," during which they are further qualified with quantifiable cost and benefit information, to a level of detail which makes high-level planning and a cost-benefit analysis possible. It is during this stage that the business case is built for executive sponsorship and approval.

Finally, once the business case has been approved, the project request moves down to the stage where it becomes a project—though strictly speaking these would not just be new projects, but also work related to production applications, upgrades, etc. At this stage, detailed planning, budgeting and resource allocation (where possible) takes place.

Demand for IT products and services originates from customers in the business in the form of ideas or opportunities, with high-level information on timing, costs and benefits.

At the one extreme (unfortunately quite common), IT is simply an internal service provider operating under the traditional client/vendor model and focused on satisfying user requirements. In essence it is a passive order taker disconnected from the business and not involved in understanding what lies behind customer demand.

At the other extreme (unfortunately not very common), IT is a strategic differentiator and is part of a joint IT/business group responsible for process improvement and business innovation. Here we would have account managers responsible for understanding customer demand and full IT participation in the decision-making and approvals process. This will be covered in more detail in chapter eight of IT Success: Towards a New Model for Information Technology, when discussing roles and responsibilities under the new business model, but at this stage let us focus on capturing and managing demand, regardless of how it occurs.

There are two categories of demand: planned and unplanned.

Planned demand arises as part of the annual planning process, which results in the "IT Plan" (which is what IT is supposed to deliver) and the corresponding budget for the next financial year. This would be the case for large, departmental or enterprise-wide projects which cannot be funded on-the-fly during the current budget cycle, but also for keeping the lights on.

Unplanned demand corresponds to the huge amount of unpredictable work that IT does which is not contained in well-defined project structures. These include things like change requests, feature requests and bug fixes which arise from changing business and regulatory environments, changes in strategy, company reorganizations, mergers and acquisitions, insufficiently tested systems, etc. Some of these requests will become input for the next planning cycle, but most will have to be done inside of the current budget cycle.

For those who believe in the myth of the sacrosanct "IT Annual Plan," remember it's just that—a myth. In the real world demand is coming in every single day, so the challenge is to capture that demand, both planned and unplanned, as early as possible, expose the high-level business justification and set up an ongoing dialogue between IT and its customers. This enables the management of a demand pipeline. An opportunity analysis on this pipeline, based on an appropriate scoring model, will give rise to an initial screening and validation process which will enable an idea to move down to next stage and become a project request. Typical examples of filtering criteria for a scoring model are expected revenue, expected cost reduction, regulatory compliance or operational improvements.

Excerpted from IT SUCCESS: TOWARDS A NEW MODEL FOR INFORMATION TECHNOLOGY

John Wiley & Sons, Inc.

October 2007

ISBN 978-0-470-72401-9

192 Pages I US$35.00

Michael Gentle

Michael Gentle has over 25 years of experience in IT departments, consulting companies and software vendors in Europe, North America and Asia-Pacific. He has a degree in mechanical engineering, with further stints in aerospace and computer science. He is also the author of The CRM Project Management Handbook.

Join the discussion
Be the first to comment on this article. Our Commenting Policies