Eventually, Ambiguity Is the Decision

Some of the most important decisions in a modernization program happen before anyone calls it a program. They take shape while leaders are still defining the problem, weighing priorities, navigating constraints, and deciding what the organization is actually prepared to change. By the time funding, acquisition, technology, and delivery align around a path forward, the program may already be carrying months, sometimes years, of decisions and assumptions that will shape what happens next.

I’ve spent much of my career in that space, sitting in the room with leaders who know something has to change, but the path forward is still taking shape. There’s no backlog, acquisition strategy, or selected technology yet. What exists is a mission or business problem, executive pressure, aging systems, stakeholder expectations, funding constraints, and usually a deadline.

Then it begins. Analysts and Subject Matter Experts document needs, architects assess the environment, security identifies constraints, acquisition considers vehicles and vendors, finance challenges the business case, executives make decisions, consultants develop alternatives, and vendors demonstrate solutions. Every one of those activities is reasonable on its own.

The problem is what happens between them.

My co-founder John Wright described the other side of this in the first article in this series. He wrote about talented software teams inheriting work that looks ready for execution but still contains as many unresolved questions as answers. As he put it, organizations and delivery teams can begin without “a shared, durable understanding of what they are actually trying to accomplish.”

From the business and client side, the problem starts much earlier.

The Program Starts Long Before We Call It a Program

We tend to mark the beginning of modernization when we fund a program, award a contract, select a platform, or begin delivery. By then, some of the most consequential decisions may already have been made. Someone defined the problem and decided which stakeholders mattered. Alternatives were included or excluded. Assumptions formed around funding, architecture, policy, security, timing, existing systems, and what the organization could realistically change.

These decisions compound, while the context behind them rarely accumulates in the same place. A decision ends up in a slide deck, a requirement in a spreadsheet, architecture somewhere else, and an important assumption in meeting notes. Months later, people may remember what was decided without remembering why.

I’ve found this to be a universal challenge. In 2026, the United States Government Accountability Office (GAO) Office of Inspector General reviewed GAO’s own IT modernization effort. GAO had paid approximately $1 million to develop a five-year modernization plan, then shifted strategies less than 18 months later. The OIG found that “current officials were not fully aware of the decision-making process that led to the transition.” The report emphasized preserving institutional knowledge when significant strategic decisions change.

The technology wasn’t the issue. The requirements and direction were.

Agreement on the Words Is Not Agreement on the Requirement

Requirements expose another version of the same problem.

I believe strongly in starting high-level. Leaders need room to define outcomes without prematurely prescribing a solution, and delivery teams need room to learn. The answer to ambiguity is not hundreds of detailed requirements before we understand the problem.

But there is a big difference between leaving room to learn and leaving room to interpret what we meant.

Consider a seemingly reasonable requirement: The solution must provide leadership with real-time visibility into operational performance.

Most people could agree with that sentence. But ask the business team, executives, architects, acquisition team, vendor, and developers what it means, and the differences surface quickly.

Which leaders?

What constitutes operational performance?

What does “real-time” mean?

What decisions should the information support?

Which systems provide the data?

Those answers can lead to materially different solutions, yet the original requirement can move through reviews, acquisition, a vendor response, and eventually into a backlog with everyone believing they agreed to the same thing.

High-level requirements are not the problem. Assuming high-level agreement means shared understanding is.

Eventually, ambiguity has to become a decision. That is true whether an organization uses Agile, waterfall, DevSecOps, product management, or another delivery framework. Nor should the goal be an exhaustive specification that removes judgment from the delivery team. As John wrote, strong software teams “challenge assumptions, ask uncomfortable questions, test their understanding, and constantly connect what they are building to the business problem it is supposed to solve.”

The goal is simpler to describe and harder to achieve: the people asking for the solution and the people building it need to understand the problem the same way.

Preserving Decisions, Not Just Documents

That challenge is increasingly landing in the middle of the CIO’s world. Deloitte’s 2026 Global Technology Leadership Study found that 79% of 662 senior technology leaders identified driving business outcomes as their top priority. At the same time, technology leaders are being asked to “run, change, protect, and grow” the business while navigating funding and governance structures that have not necessarily kept pace.

Anyone leading a major transformation knows what that looks like. Business priorities, cybersecurity, architecture, data, policy, procurement, budgets, contracts, enterprise platforms, and stakeholder perspectives all influence the path forward.

The answer isn’t another hundred-page requirements document or another governance board. It is making uncertainty visible and decisions durable.

What do we know?

What are we assuming?

What has actually been decided?

Who has the authority to resolve what remains?

And when something changes, what else does it affect?

Organizations already invest heavily in systems for what happens after these questions are answered: project management, software delivery, service management, architecture, collaboration, and increasingly AI-assisted development. The space before execution is much less connected.

AI makes that gap more consequential. We can analyze documents, generate requirements, compare alternatives, create user stories, and produce code faster than ever. But if a high-level requirement supports several reasonable interpretations, AI can just as easily accelerate the wrong one. Speed doesn’t eliminate the need for being on the same page. It increases the cost of getting it wrong.

Before We Hand It Off

John Wright argued that delivery teams need more than requirements. They need the intent behind the work, the decisions that shaped it, the surrounding dependencies, and a common understanding of success.

From the client side, I agree. But we cannot expect the delivery team to reconstruct that understanding after we hand them the work.

Organizations need a durable way to connect strategic intent, stakeholder knowledge, existing systems, constraints, evidence, requirements, and decisions before those inputs become somebody else’s backlog.

That doesn’t mean everything must be known before we begin. It won’t be. It means the client and the team building the solution should understand what has been decided, what remains uncertain, who owns the next decision, and why they are moving in the direction they chose.

That is not overhead before the work starts.

That is the work.