The system has been live for three months. Users are working in it, half the team is already on something else, and in the status report the project is still “in progress”. There are eleven items left on the list. Two weeks ago there were nine.
Nobody can say when it will end, because everyone understands the end differently. For the team the project ended on go-live day. For the client it will end when the last remark disappears. For the sponsor, when they stop paying for it.
The last five percent of a project can take longer than the first ninety-five. That rarely comes from the difficulty of the work that is left. More often it comes from nobody having agreed what “finished” means.
Why the tail drags on
There are four reasons, and they usually come together.
A list that grows. Every closed remark gives birth to two new ones. The client looks at the system more closely than during testing and reports things they didn’t see before. Some of them are bugs, and some are new wishes written down as bugs.
A team that is no longer there. The best people have been moved to the next project. The fixes are done by someone who comes back to the subject for two hours a week and each time has to remind themselves how it works.
A signature nobody wants to give. For the client the acceptance report means the end of being able to raise remarks. As long as they haven’t signed, they have the supplier at hand. Delaying is reasonable for them. It is the last and most expensive form of the gap between the client’s “done” and the team’s “done”.
A sponsor who isn’t hurting. A project that works stops being urgent. The sponsor has new matters to deal with, and the tail of the old project doesn’t hurt anyone enough to be dealt with.
Close the list before you start shortening it
In my experience one move unblocks the tail: the list stops accepting new items.
It takes a conversation with the client and one date. Until that day we collect everything that needs fixing. After that day the list is closed, and every new thing goes on a separate list, to be handled by operations or by the next phase.
The client usually agrees if they get something in return: the certainty that the closed list will be done in full and by a set date. Until now they had neither.
While you are at it, go through the list once more and put each item into one of three groups: a bug that blocks work, a bug people can live with, and a new wish. Only the first group has to be done before closing.
Define “the end” on one page
A project that is to close needs a definition of closure written out plainly. Four sentences are enough.
What has to work. What is handed over to operations, and to whom. What was deliberately not done, and why. Who signs, and when.
The third sentence is the most important and the one most often left out. A list of things not done, written down and accepted, closes a project more effectively than an attempt to do everything. A project without such a list always has something left to finish.
Give the tail an owner and a date
The last stretch needs the same thing the whole project needed: one person responsible for it, and a deadline.
A short, separate closing phase works well. Two or three weeks, specific people assigned to it full time for that period, a daily review of the list. That costs less than three months of fixes done an hour a week.
It is worth showing the sponsor this calculation in time, not in money: the team has been going back to the old project for a quarter, and the new project is standing still because of it.
Closing is an event too
A project that ends quietly leaves people feeling that nothing ended. One short meeting makes a difference: what we delivered, what we are handing over, what we didn’t do and who we thank.
After that meeting the project disappears from the status report. It is a small thing, but only then does the team really move on to the next piece of work.
One question for this week
Do you have a project that works and is formally still running? What would have to be written on one page for it to be closed this month?
All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.
