Last month, a client asked for one small feature. The budget was fine, the timeline was fine, so we approved it quickly. What we missed was that QA needed extra time to test it, and QA was already busy for two more weeks. The change looked "correctly approved," but the project still got delayed because of it.
Now, before approving any change, I ask one simple question: "Who else does this affect that we haven't checked with yet?" This small habit has already saved us from two similar problems.
Has this ever happened to you: a change that looked fine but caused a problem somewhere else?
Similar experience. We received the request, team evaluated after their "okay", management had approved as well. Effort was estimated and approved, schedule delay was acceptable and it was not entirely out of scope, more like a performance measure rather than a new feature implementation.
Problem was the misjudgment of complexity and dependency. Simple hardware change caused delay due to underestimated software effort and completely ignored layout effort. It was also unavoidable because of weak requirements and specifications. This is very common in small, old companies. Many processes are not formally defined. Therefore, this experience was also a good process improvement topic later. Saving Changes...
We agreed to add one extra field to a registration form. Two days of development, nobody blinked. What nobody thought about was everything sitting downstream of that form: the user guide, the screenshots in the training deck, the translations into two other languages, and a training session already booked with sixty people. The build finished on time. The launch slipped three weeks because the documentation and translation work had never been part of the estimate.
What I learned the hard way is that we were estimating the change, not the consequences of the change. The dev effort was right. The impact assessment barely existed.
Your question is a good one. The version I use now is close to it: who has to change something because of this, and who finds out too late? I also ask the person requesting the change to name the affected teams themselves rather than guessing on their behalf, because they usually know one dependency I don't.
The other habit that helped, echoing Bahadirhan's point, is treating capacity as part of the approval and not just cost and schedule. Two days of work means nothing if the only person who can do those two days is booked for a month. A change board that looks only at budget and dates will keep approving things the organization has no room to absorb. Saving Changes...
One example was when a change had been fully approved by stakeholders, reviewed through the change management process, and accepted by the engineering teams. The planned implementation timeline was one week. However, shortly after approval, a high-priority production issue required immediate attention. The engineering team had to shift their focus to resolving the production incident, which delayed the planned development and testing activities. As a result, the change was delayed by more than three weeks, and the late delivery impacted the UAT schedule and overall project timeline.
In another instance, a downstream application was unknowingly missed during the initial impact analysis. The issue was only discovered after the change had been deployed to the integration environment. This revealed additional dependencies and new business requirements that had to be analyzed, prioritized and developed to mitigate the downstream impact. Although the original change had already been approved, the newly identified work delayed the implementation by nearly a month. Having teams work on competing priorities or applications having dependencies or there could be more reasons when approved change cannot be implemented and the following consequences need to be addressed and acted upon based on the situation. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
An important reflection. I would add one further perspective. The issue is often not that a change was approved too quickly, but that its broader consequences were not sufficiently visible when the decision was made. Even small changes can activate hidden dependencies, capacity constraints and competing priorities elsewhere in the project. Effective change management therefore depends not only on asking who else might be affected, but on preserving the organizational conditions that make those interdependencies visible before approval. That is what turns change approval into informed decision-making rather than procedural compliance. Saving Changes...
I think this discussion highlights an important distinction: approving a change is not the same as understanding its systemic impact.
Most change processes do a good job evaluating scope, cost, and schedule. What they often miss is the impact on organizational capacity, operational readiness, knowledge transfer, documentation, training, support, or even other ongoing initiatives. One practice that has helped me is to complement the impact assessment with a simple question: "What assumptions are we making about this change, and what happens if any of them are wrong?" Hidden assumptions are often where hidden dependencies live.
In the end, successful change management is less about controlling changes and more about understanding the system in which those changes will operate. Saving Changes...
Yes, of course, many times I've experienced the situation that, having a small change approved, it becomes a large delay for the entire project.
To avoid this, it's important to follow a change control process. After submitting a change its impact should be analyzed to later pass to a review stage. If approved, the next step is to implement the change, document it, and close the process. Saving Changes...
Community Champion
