IT Project Portfolio Management: Why You Have Too Many Projects

Walk into almost any mid-size enterprise IT department and ask to see the project portfolio. What you'll find is a list of somewhere between 15 and 60 active projects, depending on how generously "active" is defined. Every project has an approved business case. Most have a planned delivery date in the past. A significant number have the same handful of people assigned to them at different percentages. The portfolio is full, the people are stretched, and almost nothing is on schedule.

This is so common it has stopped surprising anyone who works in IT. The surprise would be an enterprise IT organization with a portfolio it can actually deliver.

The theory of IT project portfolio management (PPM) is sound. The PMI's Standard for Portfolio Management, and the broader literature on portfolio management, gives you the framework: prioritize projects based on strategic alignment and expected value, compare the portfolio against available capacity, and decline or defer projects that exceed capacity. In practice, this means an IT organization has to be able to say no to projects that have internal sponsors with authority over IT's budget. That is the place where the theory and the practice diverge.

Every project on the portfolio has a sponsor. The sponsor is typically a business unit leader, a VP, or occasionally a C-suite executive who has identified a capability their area needs and has navigated the internal approval process to get it funded. From that sponsor's perspective, the project is funded, approved, and waiting for IT to deliver it. "Funded and approved" means "this should happen." The idea that IT might defer the project because the portfolio is over capacity is, in the sponsor's mental model, an IT execution problem, not a portfolio management problem. IT is under-resourced, or IT is not prioritizing correctly, or IT is inefficient. The portfolio is too full only from IT's side of the table.

This political economy of project portfolios is why capacity discipline in IT is so rare. To enforce capacity, IT leadership has to go to the business and say: we cannot do everything on this list, here is what we can realistically deliver this year, and here is what we need to defer or cancel. That conversation requires either organizational authority that IT rarely has over business units, or executive sponsorship at a level that typically isn't sustained through multiple planning cycles. IT leaders who try to have this conversation get told that IT should find a way. IT leaders who stop trying learn to keep the list long and manage expectations through delivery slippage instead.

The consequence is a portfolio where the delivery dates are mostly fiction. Projects stay "in progress" for longer than planned because the people working on them are simultaneously "in progress" on six other things. Resources in IT project portfolios are the actual constraint, not the list of approved projects. And resources in IT are not fungible. The same three senior enterprise architects review the solution designs for every project. The same two security specialists conduct the security assessments. The same database administrator handles the schema migrations. Formally, they are allocated across a dozen projects at 10 or 15 percent each. Actually, each of them is the critical path on whichever project is currently on fire, and the projects that aren't on fire wait.

Gartner research on IT budgeting and portfolio management has consistently highlighted the gap between planned and actual delivery capacity in enterprise IT portfolios (see Gartner Newsroom). According to Gartner, organizations frequently underestimate the resource constraints that limit portfolio throughput, and IT leaders often face difficulty translating capacity limits into governance decisions that business stakeholders accept. I'll hedge the specific statistics because those vary across their research, but the directional finding is consistent with what IT practitioners report.

The resource contention problem is harder to see than the project list problem because it operates below the level of formal portfolio reporting. Portfolio dashboards show projects with RAG statuses (Red, Amber, Green) and milestone dates. They don't usually show that the same three people are the bottleneck on every amber and red project in the portfolio. When a project slips, the explanation in the steering committee is usually specific to that project: the requirements changed, a key vendor was late, a technical issue was discovered during testing. The systemic explanation, which is that the organization is running more projects than it has capacity to deliver given the concentration of critical skills in a small number of people, doesn't make it into the steering committee report because it implicates the portfolio management process rather than any individual project.

The fix is not primarily technical. There is no project management software that solves this. The fix is organizational: build enough governance authority to enforce capacity limits, make the resource bottlenecks visible in portfolio reporting, and develop more people who can do the scarce things so that the portfolio is less dependent on a handful of individuals. Those are the hard interventions. They require organizational authority, sustained management attention, and willingness to disappoint project sponsors in the short term to deliver more reliably in the medium term.

Some organizations get there through crisis. A high-profile failure, a missed regulatory deadline, or a board-level conversation about IT delivery reliability creates a window for real change. Someone with sufficient authority declares that the portfolio will be right-sized. Projects get deferred with real governance behind the deferral. Capacity gets managed against a realistic model. This can work, but the gains tend to erode over time as new projects accumulate and the memory of the crisis fades.

The organizations I've seen manage this well typically have two things in common. First, IT has a strong relationship with the CFO or COO, which gives it organizational backing to enforce portfolio limits when business unit sponsors push back. Second, the portfolio is reviewed at a level where the person running the review has authority over multiple business units simultaneously, so they can arbitrate between competing project sponsors rather than leaving IT to absorb the conflict alone. Without those two conditions, portfolio discipline is largely aspirational. The list stays long. The people stay stretched. The delivery dates stay fictional.