ITIL-Demand Management: A Concise Tutorial Just An Hour – FREE

Last updated on 08th Jul 2020, Blog, Tutorials

Demand Management is a very important and critical process in service strategy. It helps to understand customer demand for services so that appropriate capacity can be provisioned to meet those demands.

Improper demand management leads to improper use of services and resources. Hence it’s worth analyzing the customer’s demand.

Demand Manager is the owner of this process.

Strategical Level Demand Management

Strategical Demand Management focuses on two important things as discussed below :

Pattern of Business Analysis (PBA)

PBA is an extremely important activity achieved by knowing customers how they operate and future requirements they might need.

User Profiles

It is the demand pattern shown by users. It can be processes, people or functions.

Tactical Level Demand Management

Under tactical level demand management, we focus on Differential Charging. It is a technique to support Demand Management by charging different amounts for same IT Service Function at different times.

Service Packages

It has two components as discussed below:

Core services

That are the basic services for which the customer is willing to pay. They bring actual value to the customer.

Support services 

Enhance value proposition of core services i.e. added features to key services.

Developing differentiated offerings

Packaging of core services and supporting services has implications for design and operation services. It is required to decide whether to standardize on the core or supporting services. One can arrive with the same level of differentiation of in service offering taking different approaches to packaging as shown in the following figure.

Service Level packages

Service packages come up with one or more Service Level Packages (SLP). Each of the service level packages provides a definite level of utility and warranty from the perspective of outcomes, assets, and PBA of customers.

Service Outage Analysis

The detailed analysis of service interruptions can identify opportunities to enhance levels of Availability. SOA is a technique designed to provide a structured approach to identify end-to-end Availability improvement opportunities that deliver benefits to the User. Many of the activities involved in SOA are closely aligned with those of Problem Management. In a number of organisations these activities are performed jointly by Problem and Availability Management.

The high level objectives of SOA are:

• to identify the underlying causes of service interruption to the User
• to assess the effectiveness of the IT support organisation and key processes
• to produce reports detailing the major findings and recommendations
• to initiate a Programme of activities to implement the agreed recommendations
• that Availability improvements derived from SOA driven activities are measured.
  

The key principles of the SOA approach are that:

• the underlying reasons for service interruption can be caused by shortfalls in technology, process, procedure or behaviours (culture)
• wider ranges of data sources are used to support the analysis
• business and User input is fundamental
• a specifically mobilised cross-functional team undertakes that analysis
• SOA assignments have a recognised sponsor(s) (Ideally joint sponsorship from the IT and business).

The reasons for adopting an SOA approach are:

• traditional IT Availability reporting often only provides an IT component perspective
• business and User input provides an ultimate view of Availability and the important issues from their perspective
• it provides a structured, focused and detailed analysis of a selected IT Service or set of Infrastructure components
• it provides a mechanism to ensure the IT Infrastructure delivers optimal Availability.
  

The benefits from taking an SOA approach are that:

• it can enable requests for enhanced levels of Availability to be met without major cost
• it provides the business with visible commitment from the IT support organisation
• it develops in-house skills and competencies to avoid expensive consultancy assignments related to Availability improvement
• the cross-functional team approach is an enabler to ‘think outside of the box’ to challenge traditional thinking and provide innovative and often inexpensive solutions
• SOA delivers a programme of improvement opportunities that can make a real difference
• SOA improvement opportunities are focused on delivering benefit to the User
• it provides an independent ‘health check’ of IT Service Management processes and is the stimulus for process improvements.
  

A structured approach

To maximise both the time of individuals allocated to the SOA assignment and the quality of the delivered report a structured approach is required. This structure is illustrated in Figure 8.19 shown below. This approach is similar to many consultancy models utilised within the industry and in many ways Availability Management can be considered as providing via SOA a form of internal consultancy.

The above high level structure is described briefly as follows:

Select Opportunity

Prior to scheduling an SOA assignment there needs to be agreement as to which IT Service or Infrastructure is to be selected. Within the Availability Plan it is recommended that 4 assignments are scheduled per year and if possible the IT Service is selected in advance as part of the proactive approach to Availability Management. Before commencing with the SOA it is important that the assignment has a recognised sponsor from within the IT organisation and/or the business. This ensures organisational visibility to the SOA and ensures recommendations are endorsed at a senior level within the organisation.

Scope Assignment

This is to state explicitly what areas are and are not covered within the assignment. This is normally documented in a Terms of Reference issued prior to the assignment.

Plan Assignment

The assignment needs to be planned a number of weeks in advance of the assignment commencing. The typical areas that require advance planning are:

• the start and end dates of the assignment
• key milestones, e.g. delivery of final report
• the individuals who form the SOA team
• role and responsibilities of the individual team members
• the data sources required to provide the data for analysis
• premises and equipment, i.e. a dedicated room, whiteboards, terminals etc.
• an interview schedule for key IT and business personnel
• a visit to the business operation and the IT operation.
  

The SOA assignment should be looking at identifying improvement opportunities that benefit the User. It is therefore important that an end-to-end view of the data and MIS requirements is taken. A suggested list of data sources is as follows:

• Incident Management records and MIS
• Problem Management records and MIS
• Change Management records and MIS
• SLAs and Service Level reporting
• Vital Business Function measures that reflect User impact
• formal complaints to the business from their Customers
• formal complaints from the business to the IT organisation
• Customer satisfaction survey results
• process metrics.

For practical reasons the coverage period for the above should be limited to approximately 6 months. This limits the amount of data to analyse but, importantly, ensures that only current issues are being investigated.

To support the team with analysis, supporting documentation should be available to the team, e.g. operational procedures, process documentation, IT policies, configuration diagrams, Industry best practice reference material, e.g. ITIL.

Use Demand Management

Users with the demand manager role can create, view, and modify demands using the Demand Management application.

You can also approve demands and create the following artifacts from the approved demands:

• Project
• Change
• Enhancement
• Defect

The type of artifact created from a demand depends on the selections in the Category and Type fields on the Demand form. Enhancements and defects can be created when the system administrator has activated the SDLC-SCRUM plugin.

Demand Management Life Cycle:

The demand management life cycle can be simplified as follows:

• Creating a demand: The user submits an idea and the demand manager approves the idea, automatically creating a demand from that idea.

• Viewing a list of demands: The demand manager views demands on the demand workbench or from a list view.

• Enhancing a demand: The demand manager can send the demand to screening, which sends assessments to stakeholders.

• Assessing a demand:
  • The demand manager can screen the demand and send surveys to stakeholders to complete assessments.
  • The demand manager can set the state of the demand to qualify, defer, or incomplete.
  • Demands can be analyzed and approved using the demand workbench.

• Creating an artifact: The demand manager creates a project, enhancement, change, or defect.

In demand management, a demand can be in any of the following states.

The demand management application uses the following simplified demand states.

State	Description
Draft	The demand manager accepts a submitted idea.After reviewing or editing the record, click one of these buttons: Update: The demand record is updated, but the demand remains in the current state. Submit demand: The demand is moved to the submitted state. Delete: The demand record is deleted.
Submitted	An accepted idea creates a demand record and the demand manager submits the demand.After reviewing or editing the record, click one of these buttons: Update: The demand record is updated, but the demand remains in the current state. Screen: The demand is moved to the screening state. Qualify: The demand is moved to the qualified state. Defer: The demand is moved to the deferred state. Incomplete: The demand is moved to the incomplete state. Delete: The demand record is deleted.
Screening	The demand initiates assessments for the demand.After reviewing or editing the record, click one of these buttons: Update: The demand record is updated, but the demand remains in the current state. Qualify: The demand is moved to the qualified state. Defer: The demand is moved to the deferred state. Delete: The demand record is deleted.
Qualified	The demand has been qualified and is ready for review.After reviewing the record, click one of these buttons: Update: The demand record is updated, but the demand remains in the current state. Approve: The demand is moved to the approved state. Defer: The demand is moved to the deferred state. Delete: The demand record is deleted.
Deferred	The demand has been put on hold. The demand can be revisited in future and reviewed.After reviewing the record, click one of these buttons: Update: The demand record is updated, but the demand remains in the current state. Approve: The demand is moved to the approved state. Reset to Draft: The demand is moved back to the draft state. Delete: The demand record is deleted.
Approved	The demand is approvedAfter reviewing or editing the record, click one of these buttons: Update: The demand record is updated, but the demand remains in the current state. Close: The demand is moved to the closed state. Delete: The demand record is deleted.
Completed	The demand is moved to the completed state.

These states appear in the process flow indicator at the top of the Demand form. The process flow indicator:

• Highlights the current state of the demand.
• Checks off the states that a demand has passed through.
• Leaves blank the states that have been skipped.

In this example, the demand is in the Approved state. It passed through the Draft, Submitted, and Qualified states but skipped the Screening state.

Submit an idea from Self-Service or Service Catalog

All users can submit ideas from the Service Catalog or from the Ideas module in Self-Service.

Assess demands

The Demand Management application comes with two demand visualization tools that can aid decision makers with demand assessment.

Demand tasks

A demand task is a unit of work, created within a demand, to break down initial planning activities before converting the demand into a project, change, enhancement, or defect.

Actual cost and effort calculation for a demand and demand task

The actual cost and effort are realized cost incurred and time spent for the work performed on a demand and demand task during a specific time period. Actual cost and effort are calculated based on the approved time cards and hourly rate for the resources and vary based on how the hourly rate for the resource is derived.

Create a demand

Create demands to capture your strategic and operational demands.

View demands

You can view existing demands at any time.

Add details to demands

The demand manager typically works with a business relationship manager to identify stakeholders and elicit requirements, risks, and other important information.

RIDAC (Risk, Issue, Decision, Action, and Request Changes) record entries for a demand

RIDAC is an acronym for Risk, Issue, Decision, Action, and Request Changes records. Create a risk record for your demand that you can convert to other records during the demand life cycle to track issues and to avoid having to manually copy relevant details in related records. This conversion and association of records helps you analyze and identify patterns, trends, and probable resolution for planning future demands.

Reset a demand to Draft state

A demand can be moved back to Draft state, if required.

Delete demands

Demands can be deleted only while in the Pending state.

Move and resize a demand

As the demand manager, you can move and resize bubbles in the bubble chart.

Stage fields

The Stage field on the Ideas list displays the current state of an idea as it moves through the demand life cycle. The current state includes from an idea to a demand and then to the resulting project, enhancement, change, or defect.

Composite fields

A composite field combines information from two fields in a table to form a single field.

Build Hypotheses

This is a useful method of building likely scenarios, which can help the study team draw early conclusions within the analysis period. These hypotheses can be built from discussing the forthcoming assignment with key roles, e.g. Senior Management, Problem Management, Change Management, and Service Level Management or by using the planning session to brainstorm the list by the assembled team.

The completed hypotheses list should be documented and input to the analysis period to provide some early focus on data and MIS that match the individual hypotheses. It should be noted that this approach also eliminates perceived issues, i.e. no data or MIS substantiates what is perceived to be a service issue.

Analyse Data

The number of individuals that form the SOA team dictates how to allocate specific analysis responsibilities.

During this analysis period the hypotheses list should be used to help draw some early conclusions.

Interview key personnel

It is essential that key business representatives and Users are interviewed to ensure the business and User perspective is captured. It is surprising how this dialogue can identify quick win opportunities as often what the business views as a big issue can be addressed by a simple IT solution.

The study team should also seek input from key individuals within the IT support organisation to identify additional problem areas and possible solutions which can be fed back to the study team.

The dialogue also helps capture those issues that are not easily visible from the assembled data and MIS reports.

Findings and Conclusions

After analysis of the data and MIS provided, interviews and continual revision of the hypothesis list, the study team should be in a position to start documenting initial findings and conclusions.

It is recommended that the team meet immediately after the analysis period to share their individual findings and then take an aggregate view to form the draft findings and conclusions.

It is important that all findings can be evidenced by facts gathered during the analysis. During this phase of the assignment it may be necessary to validate finding(s) by additional analysis to ensure the SOA team can back up all findings with clear documented evidence.

Recommendations

After all findings and conclusions have been validated the SOA team should be in a position to formulate recommendations. In many cases the recommendations to support a particular finding are straightforward and obvious.

However, the benefit of bringing a cross functional team together for the SOA assignment is to create an Environment for innovative ‘think outside of the box’ approaches. The SOA assignment leader should facilitate this session with the aim of identifying recommendations that are practical and sustainable once implemented.

Report

The final report should be issued to the sponsor with a management summary. Reporting styles are normally determined by the individual organisations.

It is important that the report clearly shows where Availability loss is being incurred and how the recommendations address this. If the report contains many recommendations an attempt should be made to quantify the Availability benefit of each recommendation together with the estimated effort to implement.

This enables informed choices to be made on how to take the recommendations forward and how these should be prioritised and resourced.

Validation

It is recommended that for each SOA, key measures that reflect the business and User perspectives prior to the assignment are captured and recorded as the ‘before’ view.

As SOA recommendations are progressed the positive impacts on Availability should be captured to provide the ‘after’ view for comparative purposes. Where anticipated benefits have not been delivered this should be investigated and remedial actions taken.

Build Programme

Having invested time and effort in completing the SOA assignment it is important that the recommendations once agreed by the sponsor are then taken forward for implementation.

The best mechanism for achieving this is by incorporating the recommendations as activities to be completed within the Availability Plan or SIP.

It is recommended that these activities are also managed and tracked by Programme Management, Project Management and Change Management processes.

The SOA team

The team should consist of experienced IT practitioners selected from a range of areas within the IT organisation.

For example the SOA team could consist of individuals from the following functions:

• Availability Management (possibly process owner and SOA assignment leader)
• Computer Operations
• Network Management
• Problem Management
• Change Management
• Service Desk
• Service Level Management
• User
• 3rd party supplier
• a leading technical expert.

The size of the team should be influenced by the size of the IT organisation and the topic selected for the SOA. A team of at least three is the recommended minimum.

The focus of the SOA assignment determines which of the above it may be advisable to include or schedule within the assignment plan.

As scheduled events, the Availability Management process owner should have these events defined within the Availability Plan and identified Resources committed in advance.

Measure SOA effectiveness

SOA should be viewed as a key element of the Availability Plan that underpins the Availability Management process. Measures should be established to monitor the effectiveness of SOA as an organisational activity and in optimising service Availability.

To measure the effectiveness of each SOA the following metrics could be used: –

• number of recommendations
• number of recommendations rejected
• number of recommendations completed
• number of recommendations in progress
• number of recommendations with no progress.
  

Challenges in Demand Management

Demand Management is critical process of service strategy. The challenges that occur in this process are as shown below:

• Improper analysis of customer’s demands lead to improper use of capacity. Excess capacity generates cost without creating value.
• Sometimes certain amount of unused capacity is necessary to deliver service levels. Such capacity is creating value through the higher level of assurance made possible with the higher capacity.
• It is required to have service level agreements, forecasting, planning, and tight coordination with the customer to reduce uncertainty in demand.
• Service production cannot occur without concurrence presence of demand that consumes the output.
• Arrival of demand is also influenced by demand management techniques such as off-peak pricing, volume discounts, and differentiated service levels

Value to the Business

The main value of demand management is to achieve a balance between the cost of service and the value of the business outcomes it supports. The other service strategy processes define the linkage between business outcomes, services, resources, and capabilities.

Demand management refines the understanding of how, when and to what level these elements interact. This enables executives to evaluate the real investment required to achieve business outcomes at varying levels of activity.

Conclusion

The above measures provide a clear indication on how progress is being made with each completed SOA assignment. The number of recommendations rejected may reflect the quality of recommendations made. Conversely a high completion rate would indicate the ‘do-ability’ of the recommendations made.