The last ten percent

I run delivery across a portfolio of client work, from scoping through testing and deployment and whatever reporting comes after. The pattern that shows up most reliably, across account after account, is not that projects overrun in the middle. The middle is usually fine. The substantive work finishes roughly when somebody said it would.

Then there is a stretch afterwards which is not really work in anyone’s mental model, and that stretch is where the date goes.

Why it is never in the estimate

Estimates are produced by people who find the substantive part interesting. That is not a criticism, it is how anybody estimates anything: you picture the work, and you can only picture the work you can picture.

Nobody pictures the closing items. Permissions that were fine in the account it was built in and are not fine in the client’s. Naming that was obvious to the person who chose it and is not obvious to the two people who will inherit it. A report that has to be signed off by somebody who is on leave. A step that only exists in one person’s head, which is discovered at exactly the moment that person tries to hand it to somebody else and cannot.

Every one of those is trivial in effort. That is why nobody counts them. It is also why they are dangerous, because effort is not what they cost.

The costly part is that they are not yours

Nearly every closing item requires somebody outside the team. An approval, an access grant, a decision from a person with other priorities, a training session with somebody who has a calendar.

An item like that has latency you do not control. A one hour task with a three day dependency is a three day task, and a plan that records it as an hour is not optimistic, it is measuring the wrong quantity. Ten of them do not take ten hours. They take as long as the slowest chain of people, and the chains overlap in ways nobody maps.

The Tableau migration I ran, a hundred workbooks and a hundred and fifty odd sources, is the cleanest example I have. The rebuild was long and knowable. The cutover was short and entirely made of other people: access, validation by the teams who owned each area, and the question of who now owns a thing that used to run somewhere else. That is the part that decides whether it went well.

Nobody outside sees the build

This is the bit I think is underrated. The client does not experience the substantive work at all. They cannot. It happens somewhere they are not, and they hear about it in a status update.

What they experience is the closing stretch. The handover call, the document they were given, whether the thing works on their machine, whether the person who trained them knew the answer. Their entire impression of the engagement, including of the parts they never saw, is formed there and then applied backwards over everything.

So the part that is systematically unestimated is also the only part that is fully visible. Those two facts together explain more missed dates and more unhappy clients than any amount of technical difficulty.

What did not work, and what costs something

Padding did not work. I spent a long time adding a buffer at the end, and buffers get eaten, because they are unlabelled and the interesting work is happy to expand into anything unnamed.

What works is naming the closing items as items, with owners and dates, in the plan, at the beginning, when they are boring and nobody objects to them. It is not clever and it took me too long.

It also has a price nobody mentions. A plan with the closing work in it is longer than a plan without it, and it is compared against plans without it. You look slower than the person who did not name any of it, and sometimes you lose the work to them, and then somebody else finds out in month three what you were trying to say in week one.

I have never found a way to make the last stretch feel important while I am in it. Only ways to make sure it is on the list before it stops feeling optional.