Why an article about demand management on a business analyst blog? Because in my experience BAs are more often called on to ensure that work requests are properly vetted, documented and prioritized before being assigned for work. In some organizations a BA (or enterprise BA) performs the role of Demand Manager, the person responsible for overseeing the demand management process. If a BA isn’t currently performing that role in your demand management process or if you don’t even have a demand management process this post is for you.
Let’s define demand management. It is the process by which customer demand is taken in, analyzed, influenced and anticipated. Proper demand management helps IT:
- plan and prioritize their organization’s work, services and assets
- staff the IT organization to support customer needs
- identify trends in demand and help their customers take a more proactive approach to technology needs
- anticipate and budget for future demand
Business analysts are at the forefront of many of these activities in their IT organizations.
A Demand Management Process
I’ve been around a lot of work in-take processes, simple and complex, and what I’ve discovered over the years is that there’s really one process which can be scaled up or down depending upon the type of work requests that are coming in. This framework encompasses the key phases of demand management, critical decision milestones and how work transitions into IT’s software development lifecycle processes and schedules. For the purposes of this article, the steps within the phases are placeholders for activities that an organization can tailor to their needs. They will not be discussed in this post.
My proposed simple demand management process has just 4 phases:
This first phase includes activities around clarifying the problem to solve and deciding if this is a problem that even needs to be solved. This is called Exploring. The purpose of this phase is to explore if this work should be done. The stage gate at the end of this phase asks question “Are we going to pursue this piece of work?” This important question acknowledges the realization that further assessing the work request has a real cost in time and labor to the organization. IT should be confident that the customer or decision-making body wants to solve the problem before time is spent on it. If the answer is “no” at this stage gate, the request is declined. Else, the request moves onto the 2nd phase: Pursuing.
The Pursuing phase involves diving into a high level of requirements and solutioning to understand more about the request and its costs and impacts. This is not intended to produce the full set of requirements for the solution. Just enough to be able to provide a high level estimate. Typically, time is set aside on a recurring basis by skilled BA, architecture, development and QA resources to evaluate these requests. This is the reason that IT must know whether the work is worth pursuing – time is being taken away from planned work to do this evaluation. This step culminates in a second stage gate that answers the question “Are we going to do the work requested?” This request is accompanied by estimate, resource and cost data so the request can be evaluated by the appropriate decision-making entity. A “no” means that the work will not be pursued, and it is declined. A “yes” means that the request will be pursued based on the data provided.
The Planning phase involves obtaining the budget and resources to perform the work. Some of the work may not be formally budgeted – for example, some support work may be part of a team’s Run budget – but an understanding of the costs, time and resources needed for all approved work requests is needed. The Planning phase should be coordinated by the process’ Demand Manager. The organization can decide whether it wants to dedicate a Project Manager for this phase, but at a minimum the activities and outputs of this phase should be documented in a clear and transparent way for the work requestor and to the teams involved in the work’s delivery. There is a 3rd stage gate in this phase which asks the question “Has the priority or need for the work changed?” The reason for this question is to make one final check to ensure that we are going forward with the work given what we’ve learned in the Planning phase. A “no” means the request will be stopped or deferred.
The final step in the demand management is the execution of the work. For larger projects, execution may take the form of the existing software development lifecycle (SDLC) that is in place for the team. In lieu of a formal SDLC or if the work request is relatively small, execution of the work can be an extension of the demand management process. That is, if the demand is tracked in a work in-take tool, the tool can be enhanced to create a development process workflow that will track the stages of the work request.
Categories of Demand
The demand management process is a framework for getting evaluating and approving work requests. Categories of demand will be used to scale the process and identify the specific activities needed to explore, pursue and plan that work.
Standard categories of demand include:
- Projects – large efforts which are needed to meet strategic goals. Projects are generally considered planned work.
- Enhancements – changes or updates to existing systems. Enhancements can be planned or unplanned work.
- Support – work to run existing systems. This can usually be divided into 2 categories: operational requests and service requests.
- Operational requests are work items like applying patches to the OS or installing upgrades to existing systems. Operational requests are usually planned work (or should be). An operational request that is because of an emergency would be treated as a Severity 1 service request.
- Service requests are work items for a discreet activity like reset a password, run a batch job or fix an inoperable system. Service requests are generally unplanned work.
Planned vs Unplanned Work
Within these demand categories, there’s a type: planned vs unplanned work. Planned work is the work that comes to you in advance. It may be cataloged as part of your annual budget process, may come through an existing work in-take mechanism or may be a recurring part of your organization’s “keep the lights on” work. Unplanned work is everything else which comes in the door at any given time with little or no notice. Service requests, bugs and even some enhancements can be unplanned. Both planned and unplanned demand should be captured somewhere and ideally in the same place so it’s easy to see what’s on your plate. By having a single line of sight into all the work, demand can truly be managed
Applying the Demand Management Process
Michael Gentle in IT Success! Towards a New Model for Information Technology uses a funnel analogy to illustrate an ideal demand management process. If you’re familiar with sales funnels, for example, you know that not everything that comes into the sales process will result in a sale. It’s the process of following up on leads, negotiating and making decisions that a sale is either won or the opportunity is passed on. Similarly, every piece of work that comes through your demand funnel may not result in work. Likewise, every request may not the need the same level of effort to get it through the funnel. The image below, borrowed and modified from Gentle’s book, illustrates how the demand dimensions mentioned above might be handled within the simple demand management process I’ve described.
In my next post, I’ll describe the roles that support this demand management framework and define the role of the business analyst in it.