“Who Owns the Delay?” How Engineers Can Respond When Client Input Arrives Late
The client delivers the required input five days late.
The deadline stays exactly where it was.
And somehow, those five missing days become the lead engineer’s problem.
You reschedule the analysis. Move another project aside. Ask a colleague to start with preliminary data. Skip some thinking time and promise yourself you will perform the final check properly once the pressure drops.
It rarely does.
The project may still be delivered. From the outside, everything looks fine.
But the planning was not fine. The delay was absorbed through interrupted work, rushed reviews, hidden overtime or another project quietly slipping instead.
In one of my conversations with an engineer, they estimated that nine out of ten projects did not start as planned because client information arrived late. In another conversation with an engineering company, late input and projects taking longer than expected came up again.
These conversations do not prove that every engineering company has the same problem. They do show a pattern worth examining: When the client delivers information late, why does the engineer inherit the original deadline?
The answer is not simply “because the client is responsible.”
A clause in the contract helps. A clear project schedule helps. But neither protects the engineer if nobody makes the dependency visible, discusses the impact and decides what changes.
Late input is not only a planning problem.
It is an ownership and decision problem.
Late input does not automatically create the same amount of delay.
Let us start with an important correction. If input arrives five days late, the final delivery date does not always need to move by five days.
Engineering projects are not perfectly linear. Work may be resequenced. Some activities can start with confirmed assumptions. Part of the delay may sit outside the critical path. A buffer may absorb it. And complex technical work often requires iteration even when all information arrives on time.
So this equation is too simple:
Five days late input = five days later delivery.
But this equation is equally dangerous:
Five days late input = the engineering team works five days faster.
The actual consequence depends on:
Which activities needed the input
Whether those activities are on the critical path
What work can safely continue in parallel
Whether preliminary assumptions can be used
How much rework those assumptions may create
Which resources are still available when the input arrives
What contingency was included in the schedule
Which quality checks and approvals remain necessary
The impact must be assessed.
Not assumed away.
Why the pressure reaches the engineer before the project manager
Someone asked a sharp question under one of my LinkedIn posts: If the contractual mechanism is clear and the effect of late input is understood, why does the pressure reach the lead engineer before the project manager?
Exactly.
Sometimes the underlying problem is not the late information itself. It is that the timeline was committed before project ownership, input requirements and decision rights were properly established.
The lead engineer then sits closest to the technical consequence but does not necessarily control:
The contract
The client relationship
The committed milestone
The available budget
Team priorities across projects
Approval of assumptions
The decision to move the deadline
Responsibility arrives before authority.
That is why “the engineer should communicate better” is only part of the answer. Engineers need a practical way to flag the dependency and explain its impact. Project managers and engineering managers must then use that information to make or secure a decision.
Otherwise, the engineer becomes the shock absorber between the commercial promise and technical reality.
The five moments when late input becomes hidden engineering work
Late input rarely causes trouble at one single moment. The damage builds through a sequence of small decisions.
1. The required input was never specific enough
“Client information required” is not a manageable dependency.
Which information? In what format? At which maturity level? Approved by whom? Needed for which activity? By what date?
If the input is not defined, the client may reasonably believe it has delivered enough while the engineering team is still waiting for what it actually needs.
2. The deadline was discussed, but the dependency was not
The project plan shows when the calculation or drawing should be finished. It does not clearly show that the work can only start after approved loads, survey data, vendor documents or interface dimensions are available.
The deadline becomes visible.
The condition behind it does not.
3. The input date passes quietly
The engineer sends a friendly reminder but does not state the consequence. “Just checking whether the data is available yet.”
The client hears a request for information. Not a warning that the delivery plan is becoming unreliable.
4. The team starts with assumptions to keep moving
This can be a sensible decision. It becomes risky when the assumption, approval and possible rework are not documented.
Preliminary work then appears to be normal progress. When the final input differs, the additional work looks like an engineering overrun rather than the consequence of an agreed project choice.
5. The engineer tries to recover the lost time
This is the moment the delay changes owner without anyone explicitly deciding it. The team compresses the work. Reviews get shorter. Other priorities move. The project manager continues reporting the original delivery date because engineering has not formally stated otherwise.
Everyone is being helpful.
The system is producing unreliable commitments.
Use the INPUT method
When a project depends on client information, use this sequence:
Identify → Name ownership → Pin down the date
→ Update the impact → Trigger a decision
It works before the project starts and when information is already late.
1. Identify exactly what is required
Describe the input in a way that allows both parties to verify whether it has been delivered. Clarify:
The document, data or decision required
The required format and revision
Whether preliminary or approved information is needed
The technical activity that depends on it
Any quality, completeness or acceptance criteria
Compare these two requests:
“We need the interface information.”
And:
“To start the final connection analysis, we need the approved interface loads for all six load cases, including the coordinate system, load factors and revision status.”
The second request removes room for two different interpretations of “input delivered.”
Useful questions before starting:
“Which party produces this information?”
“Who approves it before we use it?”
“Can we work with a preliminary revision, and for which activities?”
“Which changes can we still expect after this issue?”
“What will be our agreed design basis if final information is unavailable?”
These are not administrative questions. They protect the technical basis of the work.
2. Name ownership on both sides
Every critical input needs an owner who can influence delivery.
“The client” is not an owner. Name the person or role responsible for:
Supplying the information
Checking or approving it
Following up before the due date
Assessing the technical impact if it is late
Deciding how the project responds
The engineer may own the technical assessment. That does not mean the engineer owns the commercial or planning consequence. For example:
Client interface engineer: supplies approved loads
Lead engineer: assesses effect on the analysis
Project manager: agrees the planning consequence with the client
Engineering manager: resolves conflicts in team capacity
This division prevents responsibility from collapsing onto the person closest to the work.
3. Pin down the date and its consequence
An input date without a linked consequence is just a hopeful calendar entry. State three dates:
When the input is required
When you will warn that the date is at risk
When the delivery plan must be reviewed
For example:
“We need the approved geotechnical parameters by 6 September to start the final foundation analysis. Please flag any expected delay by 3 September. If the approved data is not available by 6 September, we will assess the effect on the 20 September design review and agree whether to replan or continue with a documented assumption.”
This does not threaten the client.
It makes the dependency usable.
Before-the-deadline reminder “A quick reminder that the approved vendor loads are required on Thursday to start the final structural check. Are you still expecting to meet that date? If not, please let us know today so we can assess the planning options before the team is reassigned.”
Notice the last sentence. Capacity is not frozen in place while the project waits.
That matters in engineering companies where the same specialists work across several projects.
4. Update the impact when reality changes
Do not jump straight from “input is late” to “the deadline moves.”
Assess the project effect using four questions.
What work is blocked? Name the activities that cannot start or finish.
What can continue safely? Separate genuinely independent work from activities that would rely on unconfirmed assumptions.
What will resequencing cost? Switching tasks is not free. Consider remobilisation, lost concentration, availability of specialists, duplicated checks and knock-on effects for other projects.
Which options remain?
The project may be able to:
Move the affected milestone
Protect the milestone by reducing or phasing the deliverable
Continue using an explicitly approved assumption
Reassign capacity, including the effect on other work
Prioritise one discipline or package
Wait for the final input and accept the resulting schedule exposure
Do not present an impossible promise as the default and the real options as excuses.
Put the trade-off on the table. Practical impact format.
Use: Missing input → Blocked work → Remaining options → Decision needed
For example: “The approved environmental loads were due yesterday and have not been received. This blocks the final fatigue assessment and the dependent drawing review. We can continue with the preliminary load set, but this may require rework if the final values change. Alternatively, we can move the drawing review by four working days and retain the normal verification sequence. We need confirmation today on which option to follow.”
That is much stronger than:
“The client is late, so our planning is delayed.”
It gives the decision owner something to decide.
5. Trigger a decision and confirm it
The objective is not merely to notify everyone that input is late. The objective is to agree what happens next.
Depending on your role, you may not have the authority to move a contractual milestone, accept extra cost or approve a technical assumption. That is fine. Your job is then to make the missing decision visible and put it with the right owner.
Internal script for a lead engineer:
“The final client data is now three days late. We can still protect the milestone if we work with the preliminary values, but that creates a rework risk and needs client acceptance. I need you to decide whether we propose that option or formally replan the delivery.”
Script for a client meeting:
“We want to keep the project moving, but we should not hide the effect of the missing input. The original delivery date assumed approved data by Monday. We now see two workable options. We can use the preliminary revision and accept the rework risk, or move the affected deliverable while keeping the full verification sequence. Which outcome has priority for you?”
Script when the client asks you to maintain the deadline:
“We will assess what is still feasible. To avoid creating a quality risk, I cannot confirm the original date until we have checked the remaining work, team availability and review time. I will return with options by 15:00.”
You do not need to accept the pressure in the meeting to prove that you are helpful.
You need to return with a reliable answer.
The email records facts, consequences, owners and dates.
No blame. No vague promise to “do our best.”
What if the contract already covers late input?
A clear contractual mechanism matters. It can define client obligations, notice requirements, entitlement to time or cost and the process for agreeing changes.
But a clause does not enforce itself. The project still needs someone to:
Recognise that the triggering event occurred
Follow the required notification process
Record the dates and affected activities
Assess the actual schedule and cost impact
Discuss mitigation
Secure a decision
If those steps do not happen, the engineer may still feel the same pressure even when the contract is perfectly clear.
Equally, engineers should not make contractual claims from memory. Use the project’s agreed process and involve the project or commercial manager when required.
The practical lesson is simple:
A contractual right is not the same as an operational response.
Both are needed.
Plan for iteration without making every deadline optional
Another response to my LinkedIn post raised a valid point: complex engineering projects require iteration. A purely linear plan can create trouble because it assumes that every input becomes final before the next activity starts.
True.
The answer is not to treat all late information as unexpected. Build the expected iteration into the project approach. For example:
Distinguish preliminary, review and approved input
Define which engineering activities can use each maturity level
Plan interface reviews before final analysis
Include decision gates and freeze dates
Reserve realistic time for comments and rework
Make assumptions and their expiry dates visible
Protect specialist capacity around critical input dates
This creates a more realistic plan.
But iteration is not an excuse for unlimited change or undefined input.
Planned iteration has boundaries, owners and review moments. Uncontrolled iteration is simply scope and schedule uncertainty wearing a nicer jacket.
What engineering managers and project managers must organise
Engineers can improve how they communicate late input. They cannot solve a broken project system alone. Managers need to establish the conditions in which early communication leads to a decision.
Make input dependencies visible in the schedule
Do not plan only engineering outputs. Show the client documents, decisions and approvals that enable them.
Project scheduling guidance consistently treats dependencies, ownership and timing as essential parts of a workable plan. If a task cannot start without information, that information is part of the schedule logic.
Agree authority before the problem occurs
Who can approve preliminary assumptions? Who can move a milestone? Who speaks to the client about additional hours? Who decides which other project loses capacity?
Do not leave these questions for the lead engineer to discover under pressure.
Create a real early-warning route
Early warnings work when they lead to risk reduction, not blame. Formal project approaches such as NEC explicitly use early warning to surface matters that could affect price, completion or performance and to discuss actions before the impact grows.
Your company may not use an NEC contract. The operating principle still helps: warn early, assess jointly and agree action.
Stop rewarding invisible recovery
If a team repeatedly compensates for late input without updating the project record, management receives false data. It may conclude that:
The original schedule was realistic
The delay had no cost
The team has spare capacity
The same commitment can be made next time
Track the recovery work, resequencing and impact on other projects. Not to create a blame file, but to improve the next decision.
Protect technical review time
When time is lost, the review should not automatically become the buffer. Compressing a review may protect a date on paper while increasing technical and organisational risk. If the review sequence changes, that should be a conscious decision by someone with the authority to accept the consequence.
What should you do the next time input is late?
Do not immediately absorb the delay.
Use the INPUT method:
Identify → Name ownership → Pin down the date → Update the impact → Trigger a decision
Make the required information specific. State who owns it. Connect the input date to the dependent work. Assess what can still be done safely. Present the remaining options. Put the decision with the right person and confirm the agreement.
The goal is not to prove that the client caused the problem.
The goal is to stop lost time from silently becoming your personal deadline.
That gives you more control over your work, protects the technical process and helps the project make an honest decision while options still exist.
Want engineers to raise risks before the options disappear?
Protect the Scope helps lead and project engineers handle late input, changing requirements and additional client requests before they turn into hidden rework and avoidable pressure.
You learn how to:
Recognise when a project dependency is becoming a scope or planning risk
Explain the technical and project consequences clearly
Separate helpful flexibility from unapproved extra work
Put decisions with the right owner
Confirm scope, responsibility, planning, budget and approval in writing
No generic advice to “communicate more.”
Just a practical approach built around the situations engineers actually face.
Suggested internal links
Why Engineers Wait Too Long to Raise Project Risks — and What to Do Instead
“Can You Quickly Add This?” How Engineers Can Handle Out-of-Scope Client Requests
“That’s Not What We Expected.” How Engineers Can Clarify Client Expectations Before Work Starts
How Engineers Can Communicate Technical Risks Without Creating Panic
Suggested external references
Annick Sabel
Annick Sabel (36) spent ten years as a Managing Director of engineering companies in the offshore industry. She combines technical understanding with strong business experience and a practical, people-focused approach. Through CTD, she helps engineers develop business skills they can apply directly in their daily work. She is keen to get in touch and discuss your thoughts.
