Rethinking Demand and Portfolio Management: From Overload to Integration, Responsibility and Execution

Executive Summary

IT organizations are drowning in demands they cannot execute. Limited capacity, unclear responsibilities, and the absence of strategic context trap IT in a reactive cycle. This report argues that flowing demand and portfolio management requires strategic awareness, integrated management, and clearly distributed responsibility.

Key Findings

• The origin of a demand matters. Demands driven by external factors such as regulation or competitive trends carry different strategic weight than internally generated ones and should be evaluated accordingly.
• Demands can be classified as fact-, fear-, or faith-based. Understanding which driver dominates helps organizations allocate scarce IT resources deliberately and maintain a balance across defensive, data-driven, and visionary initiatives.
• Demand and portfolio management must be integrated with enterprise architecture, capacity, and financial management to produce decisions that are strategically aligned and operationally feasible.
• Organizational structure determines who can decide on what. Whether IT is centralized, federated, or decentralized directly shapes decision-making authority and must be understood before responsibilities are assigned.
• Overinvestment in demand evaluation is a common and costly trap. Time spent assessing demands that cannot be executed consumes capacity that should go toward delivery.

Recommended Actions for CIOs

• Identify the external and internal origins of incoming demands to sharpen evaluation criteria and reduce unnecessary volume
• Apply the fact-fear-faith classification to surface hidden biases in how priorities are currently set
• Audit whether demand management is genuinely integrated with financial, capacity, and architecture management or running in parallel
• Match decision-making responsibilities explicitly to demand size and organizational structure, and communicate those boundaries clearly to business
• Set a deliberate limit on evaluation effort relative to execution capacity to protect delivery throughput

The more digitalized and more complex our world becomes, the more demands arise from the business. Indeed, not every wish or requirement from the business is a demand and needs to be managed. Neglecting this differentiation almost immediately brings the IT in a floated situation, where IT can only behave in a reactive way. The pressure on IT to qualify and evaluate demands right is further increased by limited IT capacities and set deadlines from business. Demand qualification and evaluation is becoming more difficult for the IT, if the provided information by the business is insufficient. IT and business often believe that with the right demand and portfolio management processes, all incoming demands can be processed properly and resource-efficiently. Unfortunately, a truly flowing demand and portfolio management is much more than a smoothly running process. It requires an understanding of the context in which the demands arise, an integrated demand and portfolio management setup and clear responsibilities in business and IT for demands’ qualification, evaluation and execution.

In our daily work, we see that CIOs and IT employees are handling too many demands without having the matching capacity. This is accompanied by a perceived loss of control over the inflow of demands and information on their delivery. To reduce the huge number of demands to a manageable level, evaluation criteria are typically employed to filter the incoming demands. This includes evaluating demands that could never be executed due to limited available IT capacities. The time spent evaluating these demands is just additional overhead for the IT and ties up capacities that could not be used for value-generating tasks. To alleviate feelings of being overwhelmed and to help IT escape the trap of being reactive, we propose taking a more strategic view on demand and portfolio management. This will broaden IT’s perception and enable a mutual understanding between business and IT.

From a strategic viewpoint, it is crucial for business and IT to understand which external factors, trends or developments in the company’s environment trigger demands. In Chapter 1 we take a broader view of the IT and business organization to highlight the importance of knowing the external context of demand origination. Not all external events or circumstances inevitably lead to new demands. Rather, this is an active decision about strategic positioning in the market, determining which external triggers and changes the company wants to respond to (cf. Chapter 2). With this active perception and decision, the company can act more quickly and proactively explore business advantages over competitors. Moreover, it is also important to consider internal dependencies (e.g., effects on the portfolio) and boundaries (e.g., budget and capacity restrictions) that are intertwined with managing demands. Chapter 3 evaluates dependencies and boundaries arising from the conjunction of demand and portfolio management with other management areas. Communicating this knowledge allows business and IT to better align on where to act next. Taking the insights from the previous chapters into account, we propose a set of factors within business and IT that have interdependencies and determine the IT’s organization (cf. Chapter 4.1). The centrality of process responsibility (centralized, federated, or decentralized) is the major factor that defines how responsibilities are defined and scoped so that IT can act proactively within its boundaries. This shapes the organization’s type and geographical structure (cf. Chapter 4.2). Based on the organization’s structure, collaboration between business and IT works differently. We thus focus on the most common collaboration models in chapter 4.3. Finally, we outline how to achieve real, flowing demand and portfolio management built on mutual understanding between business and IT, as well as clear responsibilities (cf. Chapter 5).

Chapter 1

1 Demand and Portfolio Management is Part of a Bigger Picture: Holistic Organization Management

“IT demand management (…) is an approach to holistically manage IT demands which relate to changes of business processes” (Novak et al., 2023). IT demands always indicate a change, differentiating them from repetitive inquiries, for which there is a standard process. This means that IT demands must be handled differently from the standard process for repetitive inquiries. It is important to note that not all changes can or should be implemented. Accordingly, a decision must be made as to whether the demands are worth pursuing and should be added to the execution portfolio. Thus, demand and portfolio management is a process or a capability that filters the incoming demands.

Before getting caught in the details of defining a demand and portfolio management process, first, adopt a holistic perspective to develop a comprehensive understanding. Zooming out and identifying where change needs emerge, provides a different perspective. An IT or business organization does not act in isolation from its immediate environment (e.g., industry/market, customers, competitors). Instead, it is influenced by the broader external surrounding. The entities influence each other and have an impact on what demands emerge within the organization and within IT. Proven models, such as the STEEP and PESTEL model, exist to define the wider corporate environment and its influence on the company (see Figure 1 outer layer).

The STEEP model is a strategic planning tool. It is an acronym and refers to social, technological, economical, ecological as well as political influencing factors (Nurmi and Niemelä, 2018). Each of these dimensions can have an impact on a company and therefore on its business processes:

1. Social - Example: Change in user expectations for digital experiences
2. Technological - Example: Tech trends, e.g., AI
3. Economical - Example: Economic purchasing power impacting IT budgeting and procurement
4. Ecological - Example: Demand for green IT and sustainable data centers, evaluating the ecological footprint of demands
5. Political & Legal - Example: GDPR, ISO guideline as a must to enter a market

Recognizing that organizations are embedded in a multi-layered environment means acknowledging that demands are shaped by the interactions between the organization and its environment. Following this logic, external factors influence business strategy. As digitalization is accelerating, business processes become increasingly digitalized and the number of IT demands rises. In summary, the environment can be seen as a catalyst for the velocity of demand perception, because it is not only shaped by business needs but also by technological opportunities and legal requirements. This leads us to the following hypothesis:

Figure 1: Demand and portfolio management as part of a bigger picture (Own illustration, adapted from Weissenberger-Eibl et al. (2019))

Hypothesis 1a: The environment influences the upcoming amount and kind of demands.

Simply accepting that the environment influences upcoming demands is not enough. Demand origination must be understood because external origins provide different indications about the strategic relevance and urgency of demand execution compared to internal origins. For example, following the market trend (external origin) might be more relevant than optimization of existing old technology (internal origin). Clearly, not all changes are feasible or beneficial for the organization, so demands must be filtered and evaluated properly. This leads us to our second hypothesis:

Hypothesis 1b: A better understanding of the origins of demands makes it easier to evaluate the demand and decide on the following (in)actions.

In conclusion, it is important for IT organizations to abandon traditional paths and processes and be aware of developments and changes in the broader environment. It is essential to recognize that IT organizations do not function independently of their environment. There are thus also boundaries. For example, IT does not have the power to reorganize business units within the overall corporate structure to better align with IT’s internal organization. A clear understanding of demand origination is essential when implementing a better, more flowing demand and portfolio management.

Chapter 2

2 Strategic Positioning in the Market: Fear, Fact, Faith

Demands for change imposed by the environment can be amplified further by e.g., competitors who have already adopted tech trends or by customers who request the latest technology (market-pull). This contrasts with new technology that is ready for the market and requires the company to develop a new business field or market for it (technology-push).

Both the market-pull and technology-push mechanisms can have a significant impact on the (re)development of strategies and, therefore, can intensify the urgency for change, compelling organizations to respond. Since not all demands are treated equally, companies often classify demands based on their perceived nature. Therefore, the classification of demands in fear-, fact-, or faith-based can be very helpful (adapted from Aron et al., 2018):

Hypothesis 2a: Demands can be classified as being fear-, fact-, faith-based.

In the following we give examples of fear-, fact- and faith-based demands:

• Fear-based demands: Failure to execute initiatives in this category can pose serious threats to an organization’s survival. Cybersecurity efforts typically fall into this category because they are essential for protecting critical systems and data. Other examples include GDPR investments or technical debt.
• Fact-based demands: Fact-based demands are requirements based on clear figures and verifiable facts. The aim is to achieve measurable improvements, such as lower costs, higher sales, and more satisfied customers. The benefits of such demands can usually be accurately assessed because tried-and-tested methods and data are available. They differ from requirements based more on belief or fear.
• Faith-based demands: Faith-based demands are requirements in which a company chooses to act without exact prediction what the benefits will be. The potential value is more of an assumption than a concrete figure. Such projects are based on strategic trust and should be implemented in small steps, with regular decisions on whether to continue. Having too many or too few of these demands can be risky for a company - so striking a balance is important.

Figure 2: Positioning in the market (Own illustration, adapted from Weissenberger-Eibl et al. (2019))

This classification supports the decision of which influence factors to follow and which not, depending on the weights the management puts on these factors. For example, a management that decides to follow their faith will probably allocate fewer resources to security topics than a management that bases its decisions on avoiding fear. Clarity about aligning actions (e.g., demand execution) with strategic orientation ensures that IT’s scarce resources are allocated to initiatives that reflect the organization’s core values and risk appetite. By identifying the underlying driver, companies can filter out noise and focus on what truly matters—whether it’s mitigating a threat, seizing a proven opportunity, or exploring a visionary path. Overreliance on one type of demand (e.g., only fear-based) can lead to stagnation or missed opportunities. Awareness of the dominant forces allows companies to maintain a healthy mix of defensive, data-driven, and visionary initiatives. This brings us to our next hypothesis:

Hypothesis 2b: A better understanding of the dominant (managerial) driving factors (fear, fact, faith) makes it easier to evaluate the demand and decide on the following (in)actions.

Certainly, some demands cannot be clearly assigned to one single category, because they contain elements of fear-, fact- and faith-based demands. For example, an infrastructure project may be launched due to concerns about outdated systems (fear) and the potential for concrete improvements through new functions (fact). Nevertheless, assigning the demand to a main category is helpful. This facilitates a clear and approximately correct decision and enables action faster than with an unclear but theoretically accurate one. If a demand equally covers two areas, it may make sense to split it into two separate demands.

Chapter 3

3 Beyond a Single Process within the Company: The Integrative Role of Demand and Portfolio Management

In addition to the external factors’ influence, there is a dynamic relationship between portfolio management and demand management. Demand management captures, prioritizes, and steers requirements, while portfolio management uses this input to shape the composition and strategic alignment of the project portfolio. It also establishes criteria for accepting new demands and defines prioritization. Effective collaboration between these disciplines is crucial for aligning strategic goals with operational capabilities and ensuring optimal resource utilization (Meskendahl, 2010).

Additionally, demand and portfolio management is influenced by various management areas within an organization. To practice holistic IT management, these areas should be considered together rather than in isolation. The following focuses on the interaction between demand and portfolio management and the individual areas.

Enterprise architecture management (EAM) establishes a fundamental basis. It creates the structural conditions necessary for systematically capturing, analyzing, and implementing demands. At the same time, new demands may necessitate architectural changes. For example, new technologies or business models may require adjustments to the IT landscape. This illustrates the bidirectional nature of the relationship. While architecture enables demand implementation, demands can also drive architectural evolution or reveal structural constraints. Therefore, an integrated approach to demand and portfolio management must consider both the enabling and limiting roles of EAM (Würtz, M. O., & Sandkuhl, K., 2023).

Capacity and resource management are closely linked to demand and portfolio management because the volume and nature of incoming requirements directly impact resource planning and allocation. Conversely, available capacity determines what can be implemented within a given timeframe. For instance, mergers and acquisitions tie up resources that cannot be used elsewhere. Therefore, less capacity supply thus leads to less capacity availability for other demands. Close coordination between these two areas is essential to avoid bottlenecks and ensure realistic planning (Meskendahl, 2010). Thus, effective demand and portfolio management depends on effective resource management.

Financial management is closely linked to this, because it sets the economic boundaries for demand implementation. Budget availability, cost forecasts and investment planning influence which demands can be pursued. Moreover, demand forecasts help financial planners to allocate resources more effectively. This mutual dependency requires continuous coordination to ensure that financial resources are used efficiently and that demand decisions are economically viable.

Taking a closer look at how enterprise architecture management, capacity and resource management, financial management and portfolio management are integrated with demand management, we can identify four different layers (see Figure 3).

Together, the strategic initiatives and operational service areas consume around 75 percent of the organization’s available capacity. Continuous improvement (CI) covers around 20 percent and focuses on smaller, often decentralized enhancements initiated by operational teams. At the tactical level, portfolio-level initiatives use typically around 5 percent of capacity to translate additional, rationally justified, and affordable strategic goals into executable, cross-functional projects. Such a structured demand and portfolio management process is essential to ensure that activities align with the organization’s overall direction and remain within capacity limits. Only with the integrated understanding of the interactions between the various management areas effective corporate management will be possible (McKeen 2012). The following hypothesis can now be derived:

Figure 3: Capacities need to be split between strategic transformation programs, demands and services (Own illustration)

Hypothesis 3a: Effective demand and portfolio management needs an integrated set-up with the other management areas in the organization as enterprise architecture management, capacity and resource management, and portfolio and financial management.

In this context, it is crucial to understand the perspectives of both the business and IT. Effective collaboration can only take place when both sides share a common understanding. IT leaders, in particular, benefit from understanding the business context because it enables them to align technological decisions with overarching business goals and contribute more effectively to value creation (Struckman et al., 2024). When the CIO knows the C-level’s objectives in areas such as strategy execution, finance and human resources, they can propose IT solutions for business-perceived frictions or gaps within IT. Consequently, the demand can be proactively steered. When the value of the proposed IT solution is obvious to the business, the necessary funding and resources for IT follow automatically. This leads to our next hypothesis:

Hypothesis 3b: A better understanding of the business needs and dependencies and IT’s limitations makes it easier to evaluate the demand and decide on the following (in)actions.

Consequently, demand and portfolio management is much more than just a single process; it acts as a connector across all central management areas for a functioning IT organization. With an integrated demand and portfolio management setup, the IT organization can process and work on demands that are strategically aligned, operationally feasible, financially sustainable within budgetary and financial constraints, and technically supported by or supporting the enterprise architecture.

Chapter 4

4 Responsibility as the Cornerstone of Effective Demand and Portfolio Management

If funding and resources do not equal the requirements for the chosen demands, the determination of what to execute remains only challenging in the absence of clarity regarding the decision-maker. This aspect will be explained further in the subsequent sections.

Effective demand and portfolio management requires clearly defined responsibilities (see Figure 4). It must be ensured that decision-makers have the necessary experience and contextual understanding to evaluate demands within the broader business landscape. Assigning these responsibilities to inexperienced individuals (e.g., someone who is new to their current position in the company) or who are constrained by the micromanagement of an autocratic leader undermines decentralized decision-making and organizational effectiveness.

Figure 4: At the core: Responsibilities (Own illustration)

4.1 Structural Factors Impact Responsibilities

The ability to take responsibility also depends on the company’s structure, its locations and business domains, profit and loss responsibilities, and other structural factors. These set the boundaries of the area of responsibility and the possibility to make decisions. Below, we briefly summarize these factors and take a closer look at their interdependencies:

The structural factors influence each other and the structure of IT organizations. The industry significantly impacts IT due to regulatory requirements, such as documentation obligations, e.g., in the pharmaceuticals and health industry. The existing IT strategy and the size of the IT determine the operating model and thus how IT and business collaborate. Furthermore, the dominant leadership style influences whether decisions can be made centrally or locally. An authoritarian style favors centralized decision-making, while a democratic style tends to lead to decentralized responsibilities. This leadership style directly impacts the centrality of process responsibility, the organizational type (functional vs. divisional) and the geographical orientation of the business. These parameters, in turn, determine the actual scope of action. In other words, they determine the extent to which local or technical managers can make autonomous decisions. A local manager without a budget, assigned personnel, or autonomy cannot make independent decisions about demands. The following hypothesis sums up this dependency:

Hypothesis 4a: The organizational business and IT structure determines the area of responsibility for each individual, ensuring they have the authority to make decisions on the demands.

4.2 Centrality of Process Responsibility Determines Responsibilities

In this subchapter, we examine three core factors and their effects on a decision maker’s area of responsibility. These core factors are 1. centrality of the process responsibility combined with 2. type of organization, and 3. business geographics.

The structures of the different degrees of centrality of process responsibility determine who can decide on demands in which area of responsibility, which naturally comes with limitations (see Figure 5). The following paragraphs explain the characteristics of a centralized, federated, decentralized IT organization to support our hypothesis:

Hypothesis 4b: A better understanding and transparency of the area of responsibility and its limitations makes it easier to assess who evaluates which demand and decides on the following (in)actions.

In a centralized organization, there is a single, overarching IT structure that spans all business units. Within this structure, designated business domain responsibles (we call it category responsibles) for larger demands, and continuous improvement (CI) responsibles for smaller demands. They are accountable for evaluating and deciding on IT demands for their business domain. Strategic and cross-functional topics are discussed in a central committee called the IT council. This council usually includes the category responsibles from both IT and business, the CIO, and, if necessary, members of the board of directors or managing directors. This setup ensures consistency and alignment with the overall IT strategy, though it limits the autonomy of individual business units to make independent IT decisions.

In a federated organization, some functions are managed centrally, while others are managed locally. Category and CI responsibles oversee their area across business units for centrally managed functions, while different category and CI responsibles oversee their functions within their own business unit for decentralized functions. To align on overarching topics, one common IT council is used. This approach combines centralized control with local autonomy and adaptation possibilities.

In a decentralized organization, each business unit maintains its own IT structure, including its own category responsibles and CI responsibles. These roles are empowered to make decisions about IT demands specific to their respective business unit.

Figure 5: Organizational structures and their effects on areas of responsibility (Own illustration)

Each business unit also has its own IT council, where cross-departmental topics within the unit are discussed and decided. While this allows for greater flexibility and responsiveness to business unit needs, it may lead to inconsistencies across the organization if not well-coordinated.

The following example shows the divided responsibility for different continuous improvements by business units (e.g., for cars versus trucks for an automobile manufacturer), in addition to business domains (see Table 2). The simplified example below would result in the responsibles for 1. IT & OT cars, 2. IT & OT trucks, 3. FICO cars, 4. FICO trucks.

Complexity and possibilities for areas of responsibility increase when adding a geographical structure to the factors of centrality of process responsibility and type of organization. For example, we examine business unit 1 of the decentralized organization and illustrate a federated business geography (see Figure 6). Federation is illustrated via three possibilities: A global process (1), local differentiation (2), and a partly harmonized process with a pending global rollout (3). In this example, the logistics and production business domains are organized globally. This means that one category responsible and one CI responsible can each decide on the demands within the field of logistics and production on a global level.

A second possibility is shown within the IT and finance business domain. Currently, one category responsible and one CI responsible each can decide on the European processes, but not on American ones. However, in the future, the American processes will be harmonized with the European ones. Similarly to the logistics and production business domains, the IT and finance demands will then be managed by one global category responsible and one CI responsible each. In the HR, sales, and legal business domain, however, one needs to define different category and CI responsibilities for each location because they make decisions separately. How to organize is a business decision: The choice is between an efficient, cost-effective global process that is the same everywhere and the ability to adapt to changing conditions.

Figure 6: The influence of federated company and process structures (Own illustration)

After explaining the dependencies and boundaries for areas of responsibility, in the following we summarize how to establish a flowing demand and portfolio management with clear responsibilities. Since this depends on the collaboration model between business and IT, we first describe the different models.

4.3 Models of Collaboration

Based on Gartner’s IT Operating Model (ITOM), we derived our own models for an effective collaboration between business and IT in demand and portfolio management. In the next paragraphs the different models of collaboration are introduced.

Gartner states „an IT operating model represents how an organization orchestrates its IT capabilities to achieve its business strategic objectives.” According to Gartner, “an IT operating model has nine key, highly interdependent components (performance, decision rights, financials, organizational structure, sourcing and ecosystems, talent, workplaces, tools and platforms, delivery model)” (Gartner, 2024). For IT operating models Gartner “has identified five IT operating model patterns – asset-optimizing, process optimizing, service-optimizing, value-optimizing and invention optimizing.” (ibid.).

As we noted in our report “Enhancing IT-Business Collaboration-Insights from CIOs Industry Experience and Academic Research” it is important to acknowledge that not all areas of an IT organization must work according to the same operating model. Instead, the capabilities of the respective area (e.g., enterprise IT) must align with the operating model. This includes clear responsibilities, appropriate financing models and established working methods. Practical experience shows that enterprise ITs generally work with a process- or service-optimizing operating model. Product IT usually operates based on a value-optimizing operating model, as this area of IT is generally more focused on responsibilities in business, dedicated budgets and finance management in general.

In the following, we describe the different operating models in the context of demand and portfolio management (see Figure 7). The asset-optimizing operating model is less relevant when demands arise ad hoc and are resolved informally (Hey-Joe-principle), instead of following a structured and defined process with process responsibilities. In such an operating model the target architecture is usually not defined, and the system landscape is not (yet) considered in portfolio decisions. In the value-optimizing operating model, the demands often arise within multidisciplinary teams and the teams themselves can decide which demands to implement. This is possible due to daily collaboration and transparent communication within the teams, e.g., using product boards. In these setups, there is little need for defined demand and portfolio processes and roles but a well-functioning alignment between IT and business is crucial. Therefore, we will not discuss these operating model patterns in more detail. We will focus on the process- and service-optimizing IT operating models in the following and describe their defining factors in the context of demand and portfolio management.

Figure 7: Collaboration Models between IT and Business (Own illustration)

An IT that focuses on process-optimization (Process) behaves in a workflow-based, reactive manner when it comes to demand and portfolio management. Demands from the business are recorded via a structured demand and portfolio management process. False demands that are actually tickets or standard change requests are routed to the respective ITSM tool. Right demands are classified as project candidates for larger business requirements and handled via the demand and portfolio management process.

Although a standardized process with dedicated gates is in place, the IT usually receives a high number of redundant demands due to a lack of clear responsibilities in business. Especially in global organizations, similar demands may be submitted multiple times by different regions, if responsibilities in business are not defined clearly. Challenges also arise during demand evaluation from isolated solution designs that are not aligned with the target architecture. Typically, process-optimizing IT organizations just begin working on their enterprise architecture, starting with documenting the current enterprise architecture, but not yet defining or working toward a target architecture (see Figure 8).

Figure 8: EAM Relevance in process- or service-optimizing collaboration pattern (Own illustration)

In accordance with the organizational structure, which is aligned along cost centers and areas of responsibility, bigger demands (project candidates) are included in IT portfolio discussions. The project portfolio is further specified in the annual planning. The zero-based budgeting approach can be helpful here. Rather than allocating a fixed budget at the beginning of the year, a rolling planning process is established, requiring each expenditure to be justified anew. This enables flexible and needs-based financial planning but requires a high degree of transparency and coordination.

The responsibility to prioritize the demands differs based on the potential demand size. For smaller demands it is the IT’s responsibility and for larger demands the business is responsible. Finally, prioritized demands and approved projects are handed over to the relevant departments or teams for implementation.

The IT focusing on delivering services (Service) increasingly bases portfolio decisions on strategic alignment and the EA target architecture (see Figure 8). Individual business cases are often insufficient. Instead, greater attention is paid to strategic benefits. The project portfolio management considers project candidates and more smaller demands.

The demand and portfolio management processes are backlog-based and have clear responsibilities. The business is responsible for the process, and IT is responsible for the delivery. IT and the business collaborate through regular committees. Global process owners from the business make decisions on priorities and implementation. Only then real value-generating demand and portfolio management can be implemented. As responsibility increases, stakeholders can and must be more proactive, actively proposing, prioritizing, and deciding on demands. As the transparency increases with a demand board as one single source of truth and regular committee meetings, the redundancy of requirements decreases significantly. Interdisciplinary work takes place within IT. Initial team-based financing approaches are emerging. Teams receive block funding for smaller demands (continuous improvements). However, there are no agile teams yet. Run operations are organized separately.

Chapter 5

5 How to Set Up an Integrated Flowing Demand and Portfolio Management with Clear Responsibilities

Several prerequisites are necessary for setting up an integrated flowing demand and portfolio management. First, transparency on how much capacity is available for implementing requirements that are not already strategically set, or deemed necessary for stable operations is crucial (see also chapter 3). One approach achieving this transparency is rolling planning (see our whitepaper “Effective Resource and Financial Management via Rolling Planning”). This allows resources to be used on current and new demands effectively and avoids unnecessary effort.

Based on this, management should decide on how complex the demand and portfolio management should be, as well as how much effort can and should be invested. It is a strategic decision how much admin time will be allowed for the task of demand decision (and evaluation) compared to demand execution. Especially when capacity is limited, there is a tendency to strive for control to diminish insecurities. For example, imagine the PMO spends time on managing all demands and thoroughly weights them to have a solid basis for deciding on the right demand, but there is only little capacity to execute it. Instead, IT managers and CIOs should ask themselves, if a detailed demand assessment really provides the desired added value and if the time spent on assessment is justified. Relative to execution, smaller demands naturally require a larger proportion of time for prioritization. Up to a certain point, spending more time on prioritization may be useful, because it increases the likelihood of doing the right thing (not always though). After that point, one gets lost in the details. If too little time is spent, the probability for changes rises as the prioritization did not incorporate sufficient holistic thinking.

After deciding on the desired level of complexity for demand and portfolio management, distributing responsibilities depending on the demand size further reduces the effort and alignment needed.

Hypothesis 4c: Distributing responsibilities depending on demand size makes it easier and makes it more efficient to evaluate the demand and decide on the following (in)actions.

The second prerequisite for deciding on new demands is having clearly defined roles and associated responsibilities in business and IT. Both vary depending on the IT operating model. However, the tasks to be performed remain largely the same. They range from submitting a demand to transferring it to the implementation and considering it in portfolio management.

5.1 Roles

There are six central roles in the demand and portfolio management process:

1. The requester initiates the demand. Only key users or managers from business or IT should create a demand, as they are familiar with the relevant processes in this context. This reduces errors and additional work.
2. The role of the coordinator is optional. They have knowledge of both business structures and IT. They thus first decide about the qualification as a demand and if necessary, then refer the requester to a suitable contact person or expert on the topic. For example, a coordinator may hold the position of local process owner or local IT manager in an international company.
3. The category responsible has an overview of its area of expertise and the incoming demands. Thus, they make the initial decision on whether the demand is feasible and should be pursued. This decision is made before the demand is evaluated in more detail. In this process, they act as a gatekeeper. Furthermore, they must be kept informed about delays and the finalization when the demand is implemented.
4. The CI responsible is accountable for smaller demands. The responsibility for the continuous improvement comes with a set goal, budget and capacity. Therefore, the responsible takes action to achieve the objective instead to passively await external intervention. This responsible must understand their mission, including knowing whether they are deciding on a global or local process (see above). If a continuous improvement is exhausted, the IT council decides whether to make additional budget available, considers its impacts on other projects and continuous improvements and assesses possibilities for realization.
5. In accordance with the requestor’s specifications, the technical evaluation of the request is carried out by the subject matter expert. The necessary measures include the draft of a solution design, a cost and effort estimate, and an impact analysis on the enterprise architecture. This process ensures that the demand is appropriately quantified. Additional subject matter experts can be involved, if necessary, with one retaining primary responsible subject matter expert.
6. Strategic and cross-functional topics are discussed in the IT council, which consists of the category responsibles from both the IT and business sides, the CIO, and if necessary, members of the board of directors or managing directors.

5.2 Handling Demands

Depending on the collaboration model of business and IT, the individual roles collaborate differently for different demand sizes (see Figure 9).

5.2.1 Process

The requester submits a demand. The ‘Qualification, Filtering and Routing’ phase is optional. It is often handled by IT because there is usually no clearly defined role for pre-qualification within the business, especially for smaller demands. Since IT has an overview of incoming and executed demands, a coordinator from IT can filter out demands that have already been submitted several times or are redundant. The IT category responsible decides on moving the demand further to the evaluation phase. For small demands, the decision lies with the CI responsible from IT as there is no corresponding responsibility defined by the business. Subject matter experts evaluate the demand. For larger demands the category responsible from business decides based on a cost-value analysis. For smaller demands the decision is made by the CI responsible from IT.

Figure 9: Handling demands in the different collaboration models (Own illustration)

5.2.2 Service

First, the requestor submits the demand. During the ‘Qualification, Filtering and Routing’ stage, the demand’s subject area, such as a capability or product area, can usually be clearly assigned and there is one category responsible from the business managing this area. For example, HR-related requirements can be assigned directly to the HR responsible and the HR budget. Thus, the business is responsible for deciding whether a demand is fundamentally sensible. The category responsible is responsible for larger demands and the CI responsible for smaller ones. Pre-filtering by the specialist department reduces the IT department’s processing effort. When business decides to move the demand further, the demand’s technical evaluation is carried out by the subject matter expert. Whether to finally implement a demand depends on its size. Larger demands are decided by the business category responsible as part of portfolio management, while smaller requirements are approved jointly between the IT CI responsible, and the business CI responsible.

5.2.3 Process / Service

The ’Planning and Sequencing’ step is carried out in the same way in both collaboration models.

If the business category responsible deems a potential big project as valuable enough, they pass it on to the IT council. To avoid excessive administrational overhead in this process, the IT council makes a decision in an early phase based on essential project information (e.g., benefits, risks and size). If a potential project passes this round and acquires the status of a high likely implementation, then it will be pre-planned in more detail. Via planning as a pipeline, the projects’ effects on the roadmap and capacities can be evaluated. This process prevents unnecessary effort and avoids pseudo-capacity-conflicts, as projects that are unlikely to happen are neither pre-planned nor included in capacity planning. Highlighting the role of the IT council, the council does not only decide about potential projects but also reviews and checks on the current quarter. Knowing where conflicts arose is necessary to eradicate them and take advantage of opportunities that might arise. For the next quarter, the second IT council decision round determines the future of the pipelines: whether they will be canceled, continued as pipelines, or executed as projects. Moreover, the IT council looks ahead to the second next quarter to decide which demands should be pre-planned for a more detailed decision. Thus, the process of pre-evaluation, decision-making and adaptation process starts again. See Figure 10 for this process.

Figure 10: Timeline of portfolio layer demand management (Own illustration)

As a mechanism to ensure quick decision making for smaller demands, the IT CI responsible decides about the possibility to include a demand within the relevant continuous improvement.

In summary, a demand is considered ‘in scope’ when implementation has been deemed possible within the available budget, binding approval has been given, and the timeframe and capacities have been planned.

Early, clear, and distributed decision responsibility ensures that incoming demands and the outflow are always managed. This reduces effort and prevents a huge backlog of demands. This prevents the responsibles from becoming overwhelmed by too many demands (Pilat and Krastev n.d). Demands are either brought to execution, are cancelled or deferred. When a new, more important demand arises, determine which existing demands should be removed. One decisive quality that responsibles need for effective demand and portfolio management is the ability to focus on the core needs and decline other demands. This balances demand and supply, and an equilibrium can be found (see Figure 11). If demands still exceed supply, the price of supply increases as well, e.g., in the form of more overtime, or hiring more people, etc. If the demand is worthwhile, then the responsible or supervisors can decide for execution.

Figure 11: Demand-Supply-Equilibrium (Own illustration)

Chapter 6

6 Summary

IT demand and portfolio management is more than tackling the full demand list from businesses. It is being aware of and understanding the origination of demands, boundaries and dependencies within the organizational structures. Thus, a dialog with business is enabled, the possibility to actively set a strategic direction is given and effective decision-making by dedicated responsibles is possible. An effective demand and portfolio management is thus specifically characterized by these five key aspects.

Firstly, an understanding for the external influence factors and origination of demands is needed. Understanding whether a demand is driven externally (e.g., industry regulations or competitive trends) or internally (e.g., system optimization) helps determine its urgency and relevance.

Secondly, a clear view on the drivers for change (facts, fears, faiths) and an active decision on which to focus supports in evaluating the value of the demand. Maintaining a balance across these drivers prevents overreliance on any one type, such as excessive risk aversion or unwarranted optimism, and helps organizations allocate their limited IT resources effectively.

Thirdly, a demand and portfolio management only works when being integrated within the areas that influence it like finance, capacity, and enterprise architecture management. Only when all areas are considered and addressed together can they interlock smoothly. Demands consume organizational capacity across different levels. This means that strategic initiatives and operational services use the majority of the available capacity, while continuous improvement and tactical portfolio initiatives use less. Being aware of the limitations and integrating these levels ensures that resources are aligned with long-term goals and real-time needs.

Fourthly, a comprehensive understanding of business and IT structures is essential for recognizing the scope and limits of decision-making. Depending on whether the IT organization is centralized, decentralized, or federated, the scope of decision-making authority varies. Knowing about these boundaries helps in setting up the right responsibilities.

Fifthly, and most importantly, to overcome an overload, decide on the effort spent on prioritizing demands and implementing clear responsibilities for different responsibility areas and demand sizes. Over-investment in detailed evaluations can be wasteful, especially for minor initiatives, while under-evaluation risks poor decision-making. Follow the right collaboration model for your organization and organize demand and portfolio management accordingly. Ultimately, successful IT demand and portfolio management hinges on the ability to say “no” to non-critical demands and to maintain equilibrium between IT supply and business demand. The key is to ensure that all demands receive a decision, whether to proceed, defer, or reject the demand. This prevents backlogs and decision paralysis.

By applying these five aspects, organizations can ensure that IT demand and portfolio management serves as a bridge between strategic intent and technological execution. This enables a focused, and value-driven decision-making and thereby establishes the preconditions for subsequent execution.

About the Authors

Dr. Julia Schreier

Bee360

▼

Leveraging experience across different fields - from Industrial Engineering and Management to People, Julia's passion is enhancing knowledge and creating value by exploring and sharing innovative concepts and management insights. A key facet of her expertise involves effectively bridging the gap between academic insights and practical applications, particularly in addressing management topics and organizational challenges. This multifaceted background uniquely positions her to contribute valuable impetus to initiatives aimed at fostering comprehension, continuous growth, and progress.

Dr. Tamara Leuthe (geb. Huber)

Bee360

▼

With her extensive experience as an industrial engineer, Tamara looks at IT management challenges from both a technical and business perspective. As an innovation expert, she is aware of future developments. She has gained practical experience at the interface between science and business in numerous innovation and transformation projects, which has sharpened her understanding of the associated challenges. Her holistic view of companies and her drive to develop comprehensible solutions for complex challenges bring new ideas and aspects to the composition of the management of IT organizations.

Sönke (Sonny) Claussen

Bee360

▼

Sönke (Sonny) Claussen is Founder and CEO of Bee360, an enterprise platform for adaptive IT governance. Over two decades, he has worked with CIOs across industries to integrate strategy, architecture, financial management, and capacity planning into coherent operating models. His work is grounded in the conviction that technology organization is not a tools problem but a structural one: the decisions that determine whether transformation succeeds or fails happen at the level of governance, decision rights, and resource allocation. He holds a Master’s degree in Computer Science and is a participant in Harvard Business School’s Owner/President Management program. He relocated with his family to Boston in 2025 to build Bee360’s US presence.

References

Aron, D., & McMullen, L. (2018). Digital business needs advanced business case practices (Report No. G00362812). Gartner.

Gartner, CIOs’ Reference Guide to Designing IT Operating Models, By: Nielsen, T., Scott, D., Sinha, M., & Kopcho, J., 13 December 2024. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

McKeen, J., Smith, H. A., & Gonzalez, P. (2012). Managing IT demand. Journal of Information Technology Management, 23(2), 17–28.

Meskendahl, S. (2010). The influence of business strategy on project portfolio management and its success: A conceptual framework. International Journal of Project Management, 28(8), 807–817.

Munich Business School (2025). Leadership Styles. https://www.munich-business-school.de/en/l/business-studies-dictionary/leadership-styles

Novak, C., Pfahlsberger, L., Bala, S., Revoredo, K., & Mendling, J. (2023). Enhancing decision-making of IT demand management with process mining. Business Process Management Journal, 29(1), 230–259.

Nurmi, J., & Niemelä, M. S. (2018). PESTEL analysis of hacktivism campaign motivations. In M. Gruschka (Ed.), Secure IT systems (Vol. 11252, Lecture Notes in Computer Science), 323–335.

Pilat, D., & Krastev, S. (n.d). Why do we have a harder time choosing when we have more options? The Decision Lab. https://thedecisionlab.com/biases/choice-overload-bias

Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard business press.

Rychkova, I., Zdravkovic, J., & Speckert, T. (2013). Challenges of EA methodologies facing progressive decentralization in modern organizations. CEUR Workshop Proceedings.

Statista (2025). Branchenübersicht. https://de.statista.com/statistik/kategorien/

Struckman, C., Griffin, D., Santana, M., Banerjee, A., Smith, K., & Sanchez Reina, D. (2024). 2 actions for CIOs to become an outcome-driven leader (Gartner Report No. G00814947). Gartner.

Weissenberger-Eibl, M., Almeida, A., & Seus, F. (2019). A systems thinking approach to corporate strategy development. Systems, 7(1), 16.

Würtz, M. O., & Sandkuhl, K. (2023). Enterprise architecture for integration of demand-responsive services in public transport. Complex Systems Informatics and Modeling Quarterly, 2023(34), 62–83.