Demand management – risks and mitigations
The right Demand Management process is essential to collect, analyze, synthesize, and prioritize the IT demands appropriately. If it fails, the organizations will waste money and resources on initiatives that produce less value. At the same time, they miss opportunities to implement initiatives that would be much more needed. It would result in not only financial but also time losses. The competition will, for sure proceed faster, and a delay can be fatal for the company.
The IT capabilities are not only necessary preconditions of the business operations, but they form the core of the business. In many industries, the IT capabilities are the primary decisive factor of business capabilities. As this is the case, the success of the organizations is highly dependent on the implemented IT applications and services.
Large organizations have complex IT architecture, competing departments, not always clear strategy and internal politics. In these organizations, Demand Management may fail for several reasons. This article includes some of the high risks and hints on how to mitigate them.
1. Business „will“ instead of business „need“
Whenever a colleague raises a demand, it reflects her best understanding and professional opinion what IT should deliver. However, it is possible that this demand is not what the business really needs. It may be only a wish or will of that colleague or department, but not necessarily the optimal requirement for the entire organization. The reasons may vary from a silo mentality, through lack of general overview to personal ambitions to make a meaningful initiative.
The Demand Management process should have a validation step to assess if the demands reflect the real business needs. In some cases, it is a sensitive topic since the demand owner colleague might feel offended that she doesn’t know what to ask for. In other cases, the demand owners are cooperative and ready to discuss, but they miss the whole picture and have limited information and organizational insights. Besides, some colleagues and units raise demands to ensure their influence and position in the organization.
There are ways to turn business “will” to business “need” in a cooperative manner. The most important is to match the demands to the business and the IT strategies. Assuming that the strategies are valid, the organization needs what is described there. Besides, demand consolidation is also an excellent opportunity since the demand manager team can put the request in the organizational context and challenge the original version.
2. Fragmented, non-harmonized demands
During the process, the different divisions of the organization raise their demands. They focus on their specific needs. Examples are a request for a new regulatory report from the Compliance department to meet a legal requirement and a request from the Marketing department for a new report covering the same or very similar data sets. When the team puts together the initial demand list, there may be hundreds or thousands of items there. Some of them are well elaborated, while others not at all. For this reason, it is not apparent, which demands have significant functional, process, and other similarities and dependencies. In the example above, it is possible that the request of the Compliance and the Marketing departments highly overlap, and one harmonized demand can cover both.
While it is relatively easy to see in our example, what to do, it is more complicated in real life. The obstacles are the vast amount of the demands, lack of comprehensive understanding of the enterprise business architecture, and fragmented processing of the demands.
The organizations have to find ways to review all demand overlaps and dependencies and harmonize the demands whenever justified. One proven approach is to walk through all demands during a workshop. Sometimes it takes several days, but worth doing. The participants are the key participants in the demand management process: the demand managers, the business analysts, demand owners if needed, business architects, and also the PMO representative. These discussions help to increase the clarity a lot. In some cases, it is also interesting to see how many fundamental misunderstandings existed before the workshop.
3. Implementation specific details instead of required functions
Some colleagues, especially the tech-savvy ones, are tempted to define the demand in terms of implementation details, instead of the required functionality. For example, they may request a specific software package or a technical approach like Enterprise Service Bus or blockchain. Instead, they need to define the demand phase what functionality and service they need. Their demand could be like “I want a real-time connection between the mobile app and the credit scoring system so the customer can see immediately if we would grant the loan” or “build document storage for contracts that is available from many different channels, and the integrity is guaranteed.” The architectural, implementation, and technical details would follow later on if the organization decided to proceed with this demand.
The Demand Management team should assess the requirements and remove the implementation specific details. Even more important, they should clarify what functionalities are necessary and why. In some cases, it becomes clear that the demand doesn’t serve a real business need – it instead follows a hype or a trend. It is essential to clarify and formulate the required functionality and remove unnecessary implementation details before the demand consolidation. Otherwise, the chance to find synergies will be lower.
4. Non-optimal organization level prioritization
While many organizations make good progress to become more agile and flat, the traditional hierarchical structures still result in non-optimized and fragmented demand management processes. For example, the different sales and marketing departments may formulate their demands first. Afterward, there is a consolidation on the level of the Chief Sales and Marketing Officer. As a next step, this prioritized demand list of CSMO is merged with the list of other areas like CFO, COO, and others to get the company level priorities. If the merging is a mechanical process, e.g., the organization level top priority demands are top priority demands from each area, then come the medium and the lower priority demands, the outcome is very likely, not optimal.
The goal of the Demand Management process is to figure out, which are the most beneficial demands for the entire organization. It is not the same as to run a process that tries to treat everyone equal and give every department something meaningful. While it might seem a fair approach, it doesn’t serve the needs of the organization. As an example, it is possible that the COO projects are the most relevant for the organization, given almost nothing to other areas like the CFO.
Demand evaluation and prioritization rules and procedures should be clear and documented at the beginning of the process. The most important factors are the strategic fit, legal and regulatory compliance, and payback based on a committed business case. The demand management team should analyze all demands, clarify them as described above, evaluate, and assign the priorities. If these priorities differ from the preferences of the demand owners, they should review and find the reasons. It is essential not to compromise the organization level principles and prioritization drivers.
A closing remark
Make Demand Management a dynamic process and cooperation framework. Review the demands during the year as well, since there may be essential changes in the external and internal environments. It should be part of the regular meetings between the business and IT department. Learn more about the topics to discuss during the business–IT alignments. Also, assess the Demand Management process at least annually, get feedback from other departments, and adjust if needed.