The missing scope is the client's
Sales versus delivery explains the internal argument. It explains where the margin goes. It does not explain why the client is still unhappy after the team ships the agreed backlog.
In delivery terms, "promise" is too loose a word for the first one. What matters is the scope of sale: the number, the date, and the written description of what the client bought. Call it the sold scope.
Engineering writes the built scope later, against a closer look at the site, the existing kit, and the dependency nobody costed. It comes in a third bigger. That can happen cleanly. The proposal was written before anyone had checked the site, the network, the old kit, or the supplier lead times.
Sometimes it is not innocent. The ambiguity helped the deal get signed. Either way, delivery inherits it unless someone prices the difference before the client treats it as included.
The third one is the expected scope: what the client carried out of the room and later described to their own board. It is rarely written down, and it is rarely a single scope. The sponsor bought an outcome, IT heard a support burden, facilities heard a room change, and the end user heard that Monday morning would be easier. The client is not one person. It is a set of internal commitments using the same logo. The useful question is not what the client expects. It is which client expectation wins when sponsor, IT, facilities, and users disagree.
That is the dangerous one. It is the version the project gets judged against, and it usually has no owner. Sales thinks delivery now owns the conversation. Delivery thinks sales already set the expectation. The client thinks both heard the same thing.
Sometimes the expected scope is written down. It is sitting in an email, a board pack, or a procurement note. The failure is not that the client hid it. The failure is that nobody converted it into the delivery plan.
Why the reports stay green
Green is a local measurement. It tells you the team is on track against the thing they chose to track. It does not check the build against the sale, or against the picture in the client's head, because nobody put those two into the report. Green is not proof of alignment. It is only proof that one measurement passed.
The failure usually appears when the project changes audience. The weekly delivery meeting is checking tasks against the backlog. The sponsor's board review is checking the demo against the promise they made internally. Those are different tests, and the second is the one that counts. It tends to be the first time the proposal, the backlog, and the client's internal story are checked against each other.
Reconcile the three scopes
Do not add another status meeting. Put the three versions of the job in one document: sold, built, expected. Put every line that affects price, date, user experience, or responsibility in all three columns. Where a line cannot be written the same way across all three, it is not aligned, whatever the status board says.
The steps:
- Write the three scopes in the same format. The sold scope is in the proposal. The built scope is in the backlog and an engineer's head. The expected scope is in the client's emails and their board deck. Most projects only have the first one on paper, which is why the other two never get checked.
- Validate the expected column with the people inside the client: the sponsor, the IT owner, facilities, and the actual user. Where they disagree, that disagreement is the first thing to resolve.
- For each mismatch, name who owns it and what it changes, commercially or in the schedule. A mismatch with no owner is the one that surfaces at the demo.
- Put each mismatch to the client while there is still time to choose. They can reduce scope, fund the extra work, or move the date. At handover, everyone is just buying back time.
Whoever runs this needs commercial authority, or direct access to someone who has it. A project manager can record a mismatch. They cannot trade price against scope against date unless the business has given them the right to. Without that authority, the document records the problem but cannot close it.
Expect the client to resist writing the expected scope down, because writing it down exposes the disagreements on their own side. That resistance is information, not a reason to skip the step. Do not ask them to write the technical scope. Ask them to write the outcome they expect, the promise they made internally, and the constraints they know about. Translating that into delivery work is the supplier's job, not theirs.
It is not clever work. It is a spreadsheet, some pricing, and a few calls nobody wants to make. That is where most rescues actually start.
What it looks like in AV
AV exposes this quickly, because "the room just works" is not a scope line. It is an outcome, and it hides a control processor, a network the client's IT team has not provisioned, a cable route, and a supplier lead time.
Take a fixed-date boardroom install. Sold scope: one button joins the call. Built scope, once an engineer has walked the site: a control processor, a certified network nobody on the client side has ordered, and a video matrix on an eight-week lead. Expected scope, in the client's head: "it works like the one in the other office", which ran on different kit entirely.
The awkward part is that some of the missing scope sits inside the client. If their IT has not provisioned the network, that is not supplier work, but it is still part of the outcome the client is expecting. That does not let the supplier off. If the room depends on client IT, the supplier still has to name that dependency early and get it owned. Surface it in week two and the output is not a warning note, it is a decision: IT provisions by Friday, the supplier prices a managed network, or the date moves. Reach the demo without it and the supplier gets blamed for a room it was never able to make work.
This is the pattern across integration work. The calm projects are usually boring for a reason: the awkward assumptions were written down before they hardened into commitments. I have seen it most often in AV and integration, because the thing the client buys there is an outcome, not a parts list. The calm jobs are rarely lucky. Someone forced the scope argument early.
When this is overkill
Do not turn this into ceremony. There are cases where the lightweight version is enough.
If the same person sold it, builds it, and talks to the actual user every week, the formal version may be overkill. Still write down the few assumptions that would hurt if they were wrong. If the buyer and the user are different people, do the lightweight version anyway, because that split is exactly where the expected scope hides.
Discovery work does not have a fixed solution to reconcile. It still has an expected output: the method, the evidence, the decision points, and what counts as done. Match those, and do not invent a delivery commitment to make the spreadsheet look finished.
Not every gap earns a meeting. If the difference is small and the schedule can absorb it, say the built scope is a fortnight off the sold scope with three months in hand, record it, give it an owner, and move on.