Define the Exit Criteria Before a Client Project Starts

"Basically done" is not a project status

A supplier says the service is live. The client has a short list of concerns. Your team is waiting on one document and a final billing answer. Nobody wants to call the project complete, but nobody is actively running it either.

This is how advisory projects stay open for months.

The problem usually started before kickoff. The advisor documented scope, dates, and responsibilities, but never defined the evidence required to finish. Everyone can describe what the project includes. Nobody can say what must be true before it closes.

That ambiguity has a cost. Open work keeps consuming follow-up. Client expectations drift. Supplier issues lose urgency. The project sits in your capacity view even though nobody knows whether it needs more delivery work or a clean handoff.

Define the exit criteria before the project starts. If the finish line appears only when the work is almost over, it will move every time somebody raises a new concern.

Separate delivery from acceptance

Delivery is what the supplier or project team completed. Acceptance is the evidence that the agreed result is ready to move into normal operations.

Those are related, but they are not the same.

A circuit can be installed without the client confirming failover. A contact center can be configured without supervisors approving call flows. A security service can be activated while escalation contacts are still wrong. A cloud migration can finish while one reporting exception remains unresolved.

Your closeout standard should answer two questions:

1. What must be delivered?
2. What evidence will the client accept as proof?

Do not invent acceptance tests after the supplier says the project is complete. Put them in the proposal, statement of work, or kickoff record while the client can still challenge them.

Build five closeout gates

A useful closeout checklist is not a pile of completed tasks. It is a small set of gates that prevent unfinished work from hiding behind a status label.

1. Delivery evidence exists

Record what was delivered and connect it to the original scope. Evidence might include an activation confirmation, accepted test, installed-location list, configuration record, training completion, inventory, or client-approved deliverable.

The evidence should be specific enough that another person can inspect it later. "Supplier confirmed complete" is weak. Name what the supplier completed, when it happened, and where the supporting record lives.

2. The client has accepted the result

Decide who can accept the project for the client. The person attending weekly calls may not have that authority.

Acceptance does not always need a formal signature. It does need a durable record. Capture the client's approval, the date, the evidence reviewed, and any conditions attached to the approval. If the client will not accept the work, the project is not closed. It is blocked, disputed, or still in delivery.

3. Open issues have a treatment

Some projects can close with minor exceptions. That is reasonable when everybody can see the exception and agrees on what happens next.

Put every open item into one of four treatments: finish before close, transfer to support, accept as a known limitation, or remove through an approved scope decision. Give the item an owner and date. A vague punch list attached to a closed project is just hidden work.

If a supplier issue is blocking acceptance, use a defined supplier escalation process. Closing the internal project does not make the client impact disappear.

4. Operational ownership has moved

The project team should not remain the default owner forever. Confirm who handles support, billing questions, service changes, account reviews, and future supplier communication.

Give the client the right contacts and escalation path. Give your account owner the contract dates, supplier records, service details, open risks, and next review date. This is the handoff into the broader client lifecycle.

5. The commercial record matches reality

Before closing, compare the final service, locations, quantities, pricing, billing start, contract dates, and expected commission against the approved deal record. A delivery project can look complete while the revenue and contract records are still wrong.

Do not turn closeout into a full accounting audit. Confirm enough to catch obvious gaps while the implementation history and supplier contacts are still fresh.

Put an owner on acceptance

Project managers often own tasks but do not own the final acceptance decision. That gap matters.

Name one advisor-side closeout owner at kickoff. This person gathers the evidence, confirms the client approver, resolves the open-item treatment, and moves the project out of active delivery. Other people can do the work. One person owns the decision to close.

Also name the client approver and supplier completion contact. If either role changes, update the record. Waiting until the final week to discover that the original sponsor left the company is avoidable.

Use a closeout meeting only when a decision is ready

A closeout meeting should not be another status call. Send the evidence first. Show the original scope, delivered items, acceptance results, open exceptions, operational owners, and commercial checks.

The meeting should end with one of three decisions:

• Close the project and move the relationship into normal account management
• Close with approved exceptions and dated owners
• Keep the project open because a named acceptance condition has not been met

If the decision is "we need to look into a few things," record exactly which gate failed. More discussion is not a closeout state.

Do not confuse project closeout with account closure

A completed project may be the start of a long client relationship. Preserve the work that will matter later.

Move the final scope, acceptance evidence, important decisions, service records, unresolved risks, and lessons into the client account. Set the first post-project review date. Confirm which results the advisor should revisit and which contract event comes next.

This also gives the team better context for a client business review. You should not need to reconstruct the project six months later to explain what changed.

Review closeout during capacity planning

Projects that never close distort the delivery picture. They make the team look busier than it may be, but they can also hide real follow-up behind stale project records.

During your rolling capacity review, flag any project with no current milestone, no dated client commitment, or no clear exit gate. Decide whether it needs delivery attention, client acceptance, an operational handoff, or closure.

Do not close work just to clean the dashboard. Close it because the evidence supports the decision.

Keep the closeout record with the client

Shared operating context matters more than a perfect template. The project, tasks, activities, client contacts, supplier history, and contract timing should stay connected.

Advisor OS gives advisory firms project visibility, task management with due dates, contact and organization activity, supplier records, contract context, and pipeline history in one system. A client portal can also give the client a consistent place to see project and account information.

The software cannot decide whether the client should accept the work. It can keep the evidence, owners, dates, and account history from breaking apart while you make that call.

Pick one active project that feels "basically done." Check the five gates. If delivery evidence, client acceptance, exception treatment, operational ownership, and the commercial record are clear, close it. If one gate fails, name the owner and next date today.

If your project history still depends on inbox searches and memory, run the free Advisor OS agency scorecard and see where the operating gaps are.