When consulting, I am often asked about the IT demand, how to deal with it and how to decide what to take forward. I’ve covered the topic briefly in strategy section before. Let’s pick the topic a little.
The way IT demand is managed will depend on the established IT or delivery structure and relationship with the rest of the organisation and maturity of the processes. In short, what we do and how we do it.
It is useful to bear in mind what the business relationship management does in ITSM and value management context – identify, stimulate and shape strategic IT demand. It sets the boundaries of how the IT solutions are requested and delivered. The people in this role work across the organisation bridging the business demand with IT delivery capabilities and tracking the value delivery in the process.
I’ve worked in and with the organisations with clear processes for demand intake, triage, prioritisation, assessment, handover to delivery and later analysis of value produced. I’ve also worked for and with the organisations that have no formal arrangements in place and demand is dealt with on ad-hoc basis. The latter approach may work for small organisations and with low IT overall maturity. When the organisation grows and teams grow however, there’s need to put in place some frames. The easiest is to follow the ITIL/ITSM guidance and establish necessary roles and procedures.
I like to use HS2 as an example where we had no formal way of managing demand for IT. I’m generalising on purpose – there should be a single channel for the (internal) customers to interact with the provider (your IT unit). It doesn’t matter what type of IT product or service is requested, the service management tool or an IT process should make it easy for the customer to do so. We were tasked with establishing a process and sub-processes, necessary gates and such to ensure that:
- internal customers can and will go through a single route for requesting new IT
- there’s a framework for classifying demand along with investment requirements, reviews and steering groups
- requests for new IT are tied to budgetary process
- technology debt is effectively managed and…
- value is measured
My team’s focus was on strategic demand. By interacting with the customers, however, it became clear that they may not know what they need and may be unable to understand the implications of new IT solutions. We also noted, that our colleagues may describe a desired solution, not the problem. To counter that, we borrowed a note from the UK Department of Transport IT:
“Describe a problem, not a solution.”
After some deliberation and consulting the service management team, we decided to take the next steps:
- define the process, role and routines.
- The process was initially very simple – capture the demand, assess and contact the requester to understand more.
- Roles were defined as requester, assessor/analyst (IT Business Relationship Manager/Business Analyst), approver (the budget holder and service provider), delivery team (IT service management or project delivery)
- establish a service request form in ServiceNow to capture all new demand. The form was dynamic based on the customer choices and sifted standard SR’s to service desk and the rest in to new IT demand list.
- set up weekly demand review meetings for initial triage, demand correction and future customer education. Here we agreed who will be part of the initial assessment and expected outcomes.
With such an approach we were able to capture 95% of the new IT demand. By collating all the requests already shared with various parts of the IT, we managed to skim the list of 400 down to circa 120 (a lot were repeat requests and substitutes to existing services). By using ServiceNow routing and custom dynamic forms capabilities we were able to produce intelligent ‘interaction’ with the customer. They felt that they are not asked to describe the same thing over again, just clarify detail.
Once the standard ITSM process was in place, we could focus on strategic demand. For that we used a set of questions that formed basis for the conversation. An example would be here:
|What is needed?
|Why is it needed?
|Who needs it?
|Assumed cost and who pays for it?
|What gets better?
|When is it needed by?
|Risks / opportunities?
|Link to corp programme?
This was the initial assessment form and we deliberately chose not to add more information to it than needed for triage – will it go ahead or get rejected. That meant no more than 1-2 sentences per box.
As my team’s focus was on projects, we established a framework for financial and work time impact assessment. For this we set out the following criteria for assessing. Please note that not all may apply.
|Up to €50k
|€50k to €250k
|€250k to €500k
|€500k to €1m
|€1m and above
|Single directorate / unit
|Single directorate / unit
|Multiple directorates / partners
|Org wide / partners
|Org wide / partners
|Up to 1 month
|Up to 3 months
|Up to 6 months
|Up to 1 year
|> 1 year
We anticipated demand to arrive later during the year and thus encouraged our colleagues to engage early and invite us to be part of their thought process. This approach served multiple purposes:
- it enabled IT to have an early signal of business planning and to conduct internal assessments early, without commitment to delivery
- it helped to build trust between people and to build up business expertise within the IT
- it allowed IT to promote existing services and plan necessary changes to those.
The last element, we were asked to do was the hardest – understand anticipated value and be able to measure it. Working with our colleagues from value management team we included a set of goals for any project and measures to track their impact. Each project had to provide at least one of these:
- improve customer experience
- improve business
- streamline processes
- improve data quality
- meet regulatory demand
- reduce duplication
- reduce technology debt
For example, an initiative to introduce a CRM solution helped to improve customer experience, business processes and data quality while reducing technology debt and meet regulatory demand. In this project we transitioned from in-house bespoke system to cloud-based Dynamics CRM, applied data protection policies, designed easy routes for customers to engage with the team, trained people to use the system. We finally had a single source of truth and were able to effectively respond to FOI’s and data requests. All these were assumed benefits that had values to track against once in operation.
I recognise this blog covered more than just demand management, but the function is quite broad and for it to be valuable, not just a drag on people’s time, it needs to understand both business and IT, and be engaged with both through the demand process.
Want to know more? Get in touch!