Review the Work Your Team Keeps Reopening

Small firms can hide rework for a long time

A client asks for one more change to a completed assessment. An implementation task reopens because nobody confirmed the handoff. A supplier issue returns because the update fixed the symptom but left ownership unclear.

The team handles it. Nobody wants to make the client feel difficult, so the extra work gets called follow-up, support, or relationship management. The task closes again and everybody moves on.

That works until the same kind of work keeps coming back. Then your delivery capacity, margin, and client promises are being shaped by a problem you do not track.

You do not need a heavy quality program for every correction. You need a simple decision: when completed work reopens, is the team fixing an isolated miss, completing work that was never accepted, handling a new request, or seeing a repeatable process failure?

Do not treat every reopened task the same

Start by separating four situations that look similar in an inbox but require different decisions.

• Correction: The team did not meet an agreed requirement and needs to fix the original work.
• Incomplete acceptance: The work may be correct, but the client or receiving owner never confirmed that it was complete and usable.
• New request: The client wants a different output, added analysis, another location, or a changed result after the original work was completed.
• Process failure: The same defect, missing handoff, unclear owner, or approval gap has appeared more than once.

Those labels keep the team honest. A correction belongs to the original commitment. A new request may belong in your scope change process. Missing acceptance points back to the way the work closed. A repeated failure deserves a review that changes the operating process.

If you mix all four together, the firm either charges clients for its own mistakes or gives away every changed request. Neither is a serious operating model.

Open a review only when the pattern deserves one

Not every typo needs a meeting. A quality system that investigates every small correction becomes another pile of work nobody maintains.

Review reopened work when the client was materially affected, the correction consumed meaningful team or supplier time, the original owner cannot explain why it reopened, the same failure has happened before, or the issue exposed a gap that could affect other accounts.

The American Society for Quality describes root cause analysis as a set of approaches for finding why problems occur, and it makes an important point: the analysis produces no result unless it becomes part of a larger improvement effort. That is the part small firms tend to skip. They name the cause, fix today's task, and never change the next task.

Keep the threshold practical. The review should earn its time by preventing a repeat, protecting a client, or clarifying a commercial boundary.

Build one rework record before the meeting

Do not start with opinions about who dropped the ball. Start with the record.

Connect the reopened item to the client, project, original task, owner, due date, agreement, proposal, supplier activity, delivery evidence, and client response. Record when the task first closed, who closed it, what evidence supported closure, when it reopened, who requested the new work, and how much internal and supplier effort the correction consumed.

Then write the problem in plain language. "The client was unhappy" is too vague. "The location inventory was marked complete without client confirmation, and two sites were missing" gives the team something it can test.

Keep facts and assumptions separate. The task record may prove that no acceptance response was attached. It does not prove the owner was careless. Maybe the acceptance rule did not exist. Maybe the client sent the final site list to somebody else. Maybe the work changed after delivery.

The point is to see the failure, not to find somebody to embarrass.

Find where the control failed

A useful review follows the work from commitment to closure. Ask where the process should have prevented or detected the problem and why that control did not work.

Most advisory rework will land in one or more of these operating gaps:

• The requirement was missing, vague, or changed without a recorded decision.
• The wrong client stakeholder reviewed or approved the output.
• The advisor, supplier, and client held different definitions of done.
• The owner closed the task without the required evidence.
• A handoff moved the task but not the context, authority, or open exception.
• The team corrected the immediate issue but left the same process exposed elsewhere.

Keep asking why until the answer points to something the firm can change. "Human error" is rarely useful. If a capable person could make the same mistake tomorrow because the requirement, record, review, or authority remains unclear, you have not reached an operating cause.

Choose the smallest correction that will hold

The fix should match the failure. Do not answer one missed approval by adding six new approvals to every project.

If the requirement was unclear, change the proposal or task template. If the wrong person accepted the work, record the client's approval owner during discovery. If a handoff lost context, add receiving-owner acceptance. If the task closed without proof, define the evidence required before the status can change. If the client made a new request, route it through a commercial decision instead of changing the old task.

Name one owner for the process correction, not just the client correction. Give it a due date and identify which future work will test it. Updating a checklist is not proof that the problem is solved. The next similar task must close correctly and stay closed.

A lightweight standard operating procedure can hold that correction. Document the decision that keeps breaking. Do not turn one review into a binder.

Close the correction and the review separately

The client should not wait while your team studies the process. Restore the immediate commitment, communicate the owner and timing, and confirm the client's acceptance.

Keep the internal review open until the firm has classified the rework, verified the cause, assigned the process change, and checked whether the correction worked on a later task. These are two different finish lines.

This also protects your project closeout process. Acceptance evidence tells you whether the client received the agreed work. A rework review tells you why that evidence or work failed and what changed afterward.

Bring repeated failures, overdue corrections, and process changes with no effectiveness check into the weekly operating review. Do not turn the meeting into a replay of every mistake. Ask for the decision, owner, due date, and test.

Audit the last ten completed client tasks

Pull ten tasks your team marked complete during the last month. Look for later emails, follow-up tasks, supplier tickets, revisions, or client requests tied to the same work.

For every reopened item, classify it as a correction, incomplete acceptance, new request, or process failure. Find the original definition of done, acceptance evidence, owner, and effort required after closure. If the same gap appears twice, assign a review.

Advisor OS CRM connects clients, contacts, activities, tasks, projects, proposals, contracts, suppliers, and reporting. That shared record gives a small advisory firm the context to see why work reopened and whether the correction changed the next job.

Use the free Advisor OS agency scorecard if completed work, client approvals, ownership, and follow-up still live in separate systems.