One sentence, two meanings
On one project the client and the delivery team understood the agreed scope differently. Both were reading the same document, and both were sincere. Handled badly, this turns into a blame discussion, and a blame discussion damages the relationship for the rest of the project.
Looking back, the gap rarely came from bad faith. A scope statement written at the start of a project is read weeks later, under pressure, by people who were not in the room when it was agreed. Words like integration, reporting or support stretch easily. Each side fills the blanks with what it expects, and the difference only appears when somebody tries to deliver or accept the work.
Two ways to get it wrong
The first is to refuse anything outside the contract. It is correct on paper, and it is the end of the partnership. The second is to absorb the small requests to keep the client happy. Each one looks small on its own, but they add up, and the team pays for them.
A third way: make every change visible
We went back to the written baseline together. I treated the disagreement as a gap in shared understanding, not as anyone's fault. Then I sized the impact in time and budget and gave the client options. The mechanics are simple:
- A written scope baseline, in the client's language, with assumptions and exclusions.
- Every request logged against the baseline, however small.
- Impact sized in days and budget before anyone says yes or no.
- The client chooses: swap it for something of similar size, add it as a change request, or move it to a later phase.
In practice it sounds like this (the number is only an illustration):
Happy to add this. It is roughly eight days. We can swap it for something of similar size, or add it as a change.
What changes in the conversation
When a request arrives with a size and a choice attached, the client is no longer asking for a favour and I am no longer saying no. We are both looking at the same trade-off. Some requests turn out to be worth the money. Others disappear once they have a price, which tells us they were never that important. In both cases the decision belongs to the person who owns the budget, and the team is not left carrying work nobody agreed to.
Why the baseline matters
The written baseline is the neutral third party in the room. When there is a disagreement, both sides can disagree about the document instead of about each other. That is a far easier conversation, and it is the reason I invest in writing scope clearly at the start.
I also review the baseline with the client at regular intervals, not only when something goes wrong. A short check, in the same forum as the status report, keeps both sides reading the same version of the agreement, and it catches the next misunderstanding while it is still a small one.