Widespread deployment of Artificial Intelligence is forcing companies to scrutinize their cost structures in new ways. News reports of companies laying off thousands of workers due to the impact of AI are increasingly common, such as Megan Cerullo’s CBS News report last month. To her credit, she questions whether layoffs are a “harvesting of value” produced by AI or caused by some other factor.  Ben Cagle, Managing Partner at Cagle Partners, is blunter in his assessment, “The narrative? AI productivity. The reality? AI capital expenditure.” [2]

The truth is that companies are struggling to squeeze investments in AI into their already constrained operating expense budgets.  Who loses that struggle? The workers whose jobs are eliminated to make room for increased operating expenses generated by “pay per use” generative AI tools such as ChatGPT or Claude.

A Common Pitfall: Cost Myopia

The approach of making space for generative AI expenses by large percentage reductions in labor spending is a common, but serious error due to its focus on cost rather than value. It is too easy for an organization’s finance team to solve a cost overrun by mandating a reduction in labor costs. Once these reductions are baked into a budget, they become non-negotiable as Operators in the business are held accountable to achieve the cost numbers articulated in the budget.

A Better Way: Value Engineering

Value Engineering, the analysis of a good or service in terms of the cost of its subcomponents and the relative value they contribute to a finished good, is a concept that has its roots in purchasing and materials management. I was introduced to this style of analysis back in the 1990s via a purchasing management class based on the book, Purchasing and Materials Management – Text and Cases, by Dobler, Burt and Lee, Jr.

The approach has value beyond purchasing and materials management. We can apply the fundamental idea to any business in two specific areas: growing a business by improving its ability to attract more customers or improving the efficiency with which customers receive products or services.

We begin with a simple definition of value: the benefits generated by a product or capability minus its costs.  A key characteristic of this definition is that the benefits must be monetized so costs can be subtracted from them. The definition is important because it forces us to wrestle with ways to monetize things that many leaders consider to be “intangible,” such as functional value, aesthetic value, or environmental value. [3]

What can be “Value Engineered?”

From its inception at General Electric in the 1940s to keep products affordable without sacrificing quality during World War II, value engineering has been most frequently associated with products: finished goods that are sold to external customers. [4] However, the technique can be applied to other elements of a business and at various levels of abstraction, including:

• Value Streams
• Business capabilities and their subcomponents:
  • Roles / People
  • Business processes
  • Assets (both physical and technology [including data])
• Organizations/business units

One of the benefits of evaluating a set of items (e.g. business capabilities, business processes or assets) is that it enables the organization to understand the relative value being created by various elements in its business.

Sometimes this type of assessment unlocks “surprises” that are hidden in the financial and usage data. I once led a value engineering analysis of a suite of e-commerce applications for a large technology firm. We discovered a pattern that the centralized infrastructure function routinely purchased 3x the hardware needed to run an application. Our average utilization was 12%, and workload rarely exceeded 25% of capacity.

Purchase of unnecessary capacity inflated costs allocated to other business units in multiple ways because the centralized infrastructure department allocated cost to business units by number of servers deployed to a business unit. Once discovered, our value engineering team was able to immediately save scores of millions of dollars in annual infrastructure costs by shutting down the unnecessary servers.

Value Engineering in Eight (Not So) Easy Steps

At the highest level of abstraction, value engineering is a combination of eight steps.  The first two are challenging because they set the guardrails for the remaining work.  The last one is challenging because it forces the organization to convert the benefits generated into cash that can be used to fund subsequent improvements.

1. Identify the unit of analysis,
2. Quantify how the unit of analysis generates benefits,
3. Identify subcomponents,
4. Calculate one time and ongoing costs for subcomponents,
5. Find improvement opportunities,
6. Break opportunities into discrete units of value,
7. Prioritize and begin working the list, and
8. Monetize the results.

Identify the Unit of Analysis

 Identify the “thing” to be analyzed: value stream, business capability, process, or set of assets. Effort to conduct the analysis is largely correlated to the number of things being analyzed.  For example, a mid-sized to large organization typically has 8 – 15 “level one” capabilities, the highest-level abstraction in a business capability map. Each capability has multiple business processes, roles and supporting assets. To prevent scope from quickly expanding to an unreasonable amount, it’s often useful to select a unit of analysis based on the degree to which it is underperforming, either financially or against its planned cycle time and quality service levels.

Quantify Benefits

Quantifying the benefits a unit of analysis generates is often the most challenging step in the process, particularly for items classified as “strategic and governance” capabilities.  Generation of value must be quantifiable and convertible to cash. Value must also be generated as the unit of analysis operates its business processes or work is processed by an asset.

The measurable benefits are going to serve an important role in the rest of the analysis, not only for benchmarking current performance, but also placing an upper limit on investments in improvements. For example, an organization would not spend $5 million improving something that only generates $100,000 a year in value.

Identify Subcomponents

Having identified a unit of analysis and its source(s) of benefits, the next step is to identify its subcomponents. For a value stream, its subcomponents are the value stream stages. For a business capability, its subcomponents can be either a more granular business capability, or the combination of the people (roles), business processes, and assets that instantiate the capability. For an asset, its subcomponents are the labor and non-labor elements needed to operate and sustain the asset.

Calculate Subcomponent Costs

Calculate the one time and ongoing costs for each subcomponent, taking care to ensure that the sum of the costs is a valid representation of the value stream, process or capability. One way to do this is to count the frequency with which a process is executed and then calculate the cost per execution. Once the cost per execution is known, then it can be extrapolated based on the daily, weekly, or monthly frequency with which the component is utilized.

Find Improvement Opportunities

Having determined the costs and sources of benefits for the subcomponents of our unit of analysis, we can identify outliers (high cost + low benefits, or where benefits – costs is smaller than the organization’s expected values). Identify potential improvements, structuring them as discrete changes that generate measurable value and can be implemented in less than 90 days.

Define how success will be measured, as well as the mechanism(s) that will be used to monetize the improvements. Develop a high-level cost estimate and expected improvement quantified in cash for each item.  Sometimes this means adding an incremental sales goal to a sales plan when the benefit is an increased conversion rate, and at other times it may mean booking headcount reductions to monetize improvements in efficiency.

Prioritize the Opportunity List and Implement Improvements

Use a technique such as weighted shortest job first to prioritize the opportunity list. The idea here is to solve problems in small chunks and quickly generate value so that subsequent improvements are funded by the value of the improvements we have already deployed to customers and end users.

Monetize the Results

As improvements are delivered to customers and end users, review the success measures relative to their planned values, and act on the results. Aside from establishing the unit of analysis and determining sources of benefits, this is the toughest step. Many companies plan to generate benefits from improvement initiatives, but they fail to convert improvements in productivity to cash, with the unintended consequence of increasing overall operating expenses rather than decreasing them.  For example, customer experience improvements can be monetized in one or more of the following ways:

• Increases in a conversion funnel times an average order value,
• Increased purchase frequency per unit of time,
• Increases in the number of product categories purchased per unit of time,

A/B and Multivariate testing are important tools organizations can use to test actual customer response to changes in capabilities or processes. Successful tests increase an organization’s confidence that the planned improvements are perceived as such by customers and end users.

Case Study: A Focus on Facts Leads to Wise Investments

One of the key benefits of the value engineering technique is that through the assembly of relevant facts, a leadership team makes decisions based on empirical evidence rather than gut feel or personal persuasiveness. For example, I once participated in a decision about whether to spend $20 million in capital to upgrade an e-commerce capability because the line of business owner asserted a system replacement was needed to achieve a 30% sales growth rate.

Another executive didn’t want to spend the capital on e-commerce and pushed back against the proposal. Both executives were looking for facts to support their intuition. A team was assembled to value engineer the e-commerce capability, including its ability to handle a 30% compound annual growth rate in sales over three years.

The team discovered that while the e-commerce software could support 30% annual growth, the customer service center would need to hire 60 additional people to handle the resulting backorders. Instead of spending $20 million on a systems replacement, the organization redirected funds to fix supply chain backorders, generating $2.5 million in annual productivity gains.

Common Objections

Value Engineering of things beyond finished goods has a lot to recommend it. Why do so few companies use it as a tool to accelerate profitable growth?

Objection 1: We don’t have time/data/skills, etc.

It’s true that organizations rarely have idle capacity to analyze the effectiveness and efficiency of their value streams and capabilities. It usually takes pain in the form of serious underperformance in a business area to justify an investment in value engineering. Scoping this form of analysis to one to three underperforming areas will give an organization some quick wins as well as developing experience with the approach.

Objection 2: Value Engineering is old-school Manufacturing – doesn’t apply to SaaS / Digital

Ironically, changes in corporate cost structures have been significantly impacted by technological advancements over the past 30 years, including cloud computing, subscription-based Software as a Service, and now pay-per-use operating expenses associated with the use of Generative AI tools.

Many of these expenses are either out of direct control of the end user departments to which the expenses are allocated, or only indirectly controlled. Therefore, knowledge of the details of sources of costs, as well as the entities who actually control the costs, are increasingly important for line of business executives to maintain predictability in their P&L statements.  As “old-school” as value engineering may be, it is a straightforward way to isolate sources of benefits and cost, and clarify who directly controls the costs.

Objection 3: This is too academic for our organization to adopt

The ability to scale the technique up or down as needed allows teams to value engineer their own areas before making a larger push for department or organization-wide. Value engineering is a much easier sell when a leader presents it to colleagues in a package that includes actual results generated within the organization’s specific context. If it can be proven to improve results, the degree to which the technique is rooted in academia is irrelevant.

Conclusions

Value Engineering is an important technique for leaders to dust off and add to their toolkits to generate profitable growth in companies of all sizes. Its focus on value versus cost, combined with simplicity of implementation, enable it to be implemented at a small enough scale to produce results quickly. Value Engineering is also sufficiently scalable to generate scores of millions in annual value.

Start small this quarter: Pick one underperforming capability or process, assemble a small cross-functional team, and run a focused Value Engineering workshop. The data-driven insights you uncover will quickly pay for the effort – and may fundamentally change how your organization approaches AI-related cost pressures.

References

[1] Cerullo, Megan –  AI Emerges as Top Cause of Layoffs, Accounting for 26% of April’s Job Cuts, CBS News website, retrieved May 17, 2026.

[2] Cagle, Ben – Search for AI ROI. Focus on the Business Impact, LinkedIn article, retrieved May 17, 2026.

[3] Rahman, M. Abdur – A Comprehensive Guide to Value Analysis and Value Engineering, Kindle Edition, self-published, 2025, p. 45.

[4] Ibid., p. 46.

Are our teams actually getting better?

It’s a simple question, and not enough technology leaders are asking it. Some assume the answer is yes. Others are too buried in day-to-day delivery to step back and check. But every leader should be asking it, and that’s more true today than it was even a few years ago.

Teams are moving faster than ever, and AI is a big reason why. AI tools can help a team produce working code at a pace that would have seemed unrealistic not long ago. That speed is an opportunity. It’s also a risk. If you’re not watching whether your teams are genuinely improving, AI just helps you move faster in whatever direction you’re already headed. Including the wrong one.

So it’s worth asking honestly. Are your teams shipping value faster, creating fewer defects, and keeping the system easy to change? Or are they slowly turning it into something nobody wants to touch?

Most of us reach for DORA metrics to answer that, and that’s the right instinct. Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore are some of the best indicators we have for how well a software organization delivers.

But DORA has a blind spot. It tells you what’s happening. It doesn’t tell you why. And if you can’t see the why, it’s easy to spend real time and money fixing the wrong thing.

DORA Shows the Symptoms, Not the Cause

Picture three teams, each with a high Change Failure Rate. All three keep shipping changes that cause incidents or defects in production. On the surface, they look like they have the same problem.

They don’t.

One team might have almost no automated testing, so nothing catches a mistake before customers do. Another might have copied the same logic across dozens of files, so every change risks breaking something far away. A third might be bundling weeks of work into one big release, so when something fails, nobody can tell which change caused it.

Same symptom. Three completely different cures.

This is where a lot of organizations get stuck. They can see something is wrong, but they don’t have the signals to tell them what’s actually holding the system back. It’s worth borrowing one idea from the Theory of Constraints here: in any system, only one or two things are the real bottleneck, and effort spent improving anything else is mostly wasted. Finding the true constraint is the whole game.

Five Signals, and the Questions They Let You Ask

When I want to understand what’s really going on inside a delivery system, I look at five signals. They fall into three groups, and each group answers a different kind of question.

Delivery Signals

These tell you whether value is reaching customers, and whether it’s getting there safely.

When leaders tell me delivery feels slow, one of the first things I ask is: are teams finishing work, or just starting more of it? It comes back to a simple principle: start finishing, stop starting. Deployment Frequency is often less about speed and more about flow. The question for you as a leader: are we shipping in a steady rhythm, or is everything perpetually “almost done”?

Change Failure Rate tells me how safely teams are moving. One of my favorite sayings is “be quick, but don’t hurry.” The best teams move fast, but they stay in control while they do it. The question for you: when we move fast, do we stay in control?

Code-Health Signals

These are the signals DORA doesn’t give you, and they’re usually where the why lives.

When engineers start saying, “I’m afraid to touch that file,” cognitive complexity has usually already won. When cognitive complexity climbs, teams are usually patching around problems instead of simplifying the design. The question for you: is the system getting easier or harder to change?

Churn and Hotspots show you which parts of the system change the most. Churn is how often a file gets edited. A hotspot is a file that’s both changed often and complex. Sometimes a hotspot is the beating heart of the business. Sometimes it’s just a constant source of pain. Either way, it tells you where engineering attention will pay off most. The question for you: where is our risk concentrated?

Flow Signal

This one tells you how work actually moves.

Average Commits to Main per Day tells me whether teams are integrating work in small, safe steps. Higher commit frequency usually points to trunk-based development, which means small, frequent merges instead of long-lived branches. That gives you faster feedback and lower release risk. The question for you: are we working in small steps, or big risky ones?

Back to Our Three Teams

Here’s the payoff. These five signals do something DORA on its own couldn’t. They tell our three teams apart.

The team with no automated testing shows up in Change Failure Rate, paired with near-zero test coverage. The team with duplicated logic shows up in rising Cognitive Complexity and a cluster of hotspots. The team bundling big releases shows up in a low Commits to Main number.

Three teams, one shared symptom, three completely different stories. And now you can make three well-aimed investments instead of one expensive guess.

Signals, Not Targets

One of the biggest mistakes I see leaders make is turning a metric into a goal.

The moment a metric becomes a target, teams start optimizing the number instead of the behavior behind it. You get gaming, heavier process, and a lot of noise. People spend more time explaining the metric than improving the system. In the worst cases, you create an unsustainable pace where engineers are rewarded for chasing numbers instead of building good software.

Metrics should help you ask better questions. They should create understanding. They shouldn’t become a scoreboard.

A Real Example

I recently worked with a team supporting a legacy application that was three to five years old. When we started, it had no automated tests at all. Code coverage was effectively 0%.

Change Failure Rate was high, and so was Mean Time to Restore. Every production issue was stressful because nobody had much confidence that a fix wouldn’t make things worse.

Over time, the team adopted automated testing, trunk-based development, and feature flags. Coverage went from 0% to about 15%. That’s not a high number, but it was the first real safety net the team had ever had. Commits to main went up as work started moving in smaller, safer steps.

The results were significant. Defects dropped 63% quarter over quarter. Mean Time to Restore fell from days to hours, because the team could finally deploy a fix whenever they needed to. That meant customers spent hours, not days, living with a problem.

The DORA numbers improved too. But not because anyone was chasing them. They improved because the engineering system improved.

Why This Matters Even More with AI

AI coding tools can be incredibly effective. They can also produce insecure code, duplicate logic, and changes that are hard to understand and maintain. And they can do all of that faster than any human team ever could.

That’s exactly why these signals matter more in an AI-enabled organization, not less. They’re how you see the side effects. AI-generated code tends to push up Cognitive Complexity, create new hotspots, and raise Change Failure Rate when it ships without strong review and tests. Those three signals become your early-warning system.

Watch them, and AI accelerates good delivery. Ignore them, and AI just helps you create bad software faster.

Here’s the one idea I hope you remember: AI amplifies the engineering system you already have. If your teams work in small increments, keep the code clean, and have meaningful tests, AI speeds them up. If your systems are fragile and hard to change, AI amplifies that fragility too.

What These Signals Don’t Tell You

One honest caveat. Everything above tells you whether your teams are building software well. Safely, sustainably, and in a way that stays easy to change.

None of it tells you whether they’re building the right software. The features and outcomes that actually matter to customers. That’s a separate question, and it’s just as important. I’ll take it on in the next article in this series.

A Practical Next Step

You don’t need a new dashboard. You need a better conversation.

At your next engineering review, ask your leaders to bring these five signals, and ask them to bring the story behind the signals too. Pick the one or two that map to your biggest current pain, and keep asking why until you reach a root cause you can actually invest in.

Because the goal was never to collect more numbers. The goal is to understand the engineering system that produces your software, well enough to improve the right part of it.

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

When transformation isn’t producing results, the first instinct is to look at delivery. Teams aren’t shipping fast enough. The backlog is bloated. The release cadence is inconsistent. The organization reaches for the familiar remedies: new frameworks, better ceremonies, more alignment meetings. Sometimes this helps at the margin. The underlying problem persists.

Look closer, and the diagnosis shifts. Product teams aren’t unclear because they’re undisciplined. They’re unclear because the direction they’ve been given isn’t defined precisely enough to act on. Priorities change without notice. Investment decisions made last quarter are quietly re-litigated this quarter. Teams spend a disproportionate amount of time trying to understand what they’re supposed to be building and why — and not enough time building it.

Go deeper still, and the real constraint comes into focus. The connection between the strategy Executives have articulated and the execution happening in teams is broken. Not because the strategy is wrong, and not because the teams lack capability. Because the system connecting those layers, the governance that should be shaping how decisions are made, at what altitude, with what information, hasn’t been designed. Ambiguity that arrives from above is transmitted downward unchanged. Decisions that should be resolved at the Portfolio layer are escalated or deferred. The organization mistakes motion for direction, and remains, despite genuine effort, largely unchanged.

Nobody intended this. The system produced it.

Governance Is What Connects Every Layer

The four layers of an organization (Executives, Portfolio, Product, and Delivery) are not a reporting hierarchy. They are a system for making and sustaining decisions at different altitudes. Executives own the investment thesis: where are we committing capital and capability, and why? Portfolio translates that thesis into an explicit strategy. A defined set of outcomes, expressed as bets, with measures that make progress visible. Product owns the solution space. Determining what is worth building and why, grounded in evidence from the market. Delivery produces working solutions that test the assumptions underneath those decisions.

What makes this system function is not the existence of these layers. It is governance, deliberately designed, that connects them: the defined decision rights, the evidence flows between layers, the forums where direction is set and updated, and the transparency that ensures every layer is navigating by the same version of reality.

When that system works, value is realized quickly. The path from investment commitment to measurable outcome is short, visible, and actively managed. Disagreement produces better decisions rather than circular conversations. Each layer moves with confidence because it knows what it is accountable for and what the layer above and below it is accountable for.

When governance isn’t designed, or has been left to form by habit, the system seizes. Strategy stays aspirational. Discovery stays disconnected from investment. Delivery stays busy without direction. And the cost accumulates invisibly across quarters, in work that ships without compounding into capability and in investment that continues to flow without evidence that it is working.

Design How Decisions Flow Before You Design the Org Chart

Most organizations design their governance as a reporting structure that presents to whom, which forums exist, and for which updates. That is the wrong starting point. Governance defines how decisions work: who owns what decision, at what altitude, with what information, and what the system does when the evidence shifts.

Each layer has distinct decision rights. Executives own the investment thesis. Portfolio owns the strategy.  The translation of that thesis into explicit, testable bets. Product owns the solution space, determining what is worth building based on market evidence. Delivery owns execution. Building, testing, and learning at a cadence that surfaces results before the budget is spent.

When these rights are clear and the interfaces between layers are designed, the system can move. When they blur, when Executives are making product decisions, when Portfolio is managing delivery detail, when teams are left to infer a strategy that was never made explicit, the system seizes at exactly the points where it should flow.

Good governance doesn’t just define who decides. It defines the quality of information each layer operates with, the cadence at which decisions are reviewed, and the mechanism for updating direction when evidence demands it. Without it, every layer defaults to one of two failure modes: over-controlling decisions that belong at a lower altitude, or absorbing ambiguity from above rather than resolving it.

Discovery is Strategic Intelligence, Not Product Speculation

One of the most consequential flows in the system runs upward. And it is the most consistently underdesigned.

Discovery done well is not a product team exploring possibilities. It is a disciplined, objective inquiry into market opportunity and customer reality: what problems exist, what behavior patterns are present, what unmet needs have commercial consequence. The goal is not to generate ideas. It is to produce a clear, factual picture of where value can be created that the business is not currently creating.

That evidence only becomes strategic intelligence when it is filtered through specific business goals. The question is not “what could we build?” It is “given where we want to compete and what we need to achieve, what does the market tell us about the direction worth pursuing?” That framing transforms discovery from a product function into a direct input to the investment thesis, something that Executives and Portfolio teams need to engage with actively, not receive as a slide summary after the fact.

Which means discovery has to happen in full transparency. Not as a report delivered upward once conclusions have been reached, but as a shared process in which every layer, Executives, Portfolio, Product, and Delivery understand the game being played, the hypotheses under test, the evidence being gathered, and what success looks like at each stage. When everyone navigates by the same evidence, re-litigation loses its raw material. Parallel versions of reality cannot survive shared visibility.

A Bias to Action is a System Design Choice, Not a Team Characteristic

The organizations that move quickly do not have unusually decisive individuals. They have systems designed to produce decisions rather than defer them.

A bias to action, designed into governance, means every layer operates with the information it currently has; it defines what success looks like, commits to a timeframe, runs the experiment, and surfaces what it learned. It does not wait for certainty before moving. It creates certainty by moving. Each tranche of investment is contingent on the evidence produced by the previous one, which keeps risk bounded and learning compounding.

For Portfolio, this means claiming the agency to shape the path when direction from above is ambiguous, rather than waiting for permission to materialize. Waiting is not a neutral act. In a system that requires decisions to flow, deferring them is itself a structural choice to transmit confusion downward. For Product, it means committing the most informed hypothesis to a testable bet rather than continuing to discover in the absence of a decision. For Delivery, it means building toward observable outcomes and surfacing evidence on a cadence short enough to influence the next investment decision.

The governance creates the forum where that evidence is integrated. Not a status meeting. A decision meeting where each layer reports what it expected, what happened, and what that means for where investment flows next. The agenda is consistent. The decisions are different every time, because the evidence is always moving.

From Strategy to Learning Without the Rewrite Cycle

Consider a mid-sized enterprise software business in the middle of a significant shift in its commercial model. The executive team has concluded that long-term growth depends not on serving every customer’s every request, but on investing deeply in a small number of differentiating capabilities that position the business distinctively in the market. The strategic intent is clear at the top.

Three layers below, the picture looks entirely different. Customer-facing teams are measured on retention and satisfaction scores, so they advocate loudly, and understandably, for features that address the most vocal accounts. Engineering teams, operating largely independently, are making architectural decisions optimized for technical coherence rather than commercial outcome. Product teams are trying to build towards broader customer value, but are pulled constantly toward the most recent escalation. Everyone is working hard. Nobody is working on the same problem.

The absence is governance. There are no explicitly defined decision rights: no clarity on who can commit the product to a customer-specific request, who can decline one, or what the standard is for calculating whether a piece of work is worth doing relative to the business strategy. There is no mechanism for surfacing the cost of misalignment. The accumulated drag of investment flowing toward work that doesn’t compound into the executive team’s stated direction. Teams pull in different directions, not because they are misaligned in their values, but because the system was designed to let them.

The fix is not a new strategy deck. It is how the system is designed. Stable, cross-functional teams where customer knowledge, technical judgment, and commercial accountability are integrated rather than siloed. Change the incentive structure at the point of decision. When the team building the product also owns the customer relationship and is accountable for the commercial outcome, the tension between what an individual customer wants and what the business strategy requires becomes a decision the team has to make explicitly, not a conflict they can refer upward or quietly ignore.

Decision rights, defined at the right altitude, make the cost of misalignment visible. Discovery, done in full transparency rather than within functional boundaries, gives every layer, including Executives, the same objective picture of where the market is moving and which capabilities need to express differently to get there. Portfolio works with Executives to translate that picture into a defined set of bets: explicit outcomes, measurable over a bounded timeframe, funded in tranches contingent on what each previous tranche produced. The governance creates the forum where those bets are reviewed on a consistent agenda. What did we expect, what happened, what do we do next with the investment, and where changing course requires engaging with the evidence, not simply calling a new meeting.

The system does not eliminate tension between customer needs and strategic direction. It forces that tension to be resolved at the right altitude, by the right people, on the basis of shared evidence. That is what makes the disagreement productive rather than circular.

What to Look for in Your Organization

If the transformation is moving more slowly than it should, the diagnostic is rarely about individual teams. It is about the system connecting them.

Decisions get re-litigated when governance doesn’t define who owns them and what evidence settles them. Discovery gets disconnected from strategy when product teams explore in one direction while executives invest in another because the system was never designed to make those two things visible to each other at the same time. Portfolio decisions stall when the agency to shape the path hasn’t been claimed, and Product and Delivery teams slow down when they are absorbing ambiguity that should have been resolved one layer above.

The organizations that install durable transformation systems design the system deliberately. The decision rights, the evidence flows, the forums, the cadence, and the transparency that makes it structurally difficult for any layer to operate on a different version of reality than the one everyone is navigating by.

The system does not change itself. Governance does.

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.

I’ve spent the last 25 years trying to answer one question: how do you actually get a large, complex organization to deliver software predictably? The question hasn’t changed. The technology has changed. The buzzwords have changed. The funding model has changed. But the underlying problem has been the same one the whole time, and right now it’s wearing a new costume called AI.

So when CIOs ask me what they should be telling their board about AI, I tell them the same thing: don’t tell them about AI. Tell them about the preconditions.

The Pattern I Keep Watching Repeat Itself

If you’ve been following our work for a while, you’ve heard me say that agile fails when the structural preconditions for it to work aren’t in place. We’ve been saying that for almost 20 years. It was true when the new thing was Scrum. It was true when the new thing was DevOps. It was true when the new thing was cloud migration. It’s true again now that the new thing is AI.

The pattern goes like this. A new technology emerges that promises a step-change in business outcomes. Leadership gets excited. Pilots get funded. The pilots produce a couple of demos that look great in a boardroom. The demos don’t scale into the actual business. Six months later the conversation turns to how much the team is learning. 18 months later the initiative quietly gets de-funded and replaced with the next new thing.

I’ve watched that arc play out with every major tech wave in the last 25 years. It’s playing out right now with AI. It will play out next with whatever comes after AI. The pattern is a structure problem.

Why Most AI Pilots Aren’t Scaling

A partner of ours said something to me about a year and a half ago that stuck: the move to AI is going to force digital transformation to become real. He was right. There was a lot of room in the cloud-migration wave for a CIO to spin up some containers, claim victory, and tell the board they were digital. AI doesn’t grant that kind of room. AI either solves a real business problem using your actual data and workflows, or it doesn’t.

Most of them don’t, and the reason is structural. Your AI pilot is sitting in a system that wasn’t designed for it. The data it needs is locked inside a system of record from 30 years ago that runs on a different operating assumption. The workflow it’s supposed to accelerate runs through six teams that don’t share a backlog. The output it produces has to be trusted by an executive whose dashboard is wired into a different governance system entirely. The pilot demo works because the demo conditions are controlled. The production reality isn’t, and the production reality is what your board cares about.

I’ve been saying for a long time that the unit of agile delivery is a complete cross-functional team with a clear backlog producing a working tested increment of the product on a regular cadence, with no dependencies they can’t manage themselves. Teams, backlogs, working tested software. That’s it. That’s the whole frame. Every word in that sentence is doing real work, and every word of it applies just as much to AI as to anything else we’ve ever tried to ship.

If your AI team is six engineers spread across three reporting lines, dependent on a data team in another building, releasing into a workflow they don’t own, against KPIs nobody has agreed on, the outcome is predictable. Your AI pilot will behave exactly the way every failed agile pilot has behaved for 20 years. In any useful sense, it’s a structure problem wearing AI clothes.

What I’d Actually Tell Your Board

Here’s what your board needs to hear: we’re going to be predictable.

If I were the CIO, here’s how I’d frame the board conversation. We are going to deliver AI-enabled business outcomes every 90 days, against a small number of capabilities at a time, and we’re going to deliver them predictably. We’re not going to commit to a portfolio of 15 AI use cases on a slide somewhere and then come back in 18 months apologizing for what didn’t ship. We’re going to commit to one capability that we can actually land, ship it, and earn the right to fund the next one with the value we just shipped.

That is a delivery commitment the board can hold us to. It’s the same predictability promise I’ve been trying to get technology organizations to make for 20 years. AI doesn’t change the standard. If anything, AI raises it, because the cost of AI tooling and AI talent makes a slow, unpredictable AI program more financially painful than a slow, unpredictable agile transformation ever was.

The reason this lands at the CIO level is that you’re the one who has to translate the structural reality into board language. Engineering can talk to engineering about modular architecture and complete cross-functional teams. The CFO can talk to the CFO about CapEx and OpEx. You sit in between. You’re the one who has to take “we need to break the dependencies between our systems before AI can scale” and turn it into “we will deliver business outcome X by date Y at confidence level Z.”

That’s a structural conversation, not a tooling conversation. And it’s the conversation our industry has been bad at having for a long time. We tend to want to tell the board about the new thing we bought. The harder, more honest CIO move is to tell the board about the old thing we’re redesigning so the new thing can work, and to commit to a delivery cadence the board can verify against the calendar.

Where to Start

If you take one thing from this post, take this. The structural work and the AI delivery aren’t sequential. They happen inside the same 90 days, against the same capability, by the same team.

Pick one business capability where AI would materially matter. Not five. One. Make it the one you’d most want to win. Then ask three questions about it.

One. Is there a single team that owns this business capability end-to-end, with no external dependencies that they can’t resolve themselves? If not, your first move inside the 90 days is forming that team.

Two. Is the data this AI needs encapsulated in a service that team can call, or is it sitting inside a legacy monolith that has to be touched every time something changes? If the latter, part of the 90 days is extracting and encapsulating just enough of that data for this one capability to work cleanly. Not all of your data. The slice this capability needs.

Three. Does the workflow this AI is meant to accelerate have a clear, measurable business outcome that an executive sponsor will hold their team to? If not, the 90 days include defining that outcome, in operational terms, with the sponsor signed up to it.

By the end of the 90 days, three things are true. The structural preconditions for this capability are in place. The AI is deployed against the capability in production. There is a measurable business outcome that the team and the sponsor agree was hit. That’s your first delivery. That’s what you take to the board at the end of Q1.

Then the next 90 days add the next capability. By the end of year one, you’ve got four capabilities running on the new structural pattern, each with AI compounding on top of it, each with a clean business outcome the board can point to. Most CIOs don’t see this coming. The structural work you did for capability one pays forward into capabilities two and three. The team gets faster. The data layer gets cleaner. The governance model gets more practiced. The cadence becomes the operating rhythm.

That’s a very different story than “we’re not delivering AI this year.” It’s “we’re delivering AI quarterly, against the capabilities that matter, on a cadence you can take to the audit committee.” Same underlying preconditions argument. Very different message in the boardroom.

Most of the CIOs I talk to are already deep into an AI program that doesn’t look like that. The move isn’t to throw it out. The move is to pick the one capability inside it that’s most worth saving, restructure the work around that one, and let the unsalvageable pieces wind down naturally as funding cycles end. Don’t take a year off from AI to prepare. Take 90 days to do one capability right, then prove the pattern repeats.

The firms that figure this out in the next two years won’t be the firms that bought the most AI tools. They’ll be the firms that learned to deliver AI predictably against a small number of capabilities at a time. The rest will spend year three explaining to their boards why the AI bill keeps going up and the business outcomes haven’t moved.

That’s the story. Tell that one.

In my last article, Why Most App Modernizations Fail, I made the case that organizations know they need to modernize but are lacking a framework that removes the ambiguity from the decision making. This article moves us from strategy to practice, walking through how organizations use business capability heatmaps and domain alignment to make deliberate, data-driven, and defensible modernization decisions that delivery business value at every step of the journey.

Breaking Down Silos Through Domain Alignment

Application modernization cannot happen in a silo. Legacy applications in many instances can be considered a bowl of spaghetti when pulling one noodle somehow breaks four in the process. By understanding domains and aligning technical teams to those domains, organizations create a cross-functional structure that ensures modernization efforts consider the impact on various departments and promote an integrated approach. This alignment also follows Conway’s Law [1] where organizations design systems that mirror their internal communication structures, turning an organizational reality into a deliberate design advantage.

Delivering the Value

To begin delivering value during application modernization, organizations must have an established business capability model with corresponding heatmap. In this article, I will not be describing how to establish the model, nor will I be describing how to create the needed heatmap. It is also assumed that a definition of business capability is not needed though one can reference the article Organizing Around Business Capabilities. This article will describe how using capabilities focuses strategic refactoring decision making on changes that increase value rather than simply rebuilding every application.

Precursors to a capabilities-driven application modernization

The first step is to recognize that not all business capabilities have the same significance.  Business capabilities are stratified into three layers [2]

• Strategic – direction setting or typical executive focal points
• Core – customer facing or what an organization does to thrive in the marketplace
• Supporting – what the organization must have to function as a business

For those not as familiar with business architecture, a similar concept can be found with Martin Fowler [3]. He describes how to determine if IT is strategic or utility. Technology is strategic where it contributes or supports capabilities that differentiate the organization. As with Strategic and Core business capabilities, if the business value for the technology is determined strategic then that is the area one wants to be as good as possible.

The stratification of capabilities and Martin’s concept of IT being strategic or utility are keys to unlocking sound investments. An additional key is to establish a capability-driven organization that contains both technical and business operations into the capabilities. These keys will unlock the next steps in determining how to make sound economic application modernization investments. These steps include:

1. Assess the value, performance, and risk of your capabilities using a capability heatmap
2. Align domains to your capabilities

Asses the value, performance, and risk of your capabilities using a capability heatmap

Since many organizations fail with their application modernization efforts, using data to determine what areas of the organization they should focus on should be standard practice. Those who engage in a business capability assessment will have a clear advantage by having data that shows what the organization should focus on for improvements. In Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders, Whynde Kuehn [4] identifies the business capability assessment as offering ‘a data-based view of business performance, at an aggregate level.’

Assessing the value (strategic importance), performance (people, process, and technology), and risk (flexibility/suitability) of business capabilities is the basis of a capability heatmap. Creation of the heatmap should occur before any decisions around application modernization efforts are made.

Align domains to your capabilities

A domain is the activity or business of the end user [3]. A simple explanation is a domain is equal to a business object which includes its behavior, state transitions, and data associated with an element of a business. It is a specific problem space that a software solution is meant to address. Examples of domains are Product, Market, Work Order, and Customer.

There are a few important distinctions between business capabilities and domains. Business capabilities are described at a higher, more abstract level, and they are non-redundant across the organization. Domains can be redundant across the organization. They participate in one or more bounded contexts that facilitate encapsulation of teams and systems from each other that distinguish the distinct meaning and rules inside and outside the area. For a domain the smaller the boundary the smaller the teams and the more modular the service architecture. Larger boundaries will result in larger teams and more complex or monolithic architecture. In other words, alignment of business capabilities and domains follows Conway’s Law [5] where organizations will design systems that mirror their own internal communication systems.

What happens when domains are redundant across the organization? Does it matter? The short answer is it depends.  Redundancy in domains does not mean there should and will be redundancy in data models. Attempting to unify the redundancies breaks the core principle bounded context and will in effect drive accidental complexity and monolithic coupling. For example, ‘Customer’ can appear in both ‘billing’ and ‘shipping’, but has different attributes in each context (e.g. billing address does not always equal shipping address, etc.).

Eric Evans, in Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) [3], explicitly warns against forcing a single unified model across contexts. Each bounded context owns its own ubiquitous language, meaning “Customer” in billing may carry attributes like payment history and credit status, while “Customer” in shipping cares only about address and delivery preferences. The behavior and attributes should differ because they serve different capabilities. The key is to ensure that the domain has a consistent meaning across all contexts in which it participates, and that when needed attributes from multiple contexts can be combined to fulfill a particular business need.

Sam Newman, in Building Microservices (2nd ed., 2021) [5], reinforces this by describing how shared models across service boundaries create tight coupling — the very problem that bounded contexts are designed to prevent. He recommends tolerating some data duplication across services rather than introducing shared libraries or databases that erode autonomy.

With that said, there are instances where a domain should have the same behavior and attributes across capabilities. Take for example ‘Product’ domain.  It is undesirable for calculation of pricing within the Inventory domain to be different than the calculation of pricing in the e-commerce domain. This would lead not only to teams solving the same problem, perhaps leading to different outcomes but also to increased operational costs when resolving any issues and/or updating the calculations. This is the organizational mirror that Conway’s Law predicts: siloed teams produce siloed, inconsistent implementations of logically shared concepts.

In short, if the behavioral difference has no business justification and exists purely because two teams built the same thing independently; refactoring is warranted, but the target is not necessarily a shared service. Often the right move is to designate one context as authoritative (a published language or open host servicein Evans’ terminology) and have the other consume it through a clearly defined application programming interface (API), rather than collapsing both into one monolith.

When aligning business capabilities and domains, ensure the smallest possible bounded context per domain while also taking into consideration if the redundancy within the domains has a business justification or not is critical.  Otherwise, a system that continues to perpetuate dependencies across the organization is created. If the language of the consumer varies significantly from the authoritative context, one can establish an anti-corruption layer to translate an external model into terms that are more meaningful within the consumer’s bounded context.

Pulling it Together

Nicholas Tune and Jean-Georges Perrin point out ‘To get buy-in from stakeholders and maximize return on investment, you must have a solid understanding of the business outcomes you aim to achieve and clearly articulate how investing in architecture modernization will move the business toward its strategic priorities’. [6]

To do this, leverage business capability and domain heatmap. At the most basic level, the tool visually identifies which capabilities are most critical to improve from a strategic level. The heatmap also indicates the impacts that the strategic decisions will have on the organization. Is the strategy to increase speed of innovation, operation costs, or scalability? Will the strategy impact multiple highly strategic capabilities that all have highly inflexible and are performing below average? What is the current technical debt? The executive will know that a higher level of investment will be needed to improve the capabilities and domains.

Conversely, the heatmap will also show areas that are already performing within the needed objectives and goals. The executive will know that investment in these areas is not wise as it is unnecessary to continually improve on a capability that is already performing at a high level.

Companies who may have a good understanding of their distinctive business capabilities fail to associate them with their domains. Ensuring the alignment between capabilities and domains and their associated technologies improves an organization’s awareness of where they are wasting money on non-strategic, overperforming or adequately performing capabilities. Ultimately this prevents the company from hemorrhaging money on unnecessary application modernization efforts.

This article was originally published in Architecture & Governance Magazine in May 2026.

References

[1] Conway, Melvin E., “How Do Committees Invent?” Datamation, 1968, https://www.melconway.com/Home/Committees_Paper.html.

[2] Business Architecture Guild®, A Guide to the Business Architecture Body of Knowledge®, v 13.0 (BIZBOK® Guide), 2024. Part 2, Section 2.2 & Page 79

[3] Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003.

[4] Kuehn, Whynde. Strategy to Reality: Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders. Morgan Jame Publishing, 2022

[5] Newman, Sam. Building Microservices: Designing Fine-Grained Systems. 2nd ed. Sebastopol, CA: O’Reilly Media, 2021.

[6] Tune, Nick, and Jean-Georges Perrin. Architecture Modernization: Socio-Technical Alignment of Software, Strategy, and Structure. Manning Publications, 2024.

Most Fortune 100 companies aren’t struggling with AI because they lack the right tools or models. They’re struggling because AI fails at the organizational level: fragmented data, misaligned incentives, no clear ownership of outcomes, and legacy systems that weren’t designed to feed production AI. It’s these issues that stop promising pilots from scaling into production. Addressing these organizational issues is key to realizing the potential of AI. This article explains why your pilots aren’t scaling and the five conditions that enable AI to reach meaningful production scale.

You Don’t Have an AI Problem. You Have a Systems Problem.

When we work with CIOs at large, legacy-heavy enterprises, we hear the same story: a lot of AI-focused activity but not much in production at a meaningful scale.

This is what we call pilot stall. And it’s the root causes have little to do with AI itself.

Pilots are typically initiated in a controlled environment. One where the conditions are created for success, and one that typically doesn’t reflect the operational and technical realities of the organization as a whole. The moment you tried to scale it, you hit the constraints of the legacy systems. Your legacy systems weren’t designed to feed real-time inference, so the “last mile” data problem stalls every deployment. The business units that would benefit from the AI don’t own the model, don’t feel accountable for its performance, and don’t change their processes to take advantage of it. Decision rights, funding flows, and governance processes were designed before AI was a real production constraint. None of these is an AI problem. They’re system problems.

Start with the System, Not the Symptom

Organizations are systems. They produce predictable results based on how they’re designed. If you want different results, you have to change the system’s design, not just its components.

For enterprise AI, this means asking a different set of questions before you reach for a solution:

What is the actual constraint limiting performance? Usually, it’s not the model quality. It’s the data pipeline, the decision-making structure, the incentive model, or the lack of mapping of AI capability to a value stream that produces measurable business outcomes.

What must be true for this to work at scale? AI Transformation succeeds or fails depending on whether the necessary system conditions are in place. What are the prerequisites? What has to be in place before you can build on it?

What does the system produce, and why? If your organization keeps generating pilots that don’t scale, there’s a structural reason. The behavior is an output of the system design. Find the design flaw, not the scapegoat.

Treating AI transformation as systems redesign rather than technology deployment changes what you do, in what order, and who needs to be involved.

The Five Conditions That Move AI to Production

Based on our work with complex, legacy-heavy enterprises, here’s what consistently separates the organizations that make it into production from those that don’t. The shape of the work depends on the type of AI problem and the organization’s maturity. The five conditions below are necessary in most Fortune 100 contexts; how you instantiate them varies.

1. Ruthless portfolio rationalization. Most organizations have too many pilots. Start by focusing on three to five capabilities that are connected to improving KPIs that the CFO is focused on: revenue, cost, customer impact, and cycle time. Everything else is noise until you’ve proven you can drive results in production.

2. Encapsulated capabilities, governed interfaces. Not a central AI team that everyone has to coordinate with. Not another tool. An architecture where each business capability owns its own models, its own data pipelines, and its own production lifecycle, connected through governed interfaces rather than central orchestration. Reducing cross-team dependencies is the prerequisite infrastructure that most organizations skip in their rush to build models.

3. Operating model redesign. Who owns the model in production? Who is accountable when performance degrades? How are cross-functional teams funded for ongoing capability, not one-time projects? These aren’t technology questions. They’re organizational design questions, and they’re the ones that determine whether your AI actually sticks.

4. MLOps and governance built in from the start. Model lifecycle management, monitoring, drift detection, and compliance workflows need to be part of the architecture from day one. Don’t bolt them on after a failed production launch. Governance without infrastructure creates bottlenecks. Infrastructure without governance creates risk.

5. Business-defined success metrics. If your AI program is measured by model accuracy, you’re measuring the wrong thing. The right metrics are end-to-end cycle time, EBITDA impact, cost reduction, and customer experience improvement. When success is defined in business terms, accountability follows naturally.

The LiminalArc Approach to Pilot Stall

Most AI consulting work focuses on the wrong layer: the model, the platform, the use case. The firms that consistently get AI to production at scale work at the systems layer instead, where the production failures actually originate. That’s the work LiminalArc was built for.

We work specifically with Fortune 100 enterprises where the bottleneck is organizational: incentive misalignment, cross-functional coordination failures, legacy architecture constraints, and governance gaps. We diagnose the system before we recommend technology. We install the five conditions and one capability at a time, end-to-end, until production AI delivers measurable ROI. Then we expand to the next capability.

If your pilots aren’t scaling, the firms that can solve that are the ones that treat your organization as the primary variable, not the technology. LiminalArc is built for that work.

Frequently Asked Questions

Why do our AI pilots keep failing to scale?

Pilot failure almost always traces back to organizational and infrastructure factors, not model quality. The most common causes are: no unified data layer, no business owner for the outcome, incentive structures that fund projects rather than capabilities, and operating models not designed for continuous AI deployment.

How long does enterprise AI transformation take?

For Fortune 100 companies with complex legacy infrastructure, realistically, 18-36 months to reach a satisfying ROI at scale. The first 90 days should focus on portfolio rationalization, constraint identification, and foundational architecture. Expect measurable production deployments within six months of starting structured work.

How do we avoid pilot stall?

Pilot stall happens when organizations lack unified platform architecture, MLOps infrastructure, governance frameworks, clear business ownership, or ruthless portfolio rationalization. Install all five conditions within a single capability before you build more pilots elsewhere.

What’s the difference between systems thinking and a technology-first approach?

Technology-first starts with “which model or platform should we use?” Systems thinking starts with “what is the constraint that’s limiting performance?” The questions look similar. The answers and the work required are entirely different.

How do we measure AI ROI?

Measure end-to-end cycle time, EBITDA impact, cost reduction, and customer experience improvement. Model accuracy is a technical metric, not a business metric. Build your business case in the language your CFO and board use: revenue impact, cost avoidance, margin expansion.

What’s the right size of an AI portfolio to start?

Three to five high-priority capabilities, each tied to a measurable value stream, with clear production infrastructure and business ownership. That’s it. Every additional initiative dilutes focus and slows execution until you’ve proven you can scale something.

Work With LiminalArc

If your pilots aren’t scaling, we should talk. Not about which tools you need. About why your system keeps producing the results it’s producing, and what it would take to change that.

Explore our AI Readiness work
Talk to a LiminalArc advisor

LiminalArc helps Fortune 100 enterprises move from AI experimentation to real business value by treating transformation as a systems problem rather than a technology problem.

Application modernization continues to be at the forefront of organizations’ concerns as they struggle to respond to the undeniable acceleration of digital transformation and the ability to respond to rapid changes in the market. According to an October 2025 MarketsandMarkets [1] research report, spending on legacy application modernization is expected to grow from $22.67 billion in 2025 to $51.45 billion in 2031. With the increasing investment in application modernization, it is rather astonishing that research conducted by Wakefield Research [2] showed that 79% of the respondents indicated that their application modernization effort failed. How do organizations know that they are wasting billions of dollars on app modernization, and how do they stop the bleed?

In Examining Capabilities-Driven AI, my colleague Len Greski discussed the impact of a capabilities-driven organization on the AI-enabled business. He asserted that a capabilities-driven approach to AI accelerates the delivery of data products and AI capabilities. In Organizing Around Business Capabilities, we articulated the benefits of this approach, including integrating both technical and business operations into a capability. In this article, I explore how the benefits of a capabilities-driven organization enable organizations to make economically sound investment decisions in application modernization.

Organizations Must Modernize

With market spend expected to exceed $51 billion in 5 years and growing at 5x the 2025 U.S. inflation rate, modernization is clearly a strategic imperative. Four primary drivers of this investment consistently emerge across industries:

1. Unsustainable Technical Debt and Maintenance Costs

Legacy systems accumulate technical debt gradually over time, consuming an ever-growing share of IT budgets just to keep existing systems operational. Surprisingly, once a new application goes into production, it IS a legacy application. This translates into 90% of the cost of your new application occurring after the initial deployment to production [3]. As years pass and original developers move on, even seemingly simple updates become complicated and risky. Tasks that in the past took days can drag on for months. This constant struggle not only drains resources, but it also directly undermines an organization’s competitiveness.

2. Inability to Scale and Adapt to Market Changes

Monolithic and tightly coupled legacy architectures make it difficult to introduce new products, enter new markets, or respond to competitive threats at the pace the modern business environment demands. Organizations with outdated platforms find that their technology constrains rather than enables the business. Meanwhile, competitors who have modernized can quickly try out new ideas and grow their services with ease. The longer you wait to modernize, the further behind your organization falls.

3. Escalating Security and Compliance Risk

Many older systems simply cannot keep up with today’s security threats.  It is often difficult, if not impossible, to update them with the latest protections or to comply with new rules like GDPR, HIPAA, SOC 2, and PCI-DSS. The fallout from a security breach or failing an audit can do way more damage to an organization’s revenue than the upfront investment to modernize. Security isn’t just an IT problem anymore; it’s a business risk that leadership can’t afford to ignore.

4. Degraded User and Customer Experience

Legacy systems typically produce slow, fragile, and poorly integrated experiences for both internal users and external customers. In an era where customer experience is a primary differentiator, organizations running on outdated platforms find it increasingly difficult to meet expectations. On top of poor customer experience, productivity and morale of employees are negatively affected in part due to outdated tools and processes, making it harder to recruit and keep top talent.

Most Modernization Efforts Fail

The 79% failure rate cited by Wakefield Research is disconcerting, but it is not surprising when one examines how most modernization programs are structured. The most common failure modes include:

• Technology-led, not outcome-led: Too often, organizations start with a technology decision ‘we are moving to the cloud’ or ‘we are rewriting in microservices’ ignoring the most important question, what is the business value and what business outcomes the investment is meant to deliver. Without a clear tie to business value, projects lose stakeholder support and direction.
• Boiling the ocean: Organizations attempt to modernize everything at once, resulting in multi-year programs that are too complex to govern, too expensive to sustain, and too slow to deliver value. By the time they complete, the business and market has moved on.
• Siloed execution: Technology teams modernize applications in isolation, without sufficient understanding of upstream and downstream business dependencies. This is the ‘bowl of spaghetti’ problem — pulling one noodle breaks four others — and it leads to regressions, delays, and costly rework.
• Neglecting the organizational dimension: Technology transformation without corresponding changes to team structures, processes, and governance rarely sticks. Conway’s Law tells us that systems mirror the communication structures of the organizations that build them, and if we change the software to conflict with the communication structure, the changes will eventually be reverted.
• Lack of prioritization frameworks: Without a structured way to evaluate which systems to modernize and in what order, organizations default to the loudest voice in the room, the most visible pain point, or political priorities ignoring the strategic value.

As an antidote to the failure patterns, consider a capabilities-driven approach.  Use the organization business capabilities to anchor the modernization decisions to the most valuable business outcomes ensuring cross-functional alignment and enabling prioritized roadmap that based on valuable business outcomes and sustainable technical architecture.

How a Capabilities-Driven Approach Improves Success Rates

A capabilities-driven approach addresses the root causes of modernization failure by shifting the conversation from technology replacement to business outcome enablement. Rather than asking ‘what do we need to rebuild?’, it asks ‘what capabilities do we need to perform better — and which of those are truly differentiating?’ This reframing has profound implications for how programs are structured, governed, and executed.

Anchoring Decisions to Business Value

Nicholas Tune and Jean-Georges Perrin point out that ‘to get buy-in from stakeholders and maximize return on investment, you must have a solid understanding of the business outcomes you aim to achieve and clearly articulate how investing in architecture modernization will move the business toward its strategic priorities.’ [4] A capabilities framework provides exactly this — a structured language for connecting technology investment to strategic intent, ensuring that modernization efforts remain legible and defensible to executive stakeholders throughout the program lifecycle, including the cost to operate the capability.

Enabling Value Driven Prioritized Roadmap

Not all modernization investments are equal, and not all capabilities deserve the same level of investment. Martin Fowler describes how to determine whether IT is strategic or utility: IT is strategic if it contributes to or supports capabilities that differentiate the organization. [4] This insight, combined with the business capability stratification model [5] provides a powerful framework for prioritization.

• Strategic – direction setting or typical executive focal points
• Core – customer facing or what an organization does to thrive in the marketplace
• Supporting – what the organization must have to function as a business

Organizations that apply this lens can make confident decisions: invest heavily in modernizing Strategic and Core capabilities where performance gaps exist, and adopt pragmatic, cost-efficient approaches for Supporting capabilities where “good enough” is genuinely good enough. This avoids the costly trap of gold-plating commodity systems while under-investing in differentiated ones.

Reducing Risk Through Incremental Delivery

By identifying capability boundaries and aligning domains accordingly, organizations can decompose large, risky modernization programs into smaller, independently deliverable increments. Each increment delivers measurable business value, maintains organizational support, and reduces the blast radius of any individual failure. This is the opposite of the ‘big bang’ rewrite, and it is why capability-aligned approaches consistently outperform technology-first ones.

The Path Forward

A capabilities-driven approach to application modernization is not a silver bullet, but it is a proven antidote to the failure patterns that have plagued the industry. When organizations use business value to anchor their investment decisions, apply roadmap prioritization, and deliver incrementally, they can break the cycle of costly, failed transformations. The question is no longer whether to modernize; the competitive imperatives are clear, but how to modernize in a way that is economically sound and strategically aligned. In part 2 – Capabilities-Driven Application Modernization Delivery: Business Value at Every Step, we will move from framework to practice: exploring the concrete steps organizations can take to implement a capabilities-driven modernization program and deliver measurable results.

This article was originally published in Architecture & Governance Magazine in May 2026.

References

[1] Application Modernization Services by Service Type (Cloud Application Migration, Applications Re-Platforming, Post Modernization), Application Type (Legacy, Cloud-hosted, Cloud-native) – Global Forecast to 2031. Retrieved March 2, 2026.

[2] Wakefield Research. (n.d.). Why app modernization projects fail. vFunction. https://vfunction.com/resources/report-wakefield-why-app-modernization-projects-fail/

[3] Tornhill, Adam. Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs. Pragmatic Bookshelf, 2^nd ed, 2024

[4] Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional, 2003.

[5] Business Architecture Guild®, A Guide to the Business Architecture Body of Knowledge®, v 13.0 (BIZBOK® Guide), 2024. Part 2, Section 2.2 & Page 79

Twenty-five years of change in the cost structure of technology created a minefield of risk as executives fund software application development, regardless of whether the software is sold or leased to customers or developed for internal use. Conflicting pressures lead to one breakthrough solution: Stop arguing about CapEx versus OpEx. Fund the next increment with the value you just shipped.

An Historical Perspective

Organizations have treated software applications as capital assets since the 1950s, based on early go to market models for computer hardware where the software was included in the price of capitalized hardware. The 1969 U.S. antitrust suit against IBM forced the company to begin charging separately for most software programs. Implementation of the antitrust agreement created an independent software industry as IBM and other companies separated their hardware and software businesses.

As software became a separate entity from hardware, companies relied on existing accounting standards to decide how to treat software expenses. During the 1970s the Federal Accounting Standards Board’s guidance about research and development (including software) was very conservative – costs were to be expensed as they occurred. Beyond R&D the standards were unclear, leading to a diversity of accounting treatment of the expenses to build software for sale or in-house use.

The accounting environment changed significantly with the 1985 introduction of SFAS 86, which allowed capitalization of software development costs for computer software to be sold, leased or marketed after “technological feasibility” was established [1]. Guidance for internal use software took another decade to emerge, eventually articulated in the Association of International Certified Public Accountants statement of position (SOP) 980-1, and later codified as ASC 350-40. [2] The AICPA took a three-stage position on expense vs. capitalization, where preliminary planning and operations are expensed, but application development post-planning may be capitalized.

The goal of these changes was to more effectively align the costs of building software with the benefits generated over the software’s useful life. However, life, for technology executives, was about to get a lot more complicated.

Cloud, SaaS, and Agile Exert Pressure on OpEx Budgets

Cloud computing, an infrastructure model that allows companies to pay for computing as they use it rather than making large up-front purchases of capital assets, had relatively minor impact on budgets between 2006 and 2014.  At the time, cloud consumed a small proportion of IT budgets, usually less than 15% for most enterprises. By 2020, enterprise spending on cloud infrastructure ($130 billion) surpassed spending on data center hardware and software ($90 billion) for the first time. [3] More recently, enterprise spend on cloud as a percentage of IT budgets has grown to as much as 30 – 50% of total IT spend, with Gartner pegging it at 47% in a 2024 research article. [4]

Bottom line: Subscription-based infrastructure moved roughly half of IT spend from the balance sheet to the income statement.

The net effect of these structural changes in the finances of IT is increased scrutiny on infrastructure costs, as the immediacy and variability of cloud spend (often driven by factors outside the IT department’s control) require a different form of financial management than the typical 5 to 7-year capital asset planning, purchase and depreciation cycle.

SaaS Follows the Same Cost Pattern as Cloud

A similar storyline emerged with Software as a Service (SaaS), with Concur (1993), NetSuite (1998) and Salesforce (1999) challenging the traditional way that software was purchased and consumed by companies. The key innovation was a multi-tenant architecture that would enable multiple customers’ workloads to be managed by a single instance of the application. Multi-tenancy was further enabled by cloud computing, as SaaS vendors could build their applications on highly scalable / pay per use cloud infrastructure. Together, these innovations reduced the cost per customer of SaaS applications from $12,000 – 18,000 annually to under $2,000 as of 2026. [5]

That said, as SaaS usage grew, IT departments began to experience the same capex to opex cost migration challenge they experienced with cloud computing. A 2024 Gartner article, Software and SaaS Contracts: New Negotiation Tactics for CIOs, asserted that companies spend as much as 29% of their IT budgets on SaaS and software, with price increases as high as 30%. [6]

Capex: The IT Budget Relief Valve?

If cloud charges consume 47% of the typical IT budget and SaaS / purchased software claims another 29%, that leaves only 24% to fund everything else. Unfortunately, overall personnel costs are running at 35% of total IT spend [7], leaving many IT departments over budget by 900 basis points.

How might a CIO relieve this form of budget pressure? An obvious approach would be to capitalize enough application development labor to reduce operational spending by 900 – 1,000 basis points. I have observed multiple companies address short-term budget challenges in this manner, but after three or four years of increasing labor capitalization to meet an OpEx target, CIOs find themselves squeezed between the rock of the operating expense budget and the hard place of the amortization schedule.

The Straw that Breaks the Camel’s Back: Accounting for Agile Development

Earlier we described how the American Institute of Certified Public Accountants codified an accounting standard for software development into ASC 350-40. It took a stage-based approach, where capitalization is only permissible during the second, “application development” stage. This stage occurs after preliminary planning but before the initial production deployment to customers or end users.

The theory is that work organized in an agile manner can be capitalized as it goes through the ASC 350-40 stages. The reality, however, is that a high functioning Scrum team passes through all three of these stages during every two-week sprint.

The agile emphasis on frequent delivery of working tested product becomes an accounting nightmare when the organization tries to capitalize the expenses. Companies take three major approaches to capitalization, each of which has significant implications for audit defensibility and operational cost.

Approach	Description
Story Level Tagging	Each ticket marked as new development vs. maintenance at story refinement. Pros: Highest audit defensibility Cons: Creates the heaviest process overhead and associated team friction.
Epic Mapping	Capitalize by epic or initiative, not feature or story. Attempts to balance audit rigor with impact to team velocity. Pros: Moderate audit defensibility Cons: Less labor intensive than story level tagging
Percentage Survey	Conduct quarterly surveys of engineering activity to capitalize a blanket percentage of engineering cost. Pros: Least effort required Cons: Least defensible in an audit

n current practice the trend is clear: as firms implement continuous delivery, software capitalization rates are falling. Direct expensing of software development costs simultaneously reduces non-value adding labor and audit risk.

The Breakthrough Solution: Earn the Right to Invest Again

What does “earning the right to invest again” look like? It consists of three steps, including:

1) Ship a thin slice	Working with business partners, identify the smallest unit of value that someone will pay for or measurably reduce cost – targeted in 30 to 60-day cycles.
2) Monetize the slice	Tie revenue, cost reductions, or a binding usage metric to the release. If the value is an increase in revenue, add the slice’s value to the firm’s revenue plan. If it is a cost reduction, cut the relevant labor and/or materials budgets accordingly to force monetization of the savings.
3) Fund the next tranche	Board or Portfolio-level executive approval for next scope of work releases per verified outcomes, not an annual spending plan. Align units of funding with value streams or products.

This approach reframes accounting treatment of application development as a second-order concern, that is, it shifts the conversation from accounting treatment to accountability for value generation.

AI-enabled Software Development: Tilting the Scales towards OpEx

AI-enabled software development is reducing the cycle time and cost of producing working tested product. For example, survey respondents in Google’s 2025 DORA report indicated that more than 80% of respondents reported that AI has increased their productivity. [8] An MIT study of almost 5,000 software developers at Microsoft, Accenture and an anonymous Fortune 100 manufacturer resulted in a 26% increase in the weekly number of tasks completed by users of Github Copilot relative to developers who weren’t using the tool. [9]

When the time it takes to obtain an increment of end user value is measured in days as opposed to quarters, the effort to capitalize a “project” no longer represents the reality of how software is built and deployed.   In this situation the appropriate unit of accounting is an experiment or investment hypothesis, and therefore the correct unit of funding becomes the business outcome.

Furthermore, AI-enabled software development introduces new categories of spending such as AI tool usage charges, content storage in vector databases, and code analysis infrastructure that are all inherently operational in nature because they are not compiled into the “created asset.” The accounting treatment for these items is consistently Opex.

Applying a Strategic Lens

Given the above conditions, the main question about software application for C-suite leaders is no longer “what can we capitalize?” but rather “how do we obtain value most quickly?” A second question, almost as important as the first, is “what funding model keeps us honest about cost and risk?”

A delivery approach that delivers working tested product to customers or end users in 30 to 60-day cycles will generate value more rapidly than one driven by annual planning cycles. A product-focused funding model that considers the useful life of the product is more aligned with reality than a project-focused one [10].  A funding model that explicitly accounts for uncertainty of value will also be biased toward frequent delivery cycles.

The idea of uncertainty of value (described in Kersten 2018) can be combined with the accounting treatment for the useful life of an asset to establish a 2×2 framework for funding decisions as follows.

Experiment	Short life & unproven value When both the useful life and business case are open questions, spend as little as it takes to answer them. Run these as clearly bounded pilots – a fixed dollar spend limit, a defined decision date, and written kill criteria the sponsor agrees to prior to the start of work. The result or output is an answered business question, not a running system.
Expense & Measure	Long life & unproven value When the software is likely to be around for years but the business case is uncertain, develop it as a measured expense rather than a capitalized asset. Book the costs to operating expense, include instrumentation to prove value, and let the evidence decide whether the work earns its keep as a capitalized asset or gets wound down. This is where most strategic ‘platform’ bets begin before they become infrastructure.
Subscribe	Short life & clear value When value is clear but the underlying technology evolves faster than it can be amortized, attempt to rent rather than owning it. Treat these workloads as operating expenses from day one, subscribe to a managed service, and redirect the organization’s engineering capacity on problems the market doesn’t already solve for you. The failure model is “sentimental” – keeping a custom stack alive long after the build versus buy math has flipped to favor “buy”.
Capitalize	Long life & clear value This is the textbook ASC 350-40 candidate – past a preliminary scope phase, has defined users, a demonstrable revenue or cost-savings path. Capitalize application development costs and amortize them across the expected life of the resulting asset. Core platform services, billing, identity management, and foundational infrastructure on which other value streams depend belong here. Highly regulated industries may require a higher capitalization rate for compliance. The leadership challenge is being honest about when a project clears this bar.

The pattern is that leaders should capitalize what is clearly durable. Expense what is honestly uncertain. Fund what can pay for itself. Let the feedback loop – ship, measure, learn, invest – set the pace of everything else.

Beyond the pattern, we recognize that some industries are more highly regulated than others, and these sectors may require more extensive capitalization for compliance. That said, the 90-day cycle for delivery of value is valuable regardless of the accounting treatment of an increment of value.

Moving Forward

The new economics of software development dictate that the sharpest leaders have stopped optimizing the accounting treatment. Instead, they optimize the feedback loop. If this article has provoked fresh thinking about your capital and expense budgets, consider taking the following actions within the next 90 days.

1. Review your capitalization rate
   Measure the percentage of spend that is capitalized. If your organization uses agile development and your capex rate is above industry medians, you have an audit risk and transparency problem.
2. Fund value streams or products, not projects
   Replace annual project capital expenditures with outcome-gated envelopes lasting no longer than 90 days. Reward shipping a slice and monetizing it, not completing work breakdown structure items in a plan.
3. Instrument every release
   No release goes live without a revenue, cost, or usage metric attached to it. This is essential to the monetize-to-fund loop. It also aligns with the measurement guidance provided in The Emperor’s (not so) New Clothes: the scam of corporate performance frameworks and what to do about it.
4. Pre-write your AI policy
   Decide in advance how AI-assisted code, model usage and evaluation infrastructure map to capitalization, before your auditors ask.
5. Make FinOps a senior executive role
   The combination of cloud and SaaS spend are the largest controllable IT expense lines. Treat them like cost of goods sold (COGS) with ownership, forecasts, variance analysis, and accountability for results.

 

This article was originally published in Architecture & Governance Magazine in April 2026.

References

[1] Financial Accounting Standards Board (1985) – SFAS 86, retrieved from FASB website on April 17, 2026.

[2] Munter, Paul (1999) – Accounting for Software Development Costs, The CPA Journal, retrieved from cpajournal.com website on April 17, 2026.

[3] Carey, Nolan (2021) – Cloud spending outstrips on-premises investments for the first time, InfoWorld, retrieved from infoworld.com website on April 17, 2026.

[4] Banerjee, Ashish (2024) – Maximize the ROI of Cloud Investments, Gartner, Inc. Document G00816239, published December 4, 2024.

[5] CloudNuro (2026) – A Brief History of SaaS: from ASPs to the Subscription Economy, CloudNuro, retrieved from the cloudnuro.ai website, published January 12, 2026.

[6] Decker, H., Lozada, C., Alexander, M. (2024) – Software and SaaS Contracts: New Negotiation Tactics for CIOs, Gartner Inc., document G00820833, published December 11, 2024.

[7] Stegman, E., Guevara, J., Sharma, A., Mehta, P., Tyagi, P.  (2025) – IT Key Metrics Data 2026: Industry Measures – Executive Summary, Gartner Inc., document G00840319, December 11, 2025.

[8] DeBellis, D., Storer, K., Harvey, N., et. al. (2025) – DORA Report, Google Inc., retrieved from the Google website (login required), published September 23, 2025.

[9] Cui, K., Demirer, M., Jaffe, S., Musolff, L., Peng, S., and Salz, T. (2025) – The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, Massachusetts Institute of Technology, retrieved from the Economics department’s website on April 18, 2026.

[10] Kersten, M. (2018) – Project to Product: how to survive and thrive in the age of digital disruption with the flow framework, Kindle Edition, IT Revolution, Portland OR. 97210

[11] Greski, L. (2026) – The Emperor’s (not so) New Clothes: the scam of corporate performance frameworks and what to do about it, Architecture & Governance Magazine, January 7, 2026, IASA Global, San Antonio TX, 2026.

Most organizations are stuck funding projects — but the best product companies fund teams. In this video, we break down how to shift from a project-based model to a product-led approach using value streams, durable teams, and continuous funding so your business can adapt faster, reduce waste, and deliver better outcomes for customers.

If you’re a CEO, COO, or senior leader trying to modernize how your organization delivers value, this video gives you a practical framework for making the shift — covering everything from mapping your product landscape and organizing around customer jobs, to placing small bets, building feedback loops, and staying aligned to business goals.

Video Transcript

And so currently in a lot of organizations, what happens is we wrap up all those goals and those objectives and the desired outcomes and the timeline into a project. We say, “We’ve got a project, these are what we’re hoping the project’s going to achieve. We’re going to end up building these things. It’s going to cost X amount. It’s going to take Y amount of time to do it. ” And then we set up a bunch of teams around that project and aim to get going with the project as soon as possible. If we’re working a little bit of awards full thing, we might do a lot of discovery, spend a lot of time and design, really understand the requirements, and then we get from discovery into actually starting to build up our first MVP. And then we might think about how to scale from the MVP and start adding all sorts of features in there.

And we go through the whole product life cycle. The challenge with all this is that that project is now in place with a bunch of teams around it and it’s been funded and we get stuck having to follow that maybe for two, three years, five years, even as we’re learning things that might make us want to change. We might want to make trade-offs. We might want to increase the number of teams in it. We might want to split it up or decompose it into two smaller projects, but a lot of the structures that we set up and the way we’ve incentivized people in the system means that we follow down a path that isn’t really open to changing some of the fundamental decisions when we first scoped the project.

And so another way to do this is to think about having … Well, first we need to understand our product landscape and the current sets of products and services that we offer. So I spoke before about that work to understand our customer jobs and the pains and gains. And what we find is you have very distinct areas where it’s these sets of customer jobs that we’re trying to support, and it’s these sets of product services that are going to support those customer jobs. And we might call that this little vertical slice, this little encapsulated value stream where we are going to work and build these sets of product services and they’re going to help these sets of customer jobs. And as much as possible, we want that to be encapsulated away from, say, another vertical slice set around a very different, distinct set of customer jobs that they’re enabling.

And you can have that depending on the scale, huge number of value streams. And this is where you can get a lot of overlap with looking at business architecture and capabilities and how you might look at the landscape of products and services across a whole company. Or if you’re more technically minded, you might look at domain-driven design and do the same thing. But ultimately, we’re trying to encapsulate a particular value proposition here, and we’re trying to say that we want these sets of teams, this set of skillsets, oriented towards resolving these pain points and gains for these users and their particular jobs. Now, it’s not distinct users. It might be the users who want to do X and Y. That’s what these teams are oriented towards. That same set of users might want to do Z over here, and you might have another set of teams helping them with that.

So it’s not customers and distinct customers to every single vertical slice. It’s the actual distinct jobs for a set of customers. Now, having got that landscape and that picture, the way you can approach this is to say, “We are going to fund those sets of teams.” It might be a group of AT people, it might be a portfolio team and two product teams, and then there’s four, five, six, maybe delivery teams in a particular area. That’s the sort of scale we’re looking at often when we’re trying to encapsulate because it’s the right number of people to be able to have the communications, to be able to get really good at solving for that particular set of problems that their users and their jobs they’re trying to achieve what they have. And so we fund that set of teams and they’re durable. They exist, they collaborate, they get really good at understanding their customers there.

We try as much as possible to minimize dependencies of that group of teams with teams working to resolve pain points and create gains for another set of customer jobs. And when we allocate like that, what you do is you try and empower and give agency to that portfolio team to go, “Look, you know what the broad business goals are that we’re trying to achieve. You know what our targets are. You might have some North Star metrics, you might have certain top level revenue that you’re trying to achieve, you might have certain growth you’re trying to achieve or sort of minimal attrition you’re trying to avoid. You’re trying to avoid beyond a certain amount of attrition, et cetera.” But that team, that portfolio team for this slice of the organization knows how many people it has and knows what capacity they have and what they can get done.

And so when they think about the problems that they can solve, they can think about those problems in the right sort of scale of box that they can actually come up with the right sized opportunities and the right bets to invest in. And as much as possible, we’re trying to make those bets really small. For a lot of product organizations, it’s really important that we get to a point of seeing the amount of implicit assumptions. Loads of people have to, every time you join an organization and park on boarding, have to do your unconscious bias type of training and make sure that you don’t have unconscious bias. And one of the important bits there is everybody has unconscious bias. Well, in every organization, we have assumptions. It’s what we have to do to understand the world around us is we have to accept that we are going to make some assumptions because of the sheer complexity of it.

It’s the only way to be effective and move forward. So there are always going to be implicit assumptions, but accepting the risks and accepting that we’ve done sufficient amount of discovery to understand our market and customers, we can select opportunities and think about the experiments and the small bets we can place that we can try and meet quickly, release something, test it with our customers, get something in their hands and see if it actually solved the problems they had or created gains for them and decide, should we do more of that? Did we solve that particular job they were trying to do or at least enough of that and now solve another type of job that they have to get done? Or should we actually make it even more powerful what our product does for them so they can go even more quickly or make even more money from the products and services that we have provided to them?

And so you’re trying to flow these small bets through a portfolio and you’re learning and you’re creating these feedback loops. And now, because you’re funded and you’re funded for this capacity, you can choose to shift where your capacity is oriented. You still are accountable to business outcomes. You still have to make money for the company. So that feedback is all about, are we improving outcomes for our customers and improving outcomes for the business? And within those two big measures of success, you’re making decisions about, are the current thing problems we’re looking to solve going to continue us in the right trajectory? Are we going to keep on making more money and creating the right business outcomes?

 

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.

AI adoption is an investment decision. Like any investment, it needs to be evaluated on its returns, its risks, and its alternatives. The question is not whether AI is impressive. It is whether AI creates measurable value for your organization, and what happens if you do not pursue it.

The Current State of AI in Business

AI has moved past the experimentation phase for many organizations. Companies across industries are deploying AI in production for customer support, code generation, document processing, data analysis, and workflow automation. This is not speculative. It is operational.

What has changed in the last two years:

• Capability. Models can now handle complex reasoning, nuanced language, code generation, and multi-step workflows. The gap between AI output and human output has narrowed for many routine tasks.
• Accessibility. Using AI no longer requires a machine learning team. API-based models can be integrated by any software development team. Pre-built tools handle common use cases out of the box.
• Cost. The cost per task has dropped by orders of magnitude. Tasks that cost dollars per interaction two years ago now cost fractions of a cent.
• Reliability. With proper system design (RAG, guardrails, human oversight), AI systems can meet production reliability standards.

The barrier to entry is lower than it has ever been. This is both an opportunity and a competitive concern.

Where AI Creates Value

AI creates business value in four primary areas: 

1. Reducing Cost Per Task

AI handles routine, repetitive tasks at a fraction of the cost of human labor. This is not about replacing people. It is about redirecting human effort toward work that requires judgment, creativity, and relationship management.

Examples:

• A customer support team handles 5,000 tickets per month. AI resolves 60% of routine inquiries (password resets, order status, FAQ questions) automatically. The team now focuses on complex cases that require human judgment, improving resolution quality while handling higher volume.
• A legal team reviews 500 contracts per quarter. AI extracts key terms, flags anomalies, and generates summaries. Lawyers spend time on analysis and negotiation instead of reading boilerplate.
• A development team uses AI-assisted coding to generate boilerplate, write tests, and handle routine code changes. Developer time shifts toward architecture, design, and complex problem-solving.

2. Accelerating Time to Output

AI compresses the time from question to answer, from request to delivery, from data to insight.

Examples:

• A research analyst takes 4 hours to compile a market analysis from multiple sources. An AI-assisted workflow produces a first draft in 15 minutes, which the analyst refines and validates in an hour.
• A sales team waits 48 hours for a custom proposal. AI generates a first draft from the CRM data and previous proposals in minutes. The sales engineer reviews and customizes in an hour.
• An engineering team takes 2 weeks to onboard a new developer to a codebase. An AI assistant that understands the codebase answers questions and explains patterns immediately, reducing onboarding to days.

3. Unlocking Insights from Existing Data

Most organizations sit on data they cannot use because querying it requires specialized skills or takes too long to be practical.

Examples:

• A company has 10 years of customer support transcripts. AI analyzes them to identify recurring issues, product friction points, and feature requests that no one had the time to surface manually.
• A healthcare provider has thousands of clinical notes. AI extracts structured data, identifies trends, and flags patterns that inform treatment protocols.
• An e-commerce company has millions of product reviews. AI clusters them by topic, sentiment, and actionability, producing insights that drive product roadmap decisions.

4. Creating New Capabilities

AI enables products and services that were not feasible before.

Examples:

• Personalized customer experiences at scale. AI tailors recommendations, communications, and support to individual users in ways that manual approaches cannot match.
• Natural language interfaces to complex systems. Users query databases, configure settings, and generate reports by describing what they want in plain language.
• Automated quality assurance that checks work product against standards, guidelines, and historical patterns.

The Cost of Not Adopting

The business case for AI is not only about the value of adopting. It is also about the cost of not adopting.

Competitive Disadvantage

Organizations that adopt AI effectively are already realizing benefits. Their cost structures are lower, their response times are faster, and their ability to scale is greater. Every month of delay widens the gap.

This is not hypothetical. Companies in customer support, software development, financial services, and healthcare are reporting measurable improvements from AI adoption. Competitors who delay will face a structural disadvantage in cost and speed. 

Talent Expectations

Developers, analysts, and knowledge workers increasingly expect AI tools in their workflow. Organizations that do not provide them will struggle to attract and retain talent. This is already happening in software development, where AI-assisted coding tools have become table stakes for competitive hiring.

Compounding Knowledge

AI adoption is a learning process. Organizations that start now build institutional knowledge about what works, what does not, and how to apply AI effectively in their specific context. This knowledge compounds over time. Organizations that wait will need to learn those same lessons later, against competitors who have already learned them.

Measuring ROI

AI investments should be measured like any other business investment. Here is a framework:

Direct Cost Savings

Measure the cost of performing a task before and after AI:

Metric	Before AI	After AI
Cost per support ticket resolved	$15–25	$2–5 (AI-resolved)
Hours per contract review	4–6 hours	1–2 hours
Time to generate first draft (reports, proposals)	3–8 hours	0.5–1 hour
Developer time on boilerplate code	30–40% of coding time	5–10%

Revenue Impact

Harder to measure directly, but real:

• Faster sales cycle from quicker proposal turnaround
• Higher customer satisfaction from faster support response
• More features shipped per sprint from AI-assisted development
• New products and services enabled by AI capabilities

Implementation Cost

Be honest about the investment required:

• API costs:Predictable, usage-based. Start small and scale.
• Integration effort:Engineering time to integrate AI into existing systems. Typically, 2-8 weeks for an initial use case.
• Training and change management:Time for teams to learn new workflows. Often underestimated.
• Ongoing maintenance:Prompt tuning, RAG pipeline updates, monitoring. Budget for continuous improvement.

Payback Period

For most initial AI implementations, the payback period is measured in weeks to months, not years. A customer support AI that handles 1,000 routine tickets per month at $2 per ticket instead of $20 saves $18,000 per month. If implementation costs $50,000, the payback is under three months.

Practical Adoption Path

Phase 1: Proof of Value (1-2 months)

Pick one use case with clear, measurable impact. Keep scope small. Prove that AI can deliver value in your specific context.

Good first use cases:

• Internal knowledge base Q&A (employees asking questions about company policies, processes, or documentation)
• Customer support triage and routing
• Document summarization or data extraction
• Code review or test generation assistance

Success criteria: Measurable improvement in cost, speed, or quality. User adoption and positive feedback.

Phase 2: Production Deployment (2-4 months)

Harden the proof of concept. Add monitoring, error handling, and feedback loops. Deploy to a broader user base.

Key activities:

• Define quality metrics and monitoring
• Build feedback mechanisms for users to flag issues
• Establish prompt management and version control
• Train users on effective interaction with AI tools

Phase 3: Expansion (4-12 months)

Apply the lessons from the first use case to additional areas. Build internal capability and processes for AI adoption.

Key activities:

• Identify the next 3-5 use cases based on Phase 1 learnings
• Establish an AI governance framework (data handling, model selection, risk management)
• Build or hire AI engineering capability
• Create shared infrastructure (RAG pipelines, prompt libraries, evaluation frameworks)

Phase 4: Strategic Integration (12+ months)

AI becomes part of how the organization operates, not a standalone initiative.

Indicators of maturity:

• AI is considered in product and process design decisions by default
• Teams have the skills and tools to implement AI solutions independently
• AI costs are understood and managed as operational expense
• Feedback loops continuously improve AI system quality

Addressing Common Concerns

AI will replace our workers.

AI augments human capability. It handles routine tasks so people can focus on judgment, creativity, and relationship management. Organizations that adopt AI typically redeploy staff to higher-value work, not reduce headcount. The teams that use AI effectively handle more volume at higher quality, not fewer people doing the same work.

Our data is too sensitive for AI.

Data sensitivity is a real concern with real solutions. Options include:

• On-premises deployment of open-source models (data never leaves your network)
• Enterprise agreements with model providers that include data privacy guarantees
• Architecture that keeps sensitive data out of the model (use AI for reasoning, not data storage)
• Regulated industries (healthcare, finance, legal) are already using AI with appropriate safeguards. The question is not whether it is possible, but how to do it correctly.

We tried AI and it didn’t work.

Early experiments often fail because of unrealistic expectations, poor use case selection, or inadequate system design. Common failure patterns:

• Testing AI on the hardest, most ambiguous tasks instead of starting with clear, routine ones
• Evaluating raw model output instead of building a system (RAG, prompting, guardrails) around it
• Expecting AI to work perfectly without iteration and tuning

The technology has also improved significantly. A use case that failed a year ago might succeed with current models and approaches.

We don’t have the technical expertise.

The barrier to entry has dropped significantly. API-based AI integration is within reach of any development team. Start with pre-built tools and managed services. Build internal expertise through the first project, not before it.

Closing Thoughts

AI adoption is not a technology decision. It is a business decision about competitive positioning, operational efficiency, and organizational capability. The technology is ready. The tooling is accessible. The economics are favorable.

The risk is not that AI will not work. For well-scoped use cases with proper implementation, it demonstrably does. The risk is waiting. Every month of delay is a month competitors are gaining experience, reducing costs, and building capability that compounds over time.

Start small. Prove value on one use case. Measure the results. Then expand.

The organizations that will lead in the next decade are the ones building AI competency now, not the ones that waited for the technology to be perfect. It will never be perfect. It is already good enough to deliver measurable value. The question is whether your organization captures that value or cedes it to competitors who started sooner.

 

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.