The hidden cost of “small changes” in digital projects

“Can we just make this change?”

It sounds harmless. But, in serious digital projects, this is where the serious cost begins.

Don’t think for a moment we’re saying that change is bad. Good digital projects need change. The problem starts when a project has a defined scope, fixed budget, and fixed timeline, but the scope keeps moving as if nothing else has to move with it. 

This piece is for business leaders who commission digital projects, approve them, and wonder later how a defined scope became a disputed one. 

The fixed-scope promise

A fixed-scope contract exists for one reason. It gives both sides certainty: 

• a defined deliverable, 
• a defined timeline, 
• a defined investment.

Our clients value this. They need to know what they are committing to before they commit. It’s exactly why they pay for the transformation analysis beforehand.

The problem is usually not the contract or lack of analysis, though. The problem is the gap between approving a scope and truly understanding it.

Those are two different moments. And in our experience, they don’t always happen at the same time.

Scope only becomes real when the work does

When a client signs off on a project specification, they are approving an abstraction in the form of a: 

• A document
• A diagram
• A suggested software development process
• A list of features and functions

Then the work starts. Prototypes appear, and interfaces take shape. Workflows become tangible, and a company, for the first time, sees that what they commissioned is not an abstraction.

In this moment, the first true understanding naturally arrives. And it is almost always the moment the requests for “small changes” begin.

• “Can we add a filter here?”
• “Actually, this should connect to other systems, not the ones we listed initially.”

Don’t get us wrong. This is by no means a client problem. It is a natural way people engage with digital work. 

Abstract descriptions of future systems do not activate the same scrutiny as working ones. Psychologists call this the planning fallacy. It’s a well-documented tendency to evaluate plans as ideas (abstractions) rather than as operational realities. 

The project looks simple when it is still an idea. It only starts revealing its real complexity once people can see, test, and react to it.

In other words, by the time a company is fully engaged with what they commissioned, the project is already well underway.

Not all changes. The small ones.

The thing with a change is that each request may genuinely seem minor. That is the illusion. 

In a connected digital system, there is no such thing as a change that touches only itself. 

• A new field affects a data model. 
• A new approval step affects a workflow, a notification, a user role, and potentially a compliance requirement. 
• A new connection to another system opens questions about authentication, data mapping, error handling, and testing.

The visible change is the tip. The rework is the iceberg.

The Standish Group’s CHAOS research, which has tracked software project outcomes for three decades, consistently identifies changing requirements as one of the top factors in project failure. 

PMI’s 2024 Pulse of the Profession confirms the pattern. Only 31% of projects are delivered on time, on budget, and on scope. The remaining 69% are challenged or fail. Scope change is one of the primary contributors to that gap.

Projects without a formal change management process are 35% more likely to exceed costs or miss deadlines, according to 2025 PMI data. The absence of a process is rarely intentional.

It is usually just assumed that small things can be handled informally. The reality is that they are way too important to be handled ad hoc.

Where the cost of small changes hides

It hides in rework.

Work already completed often has to be undone, rebuilt, or retested to accommodate the new requirement. This is almost never visible to a company requesting a digital transformation. 

From the outside, the change looks like a small addition. From the inside, it is a subtraction of progress already made.

It hides in integration.

Digital systems are networks of dependent parts. 

A change in one place creates ripples. Those ripples require analysis, adjustment, and validation across every connected component. The cost does not add. It multiplies.

It hides in timeline compression.

When the scope expands, and deadlines hold (because the client still expects delivery on the original date), the team often absorbs the difference. 

It’s dangerous if the thing that compresses is not the deadline but testing depth or the margin for catching mistakes before they reach production.

It hides in communication overhead.

Every undocumented change creates ambiguity about what was agreed. That ambiguity does not resolve itself. It accumulates in email chains, informal conversations, and eventually in disputes about who said what and when. 

McKinsey’s research on more than 5,400 large IT projects found that they run on average 45% over budget and deliver 56% less value than predicted. Communication and governance failures are consistently among the root causes.

It hides in team momentum.

This one rarely appears in a budget. When a team repeatedly absorbs unplanned changes, it does not just lose time. It loses focus, ownership, and confidence in the plan. The project starts to feel like a moving target. That psychological cost is real, even if it is invisible on a cost sheet.

Why committing to a software analysis is the antidote

We told you about the planning fallacy. It describes the tendency to evaluate a future project based on how we want it to go, rather than how comparable projects have actually gone.

When leaders approve a digital transformation, they are typically imagining a clean version of the work.

The planning fallacy produces the conditions for every problem described in this piece: rushed analysis, scope fights, rework, and late-stage surprises that cost multiples of what early discovery would have.

Committing to a serious analysis process is the antidote to a bias that has derailed far better-resourced projects than yours.

This is exactly what we ask of every client before a single line of code is written.

We ask because we know what will surface. Because we have worked through it so many times: with organizations like Telia, across automotive operations with Toyota Baltic, across public sector services that are now fully digitized and serving hundreds of thousands of citizens daily.

This experience has taught us one consistent lesson: 

The organizations that invest seriously in the analysis phase make better decisions about what to build, what to defer, and what not to fund at all.

The questions we ask during analysis are not for us. We already know why they matter. They are for you. The goal is for your leadership to have a shared, honest picture of reality before committing any resources.

What we are asking for is a short period of structured honesty before a long period of building.

The Net Group view: Clarity is the work

Small changes are not the enemy of a digital project. Unexamined small changes are.

The difference between a project that delivers and one that fails is never a single catastrophic decision. It is a dozen reasonable-sounding changes.Once leaders understand that, they can make better decisions: about what to request, about when to request it, and about what governance to put in place before the first conversation about “just one small thing.”