How do you handle a stakeholder who keeps changing their mind after sign-off?

Hi Syed,

The right answer depends on what kind of work is involved. In software and data engineering it is quite normal, and usually desirable, that requirements emerge and change over time. A two-week cadence of changes is a very reasonable ask from the customer and there's no reason to push back on that as long as you can deliver value iteratively and continuously. What matters is that you have in place an ongoing system of prioritisation and governance, that stakeholders are able to inspect results and give you feedback and that delivered value is demonstrated and measured.

If the relationship is a contractual one then the contract ought to have terms for managing change and the cost of change. If that is missing, then contract negotiation is implicitly what you and the customer signed-up for. A "fixed" contract really means "we will negotiate later"!

An opinion about "sign-off". Unless the sign-off has some legal force, I prefer to use the phrase "review and approval". With software and tech products it's important to seek ongoing, regular and frequent review and approval. The words "sign-off" connote something more absolute and that works against the idea of having regular review and approval. You don't want to create the impression that approval is a one-time only deal. The best time to sign-off is after the customer is satisfied that work is delivered, tested and proven, not before. For physical product the practicalities may be different of course.

An important question.
I would not treat sign-off as a prohibition on further change, but as the baseline against which every new request must be evaluated.
The key is to make both the individual and cumulative impact on scope, time, cost, risk, and benefits visible, then present clear options to the appropriate decision-maker.
Pushback should not begin only after several changes.
It should be built into the process from the first post-approval request, so that each change becomes an explicit business decision rather than an informal expectation absorbed by the project team.

In this situation, you need to negotiate with your stakeholders about the project timeline.

Your question won't seems to be from software projects. If you want to project timeline intact, you must create a stronger delivery strategy, such as implementing agile practices like Scrum.


By breaking releases into smaller, iterative cycles, any changes that arise mid‑iteration can be deferred to the next cycle rather than disrupting the current one. This approach allows you to deliver planned artifacts smoothly while packaging stakeholder requests into subsequent iterations. In doing so, you maintain the timeline for the requirements already in progress, while preparing the next set of requirements for the upcoming iteration and satisfying your stakeholders need without delays.


Each iteration should ideally span 10–15 business days, ensuring manageable scope, predictable delivery and flexibility to accommodate change without derailing the overall schedule.


Look into agile and Scrum, you will find effective solutions to manage stakeholder expectations, negotiate timelines more easily, and deliver results faster.

Good question, Syed. This is exactly why a formal change control process matters — even small changes should go through the same log and impact assessment, so the cumulative effect on timeline becomes visible early instead of being felt only after a month is lost. When pushing back, I frame it around impact, not the stakeholder's judgment — showing the combined effect on timeline usually gets the point across without it feeling personal.

Educate on the concept of critical path.

Critical path is ruthless math.

Day-for-day slippage.
Hour-by-hour slippage.

Without any additional information, Syed, my personal policy is pragmatism. Every trustworthy project sponsor grasps critical path (learning the easy way), OR they should learn the hard way (eroding the value proposition).

For the project sponsor, is the delay a problem?

As others have said, if your culture is “agile,” you must welcome changing requirements, even late in development. Frequency is the non-negotiable.

Unless your culture is “VUCA is reality" agile, in which case, ambiguity is the non-negotiable. 😊