When client approval delays a software project

The UAT build was ready last Tuesday.

The client product owner promised sign-off by Thursday. Nine days later, the agency still has no approval, no consolidated feedback, and no access to the production identity provider.

The launch date in the steering deck has not moved.

On Monday, the client asks, “We are still launching on the fifteenth, right?”

The delivery manager does not want to sound defensive. So they say the team will do its best.

Now a missing client decision has become an agency promise.

When client approval delays a software project, treat the approval as a delivery dependency: define exactly what is needed, show the agreed date and current status, calculate the real impact, offer ways to unblock the work, name the decision owner and deadline, and document the revised plan.

A late approval is a dependency change, not a blame contest

The weakest version of this conversation is:

“The project is late because you did not approve on time.”

It may be factually incomplete and it gives the client only two responses: accept blame or dispute it.

The stronger question is: what work depended on the approval, how much scheduling flexibility existed, what can continue safely, and which decision now protects the client's priority?

A late client input does not always produce a day-for-day project delay. The approval may have float. Other work may be resequenced. Or the blocked item may sit on the critical path and release specialised people who cannot return immediately.

Atlassian identifies client approvals as external dependencies that can create project lag and recommends close stakeholder communication and contingency planning. That is the right frame: make the dependency and consequence visible before arguing about fault.

The earlier EARLY framework for communicating a possible deadline slip explains how to raise an agency forecast before the client asks. DEPEND focuses on a narrower situation: the delivery forecast is changing because a required client decision, asset, access, or approval has not arrived.

The DEPEND framework for client approval delays

DEPEND gives delivery managers and tech leads six moves for addressing a blocked client dependency without softening the impact or weaponising the timeline.

1. Define the exact approval or input

“Waiting for feedback” is not a controllable dependency.

State:

• The deliverable and version under review.
• The decision required: approve, reject, choose, supply, or clarify.
• The acceptance criteria or questions the client should use.
• The person authorised to respond.
• What the approval unlocks.

“We need approval or specific rejection comments on UAT build 1.8 against the twelve agreed acceptance cases. Priya owns the sign-off. Approval unlocks production configuration and the final regression cycle.”

Not:

“We are still waiting for your team.”

Instead:

“We need Priya's decision on UAT build 1.8 to begin the two tasks that depend on it.”

Specificity makes it possible for the client to act, delegate, or explain the blocker.

2. Evidence the agreement and current status

Build a short chronology from shared records:

• When the dependency and due date were agreed.
• When the review material was delivered.
• Which reminders, walkthroughs, or clarification answers were provided.
• Whether partial feedback has arrived.
• What remains outstanding now.

“The plan assigned UAT approval to the client by 13 August. We delivered build 1.8 and the acceptance pack on 11 August, completed the walkthrough on 12 August, and answered the two open questions on 13 August. As of today, the approval decision is outstanding.”

That is evidence. A twelve-line list of every unanswered message is prosecution.

If the agency delivered late, changed the review version, sent incomplete instructions, or approached the wrong approver, include that too. A dependency conversation loses credibility when the timeline is edited to make only one side late.

3. Project the real impact

Translate the delay through the project plan before translating it to the client.

Check:

• Whether the dependency is on the critical path.
• How much float has already been consumed.
• Which tasks and milestones are blocked.
• Whether other work can proceed without creating rework.
• When the required people are next available.
• Whether the delay changes cost, scope, quality, or operational readiness.

Atlassian recommends sharing critical-path dependencies with stakeholders so priorities and possible delays are understood. The point is not to show the client a complicated Gantt chart. It is to support the consequence with a visible mechanism.

“The approval had two working days of float, which has now been used. Production configuration and final regression are blocked. If approval arrives by Wednesday, the earliest evidence-based launch date becomes 23 September because the environment specialist returns on Monday. A decision after Wednesday moves the next available configuration slot to 28 September.”

Do not automatically add nine days to the launch because approval is nine days late. Do not automatically preserve the launch because the agency wants to look flexible. Reforecast the actual dependency chain.

4. Explore ways to unblock the project

The client may be late because the approval is too broad, the approver is unavailable, reviewers disagree, the evidence is unclear, or the decision feels risky.

Offer options that match the real blocker:

• Hold a decision workshop with the authorised reviewers.
• Split approval by feature, region, or risk boundary.
• Approve conditionally with named exceptions.
• Use an authorised delegate.
• Resequence work that does not depend on the decision.
• Move a lower-risk release forward and defer the blocked component.
• Release reserved agency capacity and agree a remobilisation date.

Never proceed on an unapproved assumption merely to preserve utilisation. That converts waiting time into rework risk.

5. Name the owner, deadline, and escalation path

“Please approve as soon as possible” has urgency but no operating rule.

“Priya owns the approval. We need the decision by Wednesday at 16:00 ET to keep the 23 September recovery plan. If she is unavailable, Daniel can approve as the named delegate. If neither can decide, we need the sponsor to choose between moving the launch and releasing the reserved environment slot.”

The escalation path should be agreed before it is needed. The START framework for client kickoff calls includes testing assumptions and naming decision roles early; approval lead times and substitutes belong in that conversation.

Escalation is not punishment. It moves a decision to the level that can protect the project outcome.

6. Document the decision and revised plan

After the call, record:

• The outstanding dependency and owner.
• The original and revised decision dates.
• The affected tasks, resources, and milestones.
• The option selected and alternatives rejected.
• The interim work boundary.
• The new forecast or the rule for calculating it.
• The next communication checkpoint.

Silence is not approval unless the governing agreement explicitly creates that mechanism. A reminder email cannot invent deemed acceptance.

When the decision changes the forecast, update the shared timeline and status language. The BRIEF status-update framework helps report the new bottom line, evidence, risk, and action without hiding the dependency inside a green slide.

What a complete client conversation sounds like

“We need to reset the plan around UAT approval. The agreed sign-off date was 13 August. We delivered build 1.8 and the acceptance pack on 11 August, completed the walkthrough, and answered the open questions by the due date. The decision is still outstanding. The approval had two days of float, which is now used, and it blocks production configuration and final regression. If Priya approves by Wednesday at 16:00 ET, the earliest supported launch is 23 September. We can shorten the decision by holding a one-hour review tomorrow or by separating the two disputed cases from the ten accepted cases. Our recommendation is the split approval so configuration can begin. If no authorised decision is available by Wednesday, we will release the reserved environment slot and reforecast against the next available date. Can we confirm the approver and option now?”

The statement is firm without saying, “This is your fault.” It shows the agreement, mechanism, options, and decision.

Prevent approval delays before they happen

Define approval as work

Put client reviews, decisions, access, and asset delivery on the plan with owners, durations, and predecessors. A milestone called “client review” with no expected effort is a hope.

Make the review pack decision-ready

State the version, review scope, evidence, acceptance criteria, excluded questions, response format, decision owner, and due time. The client should not need a meeting just to discover what “approve” means.

Agree the escalation ladder

Name the primary approver, delegate, reminder cadence, escalation point, and what happens to the schedule or reserved capacity after the decision window closes.

Model approval scenarios

Show what happens if approval arrives on time, three days late, or after the reserved resource window. This makes the dependency a shared planning fact rather than a surprise clause invoked under pressure.

What software agencies get wrong

The passive reminder loop

“Just checking in” repeated five times does not explain what is blocked, who must decide, or when the plan changes.

The accusation spreadsheet

A complete message history can support facts. Presenting it to win an argument usually makes the client defend the past instead of deciding the future.

The day-for-day fiction

Some dependencies have float; others lose a scarce resource window. Calculate the chain instead of applying an automatic calendar penalty.

The unapproved workaround

The team continues based on what it thinks the client will approve. If the assumption is wrong, the agency owns both the rework and the communication failure.

The silent resource switch

The agency moves engineers to another account but keeps promising an immediate restart. Remobilisation time is part of the impact and should be visible.

The goodwill deadline

Keeping the original date without a changed mechanism feels generous for one call. It becomes a credibility problem when the underlying work still needs the same time.

Frequently asked questions

What should you do when client approval delays a project?

Define the outstanding decision, confirm the agreed due date, calculate its real schedule impact, offer safe unblock options, identify the authorised approver, and document the revised plan.

How do you tell a client their feedback is delaying the project?

Use a neutral chronology and dependency statement. Explain what was due, what remains outstanding, which tasks are blocked, what date or resource window changes, and what decision can reduce the impact.

Does late client approval automatically extend the deadline?

Not automatically. The project plan, critical path, available float, resource calendar, contract, and selected recovery option determine the effect. Reforecast rather than assuming a day-for-day extension.

Can work continue without client sign-off?

Only work that does not rely on the approval should proceed, unless the authorised parties explicitly accept a conditional path and its risk. Continuing on an unapproved assumption can create avoidable rework.

How can an agency prevent slow client approvals?

Define decision owners and delegates, review lead times, acceptance criteria, response formats, reminder cadence, escalation paths, schedule consequences, and reserved-capacity rules before delivery reaches the gate.

Should client delays be documented?

Yes. Record the dependency, agreed and actual dates, communication, impact, selected option, owner, and revised commitment. Keep the record factual and useful for decisions rather than accusatory.

A dependency log cannot rehearse the difficult call

The pressure appears when the client denies the approval date, says the agency should “work around it,” refuses to move the launch, or expects the same engineers to restart immediately after weeks of silence.

PitchDawn lets delivery managers and tech leads practise dependency and difficult-client conversations with AI stakeholders who challenge the timeline and ownership in real time. The debrief helps reveal whether you blamed, softened the impact, invented a recovery promise, or ended without an authorised decision.

Explore realistic IT-services and consulting practice scenarios on the PitchDawn industries page.

Start your first blocked-project conversation free — no card required.