In IT governance, 'demand management' and 'supply management' are treated as two separate disciplines within demand-supply alignment. What does each one actually control, and what typically goes wrong when a company builds strong supply-side portfolio management but never builds a comparable demand-management process?

## Two control problems under one label Demand-supply alignment splits IT governance into two distinct control problems that are often conflated under the single label 'IT governance.' - **Demand management** governs the question 'what should we build, and in what order' — it is the intake process: business units submit requests (a new feature, a new system, a compliance-driven change), those requests get sized, scored against strategic criteria (value, risk, urgency, dependency on other work), and a governance body — commonly a portfolio or investment committee with both business and IT representation — decides what gets funded this cycle and what gets deferred or rejected. - **Supply management** governs the separate question 'given what's been approved, how do we actually deliver it' — it covers engineering capacity planning, team allocation, sourcing decisions (build in-house, buy, or outsource), vendor management, and the delivery mechanics (sprint cadence, release management, a PMO tracking status). The distinction matters because these two disciplines can each be independently mature or immature, and the combinations produce very different failure signatures. ## Why supply matures first The specific failure the question asks about — strong supply, weak demand — is common because supply-side maturity is easier to build and easier to demonstrate. A PMO with velocity dashboards, capacity utilization reports, and a well-run delivery machine is a visible, measurable achievement that IT leadership can point to. Demand management is harder: it requires business stakeholders to agree on a shared prioritization framework, to accept that their pet request might rank below someone else's, and to sit through a governance process that inherently produces some losers every cycle — organizationally painful in a way that improving delivery velocity is not. So it's common to find IT organizations that have invested heavily in delivery excellence while demand intake remains informal: whoever has the most political capital, the loudest executive sponsor, or simply got their request in first jumps the queue, regardless of actual business value. ## The mechanism of the failure — a very efficient bad backlog The mechanism of the resulting failure is that supply-side excellence has nothing to correct for a bad backlog — a highly efficient delivery organization will very efficiently ship whatever is in front of it, at high velocity, with clean metrics, while never questioning whether that backlog reflects the company's actual priorities. This produces the well-known enterprise IT paradox where the PMO dashboard shows green (on time, on budget, high throughput) while the CFO or CEO is separately convinced that IT delivers no strategic value — both can be true simultaneously, because delivery quality and portfolio quality are orthogonal, and only demand management governs the latter. ## The second symptom — shadow IT The second, more corrosive symptom is shadow IT. When the formal demand-management process is slow, opaque, or perceived as arbitrary — long queues, unclear scoring criteria, requests silently deprioritized without explanation — business units with a budget of their own stop submitting requests through the front door and instead: - buy SaaS tools directly, - hire contractors outside IT's sourcing process, - or build spreadsheet-and-macro 'systems' that later become load-bearing and unsupported. This isn't a business-side failure of discipline so much as a rational response to a demand process that isn't delivering: if going around IT gets the marketing team its campaign tool in two weeks instead of the eight months a backlogged intake process would take, they will go around it, and no amount of supply-side delivery excellence fixes that, because supply management was never the bottleneck — demand intake was. ## The trade-off — governance overhead, answered by tiering The trade-off in building out demand management is governance overhead: a rigorous intake and scoring process adds friction and latency to every request, including genuinely urgent or small ones, and if the scoring criteria and committee cadence aren't calibrated to request size, it produces the opposite failure — a lightweight bug fix stuck behind the same six-week portfolio review cycle as a multi-million-dollar platform investment, which pushes teams right back toward shadow IT to avoid the process entirely. Mature organizations solve this with **tiered governance**: | Request | Approval path | |---|---| | Small, low-risk requests | get lightweight, delegated approval close to the team | | Large or cross-cutting investments | go through the full portfolio committee | So demand management adds rigor where it earns its cost without becoming supply management's bottleneck. Financial services and large regulated enterprises — where every IT spend traces back to a portfolio committee — are the canonical setting where this split is formalized explicitly, often under a technology business management (TBM) or similar cost-transparency framework so that demand decisions are made with real cost data rather than guesses.