NOTES BASED ON ACTUAL EXPERIENCE OF DEMAND MANAGEMENT, AWAY FROM AN ACADEMIC VIEW OF THIS
Although not formally defined in any IT methodology, I understand a “system of hurdles” to be equipping ourselves with a diverse set of difficulties that are applied to our users/clients. Either when they ask us for projects, request changes to systems, or when they want us to resolve incidents and existing problems in the technological solutions we provide.
These difficulties can be of different types: non-existent methodologies, poorly documented or unpublished procedures, unknown circuits, communications tools with no feedback to the requester (whether emails or other types of tools that conceal the requester’s identity), unfamiliarity with prioritisation mechanisms, systems with no predetermined service quality criteria, etc. This amounts to a black box approach to operations with probably very poor results.
And there are bound to be examples where this system of hurdles avoided doing that job that was no longer necessary and where the company saved a lot of money. But we also have to look elsewhere, where possible, for information on those projects not implemented within IT that could have generated significant revenue. Some would have had strategic value, value that was lost by coming late, or simply never making it, to the market.
Despite the consensus view opposing hurdles, in our organisations we sometimes have demand mechanisms with our internal and external clients that seem to be designed to make them give up using them. As I have already stated in certain previous posts, a system that purely manages requests cannot be considered a solution either. Doing something or not doing something must be in response to a criterion.
And when we are in the realm of incidents and problems, the system of hurdles is even worse. The hurdles prevent the issues from reaching those who can resolve them or those who can provide an alternative. We need to break away from that somewhat paranoid culture in which some people think that our users/clients send us problems just to annoy us and not because they actually exist.
Systems of hurdles also go against the fundamental idea of IT being a service unit. I cannot remember whether I read or someone once told me this idea about IT service that has been fundamental to me ever since. When we have an incident, request or problem, we have not one but two of them: the demand that they are informing us about, and the client creating that demand and who is affected. Even without providing a solution to the problem, a large part of the issue can be resolved by looking after the client, providing them with information, a resolution plan or temporary alternatives to avoid the problem. With a mechanism of hurdles, we will be able to resolve the incident in due course, but we will have lost the client’s perception of quality that we would have with a good demand system.
"We need to break away from that somewhat paranoid culture in which some people think that our users/clients send us problems just to annoy us and not because they actually exist."
Another idea to consider is that demand management always exists, whether it is known about and documented, or hidden and only available to the smartest of people. And I believe that this latter “smart people” scenario is devastating to service. “Smart people”, or “demand management at the analyst or support technician’s desk”, will mean that they neither do what is required, nor when it is required, with an unknown cost and non-existent revenue forecast.
Based on what I have said above, I hope that we all agree with the statement made in the title of this post. A system of hurdles will be valid for those few who operate with more resources than they need and who have a certain indifference to optimising demand management and project management.
How can we progress from this system of hurdles to effective demand management?
- Review the methodology if it exists. If it does not exist, adapt some of the existing methodologies. They are not complex, but they must include all demand, insist on transparency and involve all those affected.
- Create an implementation plan that includes all steps, and execute it. Have the methodology approved by management. And publish the methodology. Train everyone involved: requesters, managers and those responsible for implementation.
- Provide appropriate tools: standardised, that consolidate all IT demand, with defined functionality and management components, etc. Do not insist on modifying existing tools. This might be a good time to redefine your tools and opt for some of the good ones on the market. Tools aligned with current requirements, with future requirements and that are easy to customise. And simple to use.
- If possible, carry out pilot studies on the methodology and tools, and review the methodology and tools cycle until you have a valid and effective service for all those involved.
- Because we are ready for this change in IT, we should also always remember to consider the entire organisation. The next step, after the success in IT, is likely to be planning to extend it to the rest of the organisation.
At Xeridia, we can suggest developments to your methodologies from different starting points. Even if you are starting from a system similar to a system of hurdles. Progress will be a little more complex, but it will be more successful because there are more options.
As an Atlassian Gold Solution Partner, we can provide you with options to manage IT demand, suggest ways to extend demand management across the company, with easy-to-use tools that target current and future requirements.
Avelino Carrizo is Head of Financial Services Consulting at Xeridia
