Nobody wins when a Change Request becomes a blame game

Most change request conversations don't go wrong because of the change itself. They go wrong because someone in the room starts looking for who's to blame.

There is a version of a change request conversation that goes badly almost every time. Someone on the client side looks across the table and says, with barely concealed irritation: "How did we not know about this earlier?" Someone on the consultant side responds defensively, over-explains, and possibly apologises. The CR gets signed, eventually, but the atmosphere has shifted. A considerable amount of trust has quietly left the room.

It does not have to go that way. And in my experience, when it does, the damage is rarely caused by the change request itself. It is caused by how both sides respond to it.

The majority of CRs are not caused by mistakes

Let me say something plainly: in my years of delivering Salesforce projects, I cannot point to a single meaningful implementation that did not produce at least one major change request (and a bunch of smaller ones). Not one project. And the majority of CRs were not caused by anyone forgetting something, or missing something obvious, or failing to ask the right question. They happened because complex projects generate new knowledge as they progress - and new knowledge, almost by definition, changes things.

This is not a consultant (me) making excuses. It is simply how any complex work operates. It just becomes more obvious to everyone when billable money is involved.

The first month of a project, you are working with what everyone collectively knows at that point. Six months in, you know considerably more - about the client's data, their processes, their edge cases, their internal politics, the gap between how they think things work and how things actually work. Some of that knowledge will change the shape of the solution. I don’t think of that as a planning failure. That is the project doing what it is supposed to do.

The more honest framing of a change request is this: a CR is a document that says "we have learned something, and here is the impact of that new knowledge". That framing sounds almost too simple, but it matters. Because it is the opposite of the framing that causes damage, which is "someone made a mistake and now someone is paying for it."

When a genuine mistake is involved

There is a version of CRs that does involve a genuine mistake. A consultant misinterprets a requirement. An assumption slips into the build without being explicitly validated. Something that should have been caught during the Discovery phase was not. These things happen, and when they do, the right response is different: acknowledge it dispassionately, describe the impact, outline the fix, and move on. No drama. No self-flagellation. No lengthy apology that implies fault where fault actually exists, which only invites the client to agree with you.

But this version is, in my experience, the minority. Most CRs are not about mistakes. They are about the natural rhythm of learning on a complex project.

The problem is that clients - entirely reasonably - sometimes cannot tell the difference. A change request looks the same whether it was caused by a genuine oversight or by a legitimate evolution in understanding. And if the consultant responds to every CR with an apology, they are implicitly training the client to treat all of them as failures. That is a bad habit, and it compounds over time.

The real problem is the blame dynamic

Here is what actually causes damage in a CR conversation: the search for blame.

When a change request becomes an exercise in establishing whose fault it is, two things happen. Firstly, it wastes time that should be spent solving the problem. Secondly, it introduces a dynamic that will follow the project for months. Both sides start hedging. The consultant becomes risk-averse, spending billable time covering ground that has already been covered rather than moving forward. The client becomes suspicious of future recommendations. What was a collaborative working relationship starts to feel adversarial.

The cost of that dynamic is rarely visible on a spreadsheet, but it is very real. Projects slow down. Good ideas stop being surfaced because the political cost of raising them feels too high. The whole thing becomes harder than it needs to be.

The antidote is simple, even if it is not always easy. Treat the change request as a shared problem, not an accusation. Describe what changed and why. Frame it in terms of what the project now needs rather than what (or who) was wrong. And as a consultant I urge you to resist the instinct to apologise reflexively. Because reflexive apologies, however well-intentioned, invite exactly the blame dynamic you are trying to avoid.

A note for the client side

If you are on the client side reading this: a change request from your implementation partner is almost certainly not a signal that you hired the wrong people. It is almost certainly a signal that your project is progressing. The right question to ask is not "why did this happen?" but "what do we need to do now?" - and then, separately, whether the governance and process around change control is working well enough to manage these things calmly when they arise.

Because they will arise. On every project worth doing, they will arise.

That is not a problem. That is just how this works.