The AI Use-Case Backlog Is Becoming a Strategic Liability.

AI Strategy Series | Article 3 of 20

Building the Intelligent Enterprise

Enterprise organizations have become remarkably proficient at identifying opportunities to use artificial intelligence.

They are considerably less proficient at deciding which opportunities deserve to become operational capabilities.

Across industries, AI innovation workshops, employee surveys, departmental assessments, vendor demonstrations, and executive brainstorming sessions are producing extensive inventories of potential applications.

The resulting backlogs can contain dozens or hundreds of proposed initiatives.

Some promise productivity improvements.

Others target customer experience, operational efficiency, decision support, revenue growth, or competitive differentiation.

Still others exist because a vendor demonstrated an interesting capability or a competitor announced a similar deployment.

The opportunities accumulate.

The backlog grows.

And somewhere along the way, an instrument intended to organize innovation becomes a substitute for making strategic decisions.

The size of an organization’s AI opportunity backlog is not evidence of strategic maturity. It may be evidence that leadership has postponed the difficult work of prioritization.

That distinction matters because AI opportunities are becoming easier to identify while the organizational capacity required to implement them remains constrained.

Models are becoming more capable. Development tools are improving. AI functionality is increasingly embedded in enterprise applications.

But enterprise architecture, integration capacity, information quality, organizational change, executive attention, and investment capital remain finite.

An organization can generate AI opportunities faster than it can absorb them.

When that happens, the backlog stops being an innovation asset.

It becomes a strategic liability.

When Opportunity Discovery Outpaces Enterprise Capacity

Traditional enterprise technology portfolios have always faced competing demands.

Business units request new applications.

Operations teams identify automation opportunities.

Executives sponsor transformation initiatives.

Technology organizations balance modernization, maintenance, security, and innovation.

Artificial intelligence intensifies this familiar challenge because the apparent barriers to experimentation have fallen dramatically.

An employee can demonstrate a generative AI prototype in an afternoon.

A business unit can identify multiple potential applications after a single vendor presentation.

A software development team can assemble a working proof of concept using commercially available models and APIs.

These capabilities are valuable.

They also create a dangerous illusion.

The ability to demonstrate an AI capability is not equivalent to the enterprise’s ability to operate that capability reliably, economically, and at scale.

A prototype may require only a model, an interface, and sample data.

A production implementation may require enterprise identity integration, authoritative information sources, application interfaces, workflow orchestration, monitoring, exception handling, performance evaluation, operational support, and organizational change.

The difference is substantial.

Yet many AI opportunity portfolios evaluate proposed initiatives primarily on the attractiveness of their potential benefits and the apparent ease of producing an initial demonstration.

The harder questions emerge later.

Who owns the resulting capability?

Which enterprise systems must it integrate with?

What happens when the model produces an incorrect result?

How will its performance be evaluated?

What operational changes are required to realize the anticipated benefits?

Which existing applications or processes will it replace?

What is the ongoing cost of maintaining it?

A backlog that does not account for these questions systematically understates the resources required to turn experimentation into enterprise capability.

The result is predictable.

Projects begin faster than they finish.

Pilots accumulate.

Integration teams become overloaded.

Business sponsors lose interest.

And the organization discovers that its apparent AI momentum has produced relatively little enterprise transformation.

The Hidden Economics of an Expanding Backlog

An AI backlog is not merely a collection of potential investments.

It also represents a collection of future claims against limited enterprise resources.

Every initiative that advances beyond initial exploration may require architecture reviews, data engineering, integration development, security assessments, business process redesign, user training, operational support, and executive sponsorship.

These requirements create dependencies across the organization.

Consider a hypothetical enterprise with 80 proposed AI use cases.

Management evaluates the opportunities and approves 20 for development.

Each initiative appears financially attractive when assessed independently.

But suppose 15 require integration with enterprise resource planning systems.

Twelve depend on customer or product data that must be reconciled across multiple platforms.

Ten require specialized model evaluation capabilities.

Eight depend on the same small group of enterprise architects.

And several require business process changes involving departments already committed to major transformation programs.

The organization may have sufficient funding to authorize the projects.

It does not necessarily have sufficient capacity to execute them.

That distinction exposes a fundamental weakness in conventional project-by-project prioritization.

A portfolio of individually attractive AI investments can be collectively unexecutable.

The problem is not that the individual business cases are necessarily wrong.

It is that their assumptions may depend on resources, capabilities, and organizational capacity that cannot be allocated simultaneously.

The enterprise has evaluated investment attractiveness without adequately evaluating portfolio feasibility.

As the backlog expands, this problem becomes more difficult to detect.

The Backlog Creates Five Strategic Liabilities

An unmanaged AI opportunity backlog introduces risks that extend well beyond delayed projects.

1. It Fragments Strategic Investment

When every business unit maintains its own AI priorities, investment decisions tend to reflect local objectives.

Finance wants reporting automation.

Marketing wants content generation.

Operations wants forecasting.

Human resources wants employee assistants.

Customer service wants conversational AI.

Each request may have a legitimate business justification.

But the resulting portfolio may lack a coherent relationship to enterprise strategy.

Leadership ends up funding many modest improvements while failing to concentrate sufficient resources on the capabilities that could materially change business performance.

This is particularly dangerous when the organization has already identified major strategic constraints.

An enterprise struggling with customer onboarding capacity, for example, may invest in numerous departmental AI tools while postponing the architectural and operational changes required to improve onboarding throughput.

The portfolio produces activity.

The constraint remains.

2. It Encourages Architectural Duplication

Independent AI initiatives frequently reproduce similar technical capabilities.

Multiple teams build document processing services.

Different departments implement separate knowledge retrieval systems.

Several applications establish their own model integrations, orchestration components, evaluation methods, and monitoring capabilities.

Over time, the organization accumulates overlapping technical infrastructure.

This increases implementation costs, complicates maintenance, and makes enterprise-wide improvements more difficult.

It also creates architectural commitments that may outlast the original use cases.

An AI prototype that becomes embedded in a critical workflow is no longer an isolated experiment.

It has become part of the enterprise application architecture.

Without deliberate architectural coordination, a growing AI backlog can accelerate the fragmentation that enterprise architecture programs have spent years attempting to reduce.

3. It Consumes Scarce Execution Capacity

Enterprise AI implementations compete for specialized resources.

Data engineers, integration architects, software developers, domain experts, security professionals, and operational leaders are not infinitely available.

Nor is executive attention.

A backlog that encourages too many concurrent initiatives increases context switching, coordination overhead, and competition for shared resources.

Work may appear to advance across many projects while few reach operational completion.

This resembles a familiar problem in software engineering and operations management: excessive work in progress.

Little’s Law establishes a relationship among average work in progress, throughput, and cycle time in a stable system.

Although enterprise AI portfolios are more complex than simple production queues, the underlying operational lesson remains useful.

When organizations increase concurrent work without increasing effective throughput, completion times tend to grow.

Starting more AI projects does not necessarily increase the number of AI capabilities the enterprise can successfully operationalize.

In some circumstances, it reduces them.

4. It Distorts Investment Measurement

An expanding backlog encourages organizations to measure what is easiest to count.

Number of use cases identified.

Number of pilots launched.

Number of proofs of concept completed.

Number of employees using AI.

Number of applications incorporating AI functionality.

These measures may provide useful operational information.

But they do not establish whether the AI portfolio is improving enterprise performance.

An organization can report impressive activity while realizing limited financial or strategic value.

The problem becomes worse when projected benefits are aggregated across proposed use cases.

One initiative promises labor savings.

Another promises faster decision-making.

A third promises increased capacity.

A fourth promises improved customer satisfaction.

If the estimates are developed independently, they may double-count benefits, overlook shared dependencies, or assume that recovered capacity automatically translates into financial savings.

The resulting portfolio valuation can become an elaborate exercise in adding together assumptions that have never been reconciled.

5. It Delays Difficult Strategic Decisions

Perhaps the most consequential liability is organizational.

A large backlog allows leadership to postpone choosing among competing priorities.

Instead of deciding which enterprise capabilities deserve concentrated investment, management can authorize additional exploration.

Instead of declining a marginal initiative, it can move the proposal into a future planning cycle.

Instead of resolving conflicting business priorities, it can maintain both opportunities in the portfolio.

The backlog becomes a politically convenient holding area.

Nothing is rejected.

Nothing is conclusively prioritized.

And the organization gradually loses the ability to distinguish strategic commitments from expressions of interest.

A strategy that refuses to exclude alternatives is not a strategy. It is an inventory.

Why Traditional Prioritization Matrices Are Not Enough

Many organizations attempt to manage AI opportunities through scoring models.

Proposed initiatives receive numerical ratings for expected value, implementation complexity, technical feasibility, data readiness, and organizational risk.

The scores are combined into a ranking.

Projects with the highest scores receive funding.

This approach introduces useful discipline, but it has limitations.

First, numerical precision can conceal subjective assumptions.

A proposed initiative may receive a business value score of 8.5 out of 10, but what does that number actually represent?

Is it based on measurable operating constraints?

A validated financial model?

Executive judgment?

Vendor estimates?

Or the enthusiasm of the sponsoring department?

Second, scoring models often treat opportunities as independent.

They may not adequately capture shared architectural dependencies, resource contention, or the value of reusable enterprise capabilities.

Third, prioritization matrices can favor projects that are easy to implement.

An AI assistant requiring limited integration may score better than a difficult initiative capable of transforming a strategically important business process.

The organization then builds a portfolio optimized for implementation convenience rather than enterprise value.

Fourth, scoring models may fail to distinguish different investment purposes.

A foundational AI platform, an experimental agent, and a production workflow transformation should not necessarily compete under identical evaluation criteria.

Their objectives, uncertainties, and expected returns are different.

A more mature portfolio model must account for those distinctions.

Three Portfolios, Not One Backlog

I recommend separating enterprise AI investments into three distinct portfolios.

This does not require three disconnected management systems.

It requires three different investment classifications, each with appropriate evaluation criteria and decision rules.

Portfolio 1: Strategic Transformation

These initiatives directly address constraints affecting enterprise performance or competitive positioning.

Examples include redesigning customer onboarding, accelerating product development, improving supply chain responsiveness, or expanding service capacity.

The defining characteristic is not the sophistication of the AI technology.

It is the significance of the business outcome.

Strategic transformation investments should be evaluated against:

• Alignment with enterprise strategy.
• Importance of the business constraint being addressed.
• Expected economic and operational impact.
• Required changes to the operating model.
• Architectural and organizational dependencies.
• Evidence supporting the investment hypothesis.
• Ability to measure realized business outcomes.

These initiatives deserve concentrated executive attention because they have the greatest potential to change enterprise performance.

They may also be among the most difficult to execute.

Portfolio 2: Enterprise Enabling Capabilities

These investments establish reusable capabilities required to support multiple AI initiatives.

Examples include enterprise data services, model evaluation infrastructure, secure model access, identity integration, workflow orchestration, observability, and shared knowledge architecture.

Their value may not be captured adequately through a single application business case.

A shared document intelligence capability, for example, might support customer onboarding, contract management, financial analysis, and regulatory reporting.

Evaluating it solely against the first use case could significantly understate its potential enterprise value.

Enabling investments should be assessed according to their contribution to strategic execution, reuse potential, architectural coherence, operating economics, and reduction of future implementation friction.

They should not be funded simply because they represent fashionable technology.

The enterprise must establish which strategic capabilities depend on them.

Portfolio 3: Exploration and Experimentation

These initiatives investigate emerging capabilities, validate assumptions, and reduce uncertainty.

They may involve new models, agent architectures, multimodal systems, advanced analytics, or unconventional applications.

Their purpose is learning.

That means their success criteria should differ from those of production investments.

An experiment can be successful even when the organization decides not to proceed.

If a pilot establishes that a proposed capability is economically impractical, technically unreliable, or operationally unsuitable, it may have prevented a much larger investment mistake.

The important requirement is that experimentation produce a decision.

A pilot that never produces a scale, revise, or stop decision is not an innovation strategy. It is unfinished work.

The Missing Discipline: Portfolio Exit Criteria

Enterprise technology organizations have long struggled to terminate projects that no longer justify their investment.

AI introduces additional complications.

Capabilities improve rapidly.

Model costs change.

Vendor offerings evolve.

New technical approaches emerge.

An initiative that appeared strategically attractive six months earlier may no longer represent the best available investment.

Yet organizations often continue funding projects because resources have already been committed or because the initiative has an influential sponsor.

This is the sunk-cost problem expressed through enterprise technology management.

A disciplined AI portfolio requires explicit exit criteria.

Every significant initiative should establish conditions under which leadership will continue, revise, defer, or terminate the investment.

These conditions might include failure to achieve required model performance, inability to obtain authoritative data, unacceptable integration costs, insufficient business adoption, or evidence that the expected operational benefits cannot be realized.

For exploratory initiatives, exit criteria should be particularly clear.

The purpose of a pilot is to resolve uncertainty.

Once that uncertainty has been sufficiently resolved, the organization should make a decision.

Continuing experimentation indefinitely is not a neutral choice.

It consumes resources that could support more consequential opportunities.

The Portfolio Needs a Capacity Model

A realistic AI investment portfolio must reflect the enterprise’s ability to execute.

Funding alone is insufficient.

Leadership should understand the capacity available across the functions required to deliver AI capabilities.

That includes architecture, engineering, data management, security, integration, business process redesign, testing, operational support, and organizational change.

The portfolio should identify shared dependencies and critical resource constraints.

For example, if ten initiatives depend on the same enterprise integration team, their schedules cannot be evaluated independently.

If multiple projects require remediation of the same data quality problems, the organization should consider addressing those problems as shared enabling investments.

If business units lack the capacity to redesign workflows, deploying additional AI functionality may create technical assets without operational adoption.

The objective is not to produce a perfect capacity forecast.

That would be unrealistic in a rapidly changing technology environment.

The objective is to prevent the enterprise from authorizing a portfolio whose execution assumptions are internally inconsistent.

A portfolio should represent what the organization has chosen to accomplish, not everything it would like to attempt.

From Use-Case Backlog to Strategic Investment Portfolio

The transition requires changing how AI opportunities enter, advance through, and exit the investment process.

I recommend a six-stage model.

Stage 1: Capture the Opportunity

Record the proposed capability, sponsoring business function, expected benefit, and underlying business problem.

At this stage, the objective is to preserve useful ideas without implying that every submission deserves implementation.

Stage 2: Establish Strategic Relevance

Determine which enterprise objective or business constraint the opportunity addresses.

If the connection is weak or unclear, the initiative should not automatically proceed.

Some proposals may be retained for exploration, but they should not be represented as strategic transformation investments.

Stage 3: Identify Dependencies and Alternatives

Evaluate the data, architecture, integration, organizational, and operational capabilities required.

Consider whether conventional automation, process redesign, or existing enterprise software could deliver the desired outcome more effectively.

Stage 4: Classify the Investment

Assign the initiative to strategic transformation, enabling capability, or exploration.

This determines the appropriate evaluation criteria and funding expectations.

Stage 5: Authorize Against Available Capacity

Approve investments based on strategic priority and realistic execution capacity.

Do not assume that every financially attractive proposal can proceed simultaneously.

Explicitly identify which initiatives must wait, which share dependencies, and which should be consolidated.

Stage 6: Measure, Reassess, and Decide

Evaluate progress against the initiative’s stated purpose.

For strategic transformation, measure business outcomes.

For enabling capabilities, measure readiness, reuse, reliability, and contribution to dependent initiatives.

For exploration, measure the reduction of uncertainty and the quality of the resulting investment decision.

At defined intervals, determine whether to continue, scale, revise, or terminate the initiative.

This approach transforms the backlog from an accumulation of possibilities into a managed system of enterprise choices.

The Boardroom Implications

AI portfolio management should not become an exercise in presenting increasingly impressive dashboards.

Boards and executive investment committees need visibility into the relationship between AI investment and enterprise strategy.

A portfolio containing 100 proposed use cases tells directors relatively little.

A portfolio showing five strategically important business constraints, the investments intended to address them, the capabilities required for execution, and the evidence of realized outcomes provides a much stronger basis for oversight.

The discussion should focus on questions such as:

• Where are we concentrating our AI investments, and why?
• Which enterprise capabilities are we attempting to change?
• What percentage of our investment supports strategic transformation rather than isolated experimentation?
• Which shared dependencies could prevent execution?
• How much work have we authorized relative to our actual delivery capacity?
• Which initiatives have we stopped because the evidence no longer supports continued investment?

The last question is particularly revealing.

An organization that never terminates an AI initiative may not be demonstrating exceptional investment judgment.

It may be demonstrating an unwillingness to make difficult decisions.

Effective portfolio management requires both investment discipline and the willingness to redirect resources as evidence changes.

The Architecture of Portfolio Decisions

There is a broader enterprise architecture implication.

AI portfolio management is not simply a financial allocation process.

It is also an architectural decision process.

Every significant AI investment introduces or modifies enterprise capabilities.

Some decisions create reusable infrastructure.

Others establish dependencies on particular vendors, models, platforms, or integration patterns.

Still others change how business processes operate and where decisions are made.

These choices accumulate.

An enterprise that evaluates AI initiatives independently may approve a collection of locally rational decisions that collectively produce an incoherent architecture.

Conversely, an organization that evaluates investments through a common enterprise capability model can identify opportunities for reuse, consolidation, and strategic sequencing.

For example, three proposed AI assistants may appear to be separate departmental projects.

Architectural analysis may reveal that all three depend on the same underlying requirement: reliable access to authoritative enterprise knowledge.

The more valuable investment may be a shared knowledge capability supporting all three applications.

That decision cannot be made effectively by evaluating each use case in isolation.

It requires understanding how individual investments contribute to the enterprise’s future operating and technology architecture.

The AI portfolio is becoming one of the places where enterprise strategy is translated into architectural commitments.

That makes portfolio discipline an essential component of intelligent enterprise design.

The Executive Imperative

Enterprise leaders should stop treating the growth of the AI use-case backlog as an accomplishment.

Generating opportunities is easy compared with selecting, executing, and operationalizing the ones that matter.

The challenge is no longer demonstrating that artificial intelligence can be applied across the organization.

That question has largely been answered.

The challenge is determining which applications deserve scarce capital, architectural capacity, organizational attention, and long-term operational commitment.

A disciplined AI portfolio should make strategic priorities visible.

It should distinguish transformation from enablement and experimentation.

It should account for shared dependencies and realistic execution capacity.

It should establish measurable outcomes and explicit exit criteria.

And it should demonstrate that leadership is willing to decline attractive opportunities when they do not advance the enterprise’s most important objectives.

The objective is not to eliminate experimentation or discourage innovation.

It is to ensure that innovation produces meaningful enterprise capabilities rather than an expanding inventory of unfinished possibilities.

Artificial intelligence will continue to generate new opportunities faster than most organizations can implement them.

That imbalance is unlikely to disappear.

The enterprises that succeed will therefore need to become increasingly selective.

The strategic advantage will not belong to the organization with the largest AI backlog. It will belong to the organization that consistently makes the best decisions about what deserves to leave the backlog and become an enterprise capability.

And sometimes, the most valuable AI investment decision will be the one leadership chooses not to make.

References

Goldratt, Eliyahu M., and Jeff Cox. The Goal: A Process of Ongoing Improvement. Revised ed. Great Barrington, MA: North River Press, 2004.

Kaplan, Robert S., and David P. Norton. The Balanced Scorecard: Translating Strategy into Action. Boston: Harvard Business School Press, 1996.

Little, John D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research 9, no. 3 (1961): 383–387. https://doi.org/10.1287/opre.9.3.383.

Porter, Michael E. “What Is Strategy?” Harvard Business Review 74, no. 6 (November–December 1996): 61–78.

Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach, CA: Celeritas Publishing, 2009.

Coming Next

Article 4 — Where Should AI Actually Have Decision Authority?

As enterprises move beyond AI-assisted analysis and content generation, artificial intelligence is increasingly capable of initiating actions, executing workflows, and making operational decisions.

That introduces a strategic question more consequential than which models or platforms an organization deploys:

What authority should the enterprise delegate to artificial intelligence, and where must human judgment remain decisive?

In the next article, we examine the distinction between AI that informs, recommends, executes, and autonomously decides—and why defining those boundaries is becoming a foundational enterprise strategy decision.