Why requirement changes are really so expensive

The situation: twelve business areas, requirements changing daily

It was a program management and profitability analysis system. Twelve business areas — orders, cost, profitability, quality and schedules among them — had to come together in one system, with business teams, the PMO and developers working side by side.

In a system shared by many departments, requirements arrive every day, and what was decided yesterday changes today.

The problem: everything one change drags along

On large projects, changes are feared not because of the time it takes to change code. Each change brings a chain of work behind it.

• Analyse the requirement and check its impact.
• Update the design documents.
• Rewrite the test scenarios.
• Release it and update the progress report.

The usual response, and its price

When people do all of this by hand, change is slow and expensive. So requirements get frozen early or blocked with change-request forms — and months later, on launch day, the business says, 'This isn't what we needed.'

The approach: change the question

We changed the question from 'How do we stop changes?' to 'How do we lower the cost of handling one change?'

The answer wasn't more people. We redivided the work: AI agents took on the analysis, documents, tests, code and records that follow a change, and people approved scope and checked results.

The result

Over sixteen weeks we delivered more than 500 requirements. During that period, merged changes were released three times a day at fixed times (as of October 8, 2026).