June 07, 2020
When the Client Changes the Plan: Handling Rework
Updated September 2026: this 2020 post described a day of addressing review comments, only for the onsite team to announce the next morning that the client had changed direction and the whole solution needed revamping. I have rewritten it into practical advice for handling a client's change of plan without taking on endless rework.
In June 2020 the delivery lead and I spent a full day on review comments and suggestions from other teams, and sent the updated document back hoping for light edits. On the next call, within minutes, the onsite team told us the client had changed the plan and we would need to rework the entire solution and approach. Before that call ended, I said we would deliver the revised version, and that any changes after it would be owned by the onsite team. They agreed.
Why do clients change direction late?
Because their own decision-makers see the proposal for the first time, budgets move, or a competitor's offer shifts their thinking. Late changes are part of presales work. The aim is not to prevent them but to limit how many times the same document is rebuilt from scratch.
What should you do in the call where the change is announced?
- Listen and take detailed notes rather than reacting. The reasons behind the change shape the rework.
- Ask what stays the same. Parts of the solution usually survive, and naming them early saves time.
- Agree ownership before the call ends, as I did: who does the rework, and who owns any changes after it.
How do you make the ownership agreement stick?
Write it down straight after the call and send it to everyone present. A verbal agreement made in a tense meeting is easy to forget a week later, which is what tends to happen. In my case the onsite team accepted ownership on the call, and it still went the other way afterwards. A short email summary gives you something to point to when the next round of changes arrives at offshore.
How do you protect your team from repeated rework?
Build documents in modules, so a change of approach replaces sections rather than the whole thing. Keep each version, and mark which parts changed and why. When a third or fourth complete revamp is requested, the version history turns "we keep redoing this" into evidence your manager can use to renegotiate the effort or the timeline.
What is the lesson from that morning?
Saying clearly who owns the next round was the right instinct. Putting it in writing the same hour is what would have made it hold.
No comments
Post a Comment