Rarely do projects go exactly as planned: new market insights appear, business priorities change, and user feedback arrives in the middle of a sprint. And suddenly what seemed like a well-defined scope becomes something very different. As change can sometimes fuel better products, it can also quietly erode the budget.
There is compelling evidence: research by Standish Group found that only 31% of projects completed between 2020 and 2024 were considered successful, meaning that they were delivered on time, on budget, and met expectations.
In fact, the researchers conclude that these issues often stem from estimation errors and uncontrolled scope creep, which gradually expand the original project plan and put additional pressure on timelines and budgets.
Other studies confirm similar risks. According to Bent Flyvbjerg and Dan Gardner’s book “How Big Things Get Done,” around 27% of projects exceed their budgets, with 17% experiencing extreme overruns of about 200% over budget and 70% over schedule.
To move from statistics to practice, we asked Alexey Shinkarev, Engineering Manager at Bamboo Agile, to elaborate on the topic and share approaches to managing changing requirements without breaking the budget.
Alexey Shinkarev
Alexey is an engineering manager with 18 years of software development experience. He specializes in web applications built with JavaScript, TypeScript, and Node.js, and combines hands-on backend development with leadership of cross‑functional teams. At Bamboo Agile, Alexey has helped establish development processes across a wide range of products – from internal R&D initiatives to global client projects with strict deadlines and budgets.
Below are Alexey’s insights, grounded in both evidence and experience.
Why сhanging requirements become a budget problem
Let’s start with the classic disconnect. A client asks for a change that looks like a “five-minute fix”, but it’s a two-day headache in the code. What non-obvious factors do clients typically underestimate?
Yes, it is quite a classic situation. From a client’s or stakeholder’s point of view, a change might often look quick and insignificant. Most of the time, they simply don’t have sufficient technical expertise to realistically assess the scope of that change.
In fact, what seems harmless on the surface can trigger deeper consequences. A small request may require architectural changes, work on legacy code, or modifications in some core parts of the system. Quite often, these changes are also tied to integrations with third-party systems, which adds another layer of complexity and risk.
There are lots of real-life examples of “small” changes we sometimes face. For instance, “just adding one field to a form” can turn into one or two weeks of work when that field affects business logic that is tied to third-party integrations.
“Slightly changing verification rules for one client” can eventually lead to reworking the entire verification module because, in the initial scope, we agreed to apply the same rules for everyone, without the possibility of customization. And verification itself is usually tied to a third-party integration as well.
Or “changing the order of screens in a form.” If this form is large and involves complex validation logic on both the internal and external interfaces, this may lead to even an additional month of development.
Looking back at projects that went south, can you name the top 3-5 behaviors or requests from a client that most often lead to scope creep and budget overrun?
Actually, projects that went off track rarely failed because of one single decision. More often, it was a pattern of everyday behaviors that slowly but steadily pushed scope and budget beyond control.
In my experience, the most common ones include:
- Lack of clear priorities, when there is an endless stream of “small changes,” all treated as equally important.
- Requests for changes without acknowledging that even minor adjustments affect timelines or budget.
- Changes discussed in meetings but never documented anywhere.
- New stakeholders suddenly appearing mid-project and influencing the product logic or decisions.
- Attempts to push changes when deadlines are already tight and the release is approaching.
How to make decisions about changes without losing control
When those red flags start appearing, usually in the form of a “great new idea” mid-build, how do you help a client figure out if it’s a “must-have” for launch or just a distraction?
In most cases, there are agreed timelines and a budget within which the team is expected to deliver what was initially discussed. Ideally, all of this should be clearly documented upfront.
When new ideas come up during the development process, the first step is to remind everyone what the original agreements were.
Then you clearly explain what these new changes can actually lead to. It is important to translate them into specific consequences, such as how they will affect deadlines, how they will affect the budget, and what will need to be changed or postponed as a result.
Once the discussion is framed this way, things usually fall into place. The idea either proves to be a real must-have worth the trade-offs, or it becomes clear that it can wait.
Having said that, I don’t see this as contradicting the Agile Manifesto, for example, which encourages welcoming changes even late in development. But in practice, we almost always work within fixed deadlines and a strict budget.
So, I personally don’t hold a position against accepting changes since they are inevitable in every project. But I do have a firm principle: changes should not cause loss to either party. Whoever brings a change needs to understand its impact. That is my main responsibility as an engineering manager.
Therefore, we always recommend evaluating changes as business decisions, not feature wishlists. In practice, we look at three dimensions:
- First, business value and risk. Some changes are non-negotiable. For example, regulatory or compliance updates, or changes that directly protect revenue. Others may improve usability or convenience but have no material impact if postponed. The key question is always what happens if we don’t implement this change.
- Second, implementation effort. A seemingly small request can hide significant architectural impact, while a larger idea may be relatively isolated. Understanding the real effort helps avoid underestimating cost and delivery risk.
- Third, feasibility in terms of budget and deadlines. Even high-value changes need to fit within realistic constraints. If they don’t, the discussion should shift to re-scoping, phasing, or moving the change to a later stage.
Theory aside, reality often tests these principles in uncomfortable ways. Tell us the wildest examples of a project where the client’s requirements kept shifting, and what were the results.
I have an example, but it isn’t wild, since many startup founders experience it. There is one relatively small project which, to this day, still hasn’t moved beyond the beta stage and hasn’t started generating revenue.
The team kept introducing improvements and refinements over and over again. The idea of making it better kept winning over the need to actually launch.
It was only recently that we finally managed to make the decision to introduce the product to the world and move on. By that point, a lot of time had already been invested without confirming whether the product would reach market fit.
What’s the strangest or most unusual change request you’ve ever had, and how did the team adapt?
I wouldn’t say it was unusual in a creative way, but there was one case that was definitely strange and rather painful. It was the start of a large web project that involved very complex custom frontend logic. After receiving approval from the client, the team prepared the design and started implementing this logic.
After about two months of work, the client came back and said that they had decided that everything should work completely differently. They insisted that almost everything needed to be rebuilt from scratch.
As a result, we had to urgently travel to the other side of the world to get together, discuss everything, and agree on how the system should actually work.
It’s not just new ideas that hurt; it’s the pauses. How do you handle a project that’s stalling and burning budget, because the client is stuck on a requirement decision? Can you also show how setting decision deadlines helped avoid wasted time?
Lately, we’ve been trying not to keep teams idle on projects that are paused for one reason or another. With this approach, the budget is not spent on downtime, and engineers almost always have tasks from other projects that were previously postponed due to higher priorities.
It’s probably worth saying that it’s also crucial to set clear deadlines for when requirements need to be finalized, since timelines are usually built based on initial agreements. Those agreements typically highlight specific dates or calendar weeks by which requirements are expected to be ready.
Can you give an example of a project where involving the right stakeholders avoided conflicts or delays? How should clients decide who needs to be consulted before approving changes?
I’ll answer this differently. In many cases, the solution is not so much about involving the right people on the client’s side but about managing expectations properly on our side.
The most important part is catching that subtle understanding of what the client actually needs (besides what is being requested at the moment) and then aligning the entire development process around that.
Documentation is the part everyone hates, but it’s a lifesaver. Do you agree that a simple “Decision Log” can actually save a project from a total budget meltdown?
I can’t recall such a dramatic case. But in practice, having a clear record of decisions, who made them, and when, makes life much easier when disputes arise or when you need to defend your approach.
Atlassian highlights that when teams don’t have recorded plans, meeting summaries, workflows, or decision notes from previous efforts, new teams often feel like they’re “closing their eyes and throwing a dart at a board” while trying to guess how to proceed. This is exactly the kind of situation that leads to rework and wasted time and budget. Atlassian also states that only about 4% of organizations say they always document their processes. It seems that consistent documentation is more the exception than the rule so far.
What makes projects finish on time and on budget
Sometimes the best way to save a budget is to say “No.” Have you ever had to kill a client’s favorite idea for the sake of the product? Tell us this story.
Honestly, this happens at every stage and in almost every project. Usually, these “favorite ideas” collide with timelines or budget constraints.
The key isn’t just saying no. Instead, it makes sense to explain why an idea can’t work and offer alternatives where possible. Of course, there’s always a risk of negative reactions, but in each case, the goal is to find some form of compromise. In short, it’s all about managing expectations.
Thinking of the projects that actually finished on time and on budget – what was the one specific habit those clients had that made the difference?
Almost always, this is not the merit of one particular person on either side. First and foremost, timely delivery is a team effort. The success of the project lies in the work of all team members: competent project management and technical specialists, as well as a responsible client with a structured approach.
Can you explain what a “change management framework” actually looks like at Bamboo Agile?
We try not to make invisible changes. On the contrary, we make sure that every request is recorded in one form or another, depending on the project.
Sometimes that’s a task directly in the backlog. Other times, it’s a document with ideas, requests, or proposed changes. Accordingly, all these changes need to be described, evaluated, prioritized, and planned if necessary.
And only after the final agreement are the changes handed over for implementation.
If you could hand every new client a “3-rule cheat sheet” for requesting changes without ruining the project, what would those rules be?
If I could give every new client such a “cheat sheet,” it would have these three rules.
First, always keep in mind that every idea will almost always affect cost and timelines.
Second, make sure every change is documented. Whether it’s a backlog task or a simple list of requests, having a written record prevents misunderstandings later.
And third, don’t be afraid to accept compromises or alternative solutions if the team suggests them. In this case, being flexible can save both time and budget.
What to remember
Throughout the conversation, Alexey shared practical observations from real projects – situations that teams face every day when requirements begin to change and pressure on budget and deadlines increases. If we reduce all this to a few points that are most useful in practice, then that’s what’s most important:
If managing changing requirements feels harder than it should, it may be worth taking a closer look at how decisions are made, documented, and communicated within your project. If you want to go deeper into this topic in the context of your own project, feel free to reach out.
