Six Questions to Ask Before You Lock the Scope of Your Modernization Project

TL;DR: Every modernization project has a scoping conversation in its first few weeks, and that conversation is where agentic readiness gets decided by default or by design. This post lays out six diagnostic questions—covering revenue potential, the cost of a future cycle, planned AI investment, data readiness, exception ownership, and system extensibility—that COOs, CTOs, and Heads of Operations can bring into that meeting before scope locks. Each question is paired with what a strong answer unlocks and what a weak answer costs, so the case for expanded scope shows up as a number instead of a preference.

The Argument, Compressed Into a Meeting

Across this series, we've made the case that a legacy modernization project scopes to the problem that forced it—vendor end-of-life, technical debt, a maintenance bill nobody wants to pay anymore—and that scope decision quietly determines whether the resulting system can support AI two years later. We've walked through the five architectural pillars that make a system agent-ready, and the ROI math on building them in now versus retrofitting them after the fact.

None of that changes anything if it doesn't make it into the room where scope gets locked.

That room usually has an agenda built around the forcing function, a timeline, and a budget. Agentic readiness isn't on it unless someone puts it there. The six questions below are designed to do that: they're diagnostic, not rhetorical, and each is designed to produce an answer the group can act on in the same meeting, not a follow-up conversation six months out.

A pattern worth naming before question one: on every one of these, a business buyer and a technical buyer are in the room together, and neither one has the full picture alone. A COO can see the exception cost and the AI initiative on the roadmap. An engineering lead can see whether the data and the workflow logic will support it in practice. The scope decision only gets made correctly when both answers land on the same table.

Question 1: Where's the Revenue, Not Just the Efficiency?

Is there a workflow in the modernization scope that, if instrumented or automated, would move throughput, margin, or revenue, not just reduce headcount hours?

Most scoping conversations default to efficiency framing: fewer manual touches, lower labor cost, faster processing. That framing isn't wrong, but it undersells the workflows where automation changes the top line, not just the cost line. A freight brokerage that can price a load faster than a competitor wins the load. A claims operation that can adjudicate straight-through cases in minutes instead of days changes retention, not just cost per claim.

A strong answer names the specific workflow and the specific lever: which transaction type, which decision point, which number moves and by how much. A weak answer produces an AI initiative aimed at the wrong workflow—efficiency gains banked where revenue and throughput gains were sitting on the table the whole time.

Question 2: What Does the Next Cycle Cost, Compared to This One?

If this project scopes to eliminate only the current forcing function, how long before the same conditions force another modernization? What would that cycle cost against the incremental investment required now?

This is the question that puts a number next to a hypothetical. Most scoping conversations discuss the current project's budget and timeline in detail and never model the next one, even though the pattern—forcing function, minimum viable fix, same constraints resurfacing 18 to 24 months later—is predictable enough to plan around.

A strong answer produces a directional comparison: the incremental cost of building agentic readiness in now against the engineering capacity, budget cycle, and competitive lag a third cycle requires. A weak answer means that comparison never gets made, and the third cycle shows up as a surprise instead of a modeled cost.

Question 3: Does the AI Initiative on Next Year's Roadmap Still Work?

Is there an AI initiative planned for the next 12 to 24 months that depends on data, workflow, or infrastructure this project will touch? If this modernization produces a minimum viable outcome, does that initiative still run?

This is the question that closes the gap Part 3 of this series named directly: 47% of AI funding now originates outside IT (Gartner data), and the leader who committed that budget often isn't in the scoping room. If nobody asks this question explicitly, the modernization project and the AI initiative get scoped as if they're unrelated, until the initiative hits infrastructure that can't carry it.

A strong answer connects the two projects on paper before either one is built: the same data, the same workflows, the same system interfaces, scoped once. A weak answer means the AI initiative discovers the gap after the modernization project is already closed and reopening it means competing for budget from scratch.

Question 4: Is the Data Being Designed, or Migrated As-Is?

Is the data architecture being built with defined ownership, quality standards, and semantic consistency? Or is data moving into the new system in whatever state it's in today, with cleanup pushed to a future project?

Data is the pillar that breaks AI initiatives most often, and it's also the one most likely to get waved through a scoping conversation because migration reads as a technical detail rather than a strategic decision. It isn't. Field definitions that drifted for fifteen years under a brittle legacy application don't fix themselves by moving to a new database. They just move.

A strong answer describes deliberate data engineering, ETL work, and master data management as part of this project's scope (not a nice-to-have, a line item). A weak answer means the data carries its inconsistency into the new environment intact, and the organization discovers that an AI model can't be trusted to act on it only after the model is already built.

Question 5: Who Owns Exceptions Right Now? A System or a Shift?

Does the new system explicitly define exception pathways, or does whoever is on shift still handle them by judgment? What's the current labor cost of manual exception handling in the workflows this project touches?

Exception handling is usually the highest-volume, highest-cost work in an operation, and it's usually the least documented, because it lives in the heads of the people who've been doing it the longest. That's precisely why it's a good diagnostic: if the group can't answer this question with a number, that's evidence the exceptions were never codified in the first place, which means no agent can operate in that workflow regardless of what model sits on top of it.

A strong answer names the labor cost directly and commits to defining exception pathways as part of the current build. A weak answer leaves every exception as a ceiling on automation that this project didn't touch and the next one will have to.

Question 6: Can the System Be Instructed, or Only Operated?

Will the new system expose its logic through API-first architecture, or only through a human interface? If it needed to be instructed by an agent instead of clicked through by a person in two years, could it be?

This question separates a system built for humans from a system built for orchestration. A UI that requires a login and a click path is a wall for an agent, even if the underlying logic is sound. This is also the question most likely to get deferred with "we can build that integration later," which is true and also exactly the deferred cost this series has been tracking since Part 1.

A strong answer means integrations get defined as extensible during this project's build, not bolted on afterward. A weak answer means a future integration project has to open up what could have been designed open from the start, one connected workflow at a time.

What to Do With the Answers

Two of these six questions will produce an honest "we haven't modeled that" or "that's a future project." That's not a failure of the scoping conversation, it's the whole point of asking. Those are the scope gaps with the clearest return on closing them now.

Once identified, put a number on each one: the annual labor cost from Question 5, the cost of a future cycle from Question 2, the value of the AI initiative from Question 3. A scoping conversation that ends with "we should probably do more" doesn't move budget. A scoping conversation that ends with a number attached to each gap is the one that gets scope expanded before the project closes.

The window for this conversation is exactly as wide as the active project. Once the new system goes live, these same six questions still apply. They just get a lot more expensive to answer honestly.

Back to Part 1: Most Legacy Modernization Projects Set Up a Third Cycle. Here's Why.

Back to Part 2: The Five Architectural Decisions That Determine Whether AI Can Run in Your Systems.

Back to Part 3: The Hidden Cost of Minimum Viable Modernization.

Want help running this scoping conversation before your project locks? Book a strategy session with a Sparq architect.

Part 4 of 4 in Sparq's series on Legacy Modernization and Agentic Readiness.

Frequently Asked Questions

Who should be in the room for a legacy modernization project scoping conversation?

At minimum, the business buyer accountable for the modernization budget (often a COO or CTO), the engineering or architecture lead who understands what's technically being rebuilt, and, critically, whoever owns any AI initiative planned for the next 12 to 24 months, even if that person sits outside IT. Question 3 in this article exists specifically because that third stakeholder is often missing from the room.

What if we can't put a precise number on the cost of a future modernization cycle?

Use a range grounded in this project's own numbers. If this modernization is consuming a known amount of engineering capacity and budget, a third cycle addressing the same categories of debt is a reasonable proxy, adjusted for the fact that a delayed cycle usually competes against more accumulated roadmap priorities than this one did.

Do we need to answer all six questions before we can lock modernization scope?

No single question blocks the project. The value is in surfacing which questions produce weak answers, because those are the specific scope gaps worth arguing for, rather than trying to expand scope broadly and unfocused. Two or three well-evidenced gaps make a stronger internal case than a vague push for "more."

How is legacy modernization project scoping different from a standard requirements-gathering session?

Requirements gathering typically starts from the forcing function and asks what's needed to solve it. These six modernization scope questions start from the AI outcomes the organization has already committed to funding and work backward to what the modernization project needs to deliver to support them. It's the same project, scoped from the other direction.