NOTES BASED ON ACTUAL EXPERIENCE OF DEMAND MANAGEMENT, AWAY FROM AN ACADEMIC VIEW OF THIS
When I ask my colleagues in the sector what they understand by IT demand management, I end up with some very different answers:
- A methodology for managing limited and valuable IT resources.
- Part of capacity management that needs to be taken into consideration.
- A system for managing requests received by IT from the business.
- The tool that the IT team provides for us to log incidents.
- The application in which all management information for projects and requests is recorded.
In my opinion, these answers – and several others – are all correct. Historically, demand has been managed in different ways (sometimes manually, but mostly using solutions) and with a wide variety of tools, which is why the approach to IT Demand Management (and its implementation) is so varied.
“Historically demand has been managed in different ways and with a wide variety of tools, which is why the approach to IT Demand Management (and its implementation) is so varied”
Although the scenario detailed below may seem highly simplified, it is close to what happens in the real world:
- Support teams are likely to have an ITIL-based solution to handle all hardware and core software maintenance requests. As well as handling their own incidents and requests, an inventory system to facilitate management tasks will be built in to the solution. It will also be used by first and second-level Service Desks and will have some kind of two-way integration with external providers, either using email, file sharing or some other more elaborate system.
- There is likely to be another procedure or tool to resolve application functionality problems, in some cases used by support teams and in others by development teams.
- We can assume that the system for managing evolutionary and regulatory developments is different, although in some cases it will be the same as the corrective maintenance system above.
- It is quite possible that there is a different procedure for major projects. And if these are technology-based (systems, communications, databases, etc.), we are likely to encounter criteria and procedures specific to them.
- Finally, in addition to the type of demand, there may also be variations depending on the channel from which the demand is arriving: Service Desks, telephone banking teams, point-of-sale call centres, physical branches, head office departments, email, etc.
These assumptions, which are very close to how Demand Management is performed today, may result in problems of a different nature. For example:
- Applying different methodologies, procedures, KPIs, or using different ways to calculate these KPIs, to services that are essentially the same.
- A partial view of IT demand. Remember that demand is everything.
- The costs of tools and implementation services, as well as the ongoing maintenance costs.
- The IT team’s lack of flexibility, which is a major problem. For example, if application support needs to expand, perhaps we could do so at the expense of the distributed hardware support team. However, we will have to reinstall tools and prepare an instruction or training programme on those tools.
While the current situation gradually evolved over many years, this, in my view, has to start to change. Today, there are solutions available that address all IT demand, which can accommodate different demand methodologies, based on which the particular requirements of each service can be implemented, which can define quality parameters for any part of the data, and which have almost no learning curve, either for IT or its clients/users.
And these solutions can be implemented gradually, by functional area of demand as well as to a level of depth that is required in each case. With generalist hardware, limited core software costs and shared tools for all teams that form part of the IT infrastructure, both internal and external.
We can clearly demonstrate that one solution for all IT demand is appropriate. However, if we agree with this last statement, I think that we also have the answer to the question in the heading. There is also mixed demand out the IT departments, there is also a need to manage that demand between the different parts of the organisation, there will be specific cases, flexibility when relocating people within or between facilities will be just as important, etc. This is a well-known everyday occurrence, and one that we have clearly seen during the merger and acquisition processes of recent years.
Therefore, our action plan should include going through the necessary consolidation of IT demand management tools. And should also include having a plan to extend that consolidation to the rest of the company. Starting with those business units (Facilities, Operations, General Services, etc.) that have been working closely with IT and that have experience in managing this type of service.
At Xeridia, as an Atlassian Gold Solution Partner, we have been doing this kind of integration for years, for clients from various sectors, using Influunt, our demand management solution (based on Atlassian’s Jira, Jira Service Management, Confluence and Slack products), which can manage all IT demand and can be extended to manage demand across the entire organisation. All the information you need can be found by clicking on this link.
Avelino Carrizo is Head of Financial Services Consulting at Xeridia
