They don't send data. They send time
Every other source in this track hands you a number. The site gives quantities, the store gives issues, the commercial team gives cost. What the client and the consultant hand you is different in kind.
They give instructions, which change what has to be done. They give approvals, which decide when it can be done. And they give comments, which are the most ambiguous of the three, because a drawing returned with comments is neither approved nor rejected and somebody has to decide what to do with it this afternoon.
None of that is data in the sense the rest of the track means. It is duration and permission, and it belongs in the programme rather than in a correspondence file.
Turnaround is an activity
A submittal goes out and something comes back. The gap between those two events is real, it is measurable, and on most projects it is not planned.
The contract usually states a period. What actually happens is a distribution: some responses come back in days, some take weeks, and a few sit. Planning against the contractual figure produces a programme that assumes the fast case every time.
The fix is unglamorous. Record the actual turnaround for a few months and plan against what you observe rather than what the contract permits. If your consultant averages three weeks and the contract says two, the programme that assumes two is wrong by a week on every submittal, and there are hundreds of them.
Approved with comments
This is the category that causes the most trouble, because it looks like a decision and is not.
The drawing comes back marked approved with comments. Sometimes the comments are editorial and work can start. Sometimes one of them changes a dimension, and starting means building something that will have to be revisited. The status field says the same thing in both cases.
So the status alone can't be used as a readiness test. Somebody has to read the comments and decide, and that decision needs recording, because the alternative is that two people read the same drawing differently — which is where Week 13 starts.
The request with no record
There is a second thing that comes from the client side and it doesn't arrive through any of the formal channels.
A message asks where the daily report is, or whether the workfront is ready, or for the latest progress. It arrives directly, outside the reporting chain, often outside the project's own systems entirely.
Answering it is not the problem. The problem is that the request has no record. It can't be prioritised against the other things you were doing, it can't be assigned to somebody else, and in a month nobody can say who asked for it or why the work was done. Multiply it by a few requests a week
and a meaningful share of the reporting effort on a project exists nowhere in any plan.
What works is not refusing to answer. It is answering and then logging it — a line in the same register that holds the formal correspondence, so that the volume becomes visible even when each individual request was trivial.
The approval that was never asked for
There is a quieter version of the same problem, and it costs more than the slow response.
A submittal that was never sent can't be late. The activity sits in the programme with a start date, the drawing is ready, and nobody raised the inspection request or lodged the document because it was assumed somebody else had. Nothing appears in the turnaround log, because nothing entered it.
This is why a submittal register with only two columns is misleading. It measures the responses to things that were sent, which flatters the process by leaving out everything that never started. The useful register begins earlier: what has to be submitted, by when, to leave enough turnaround before the work needs it.
Read that way the register is a forward-looking document rather than a record. It tells you what to chase this week, which is a different job from telling you what happened last week.
Instructions that are not instructions
The last category is the one with contractual weight, and this track is not the place for it. Contract Week 6 deals with what constitutes an instruction and what follows from one.
What matters here is narrower: the reporting consequence. An instruction changes scope, and scope changes have to reach your quantities and your baseline before the next report, or the report describes a project that no longer exists. That handover is often informal, and the planner finds out about a change from a site engineer rather than from the change register.
System design
A submittal log that records only what was sent can't tell you what to plan against. Two dates and one status field turn it into an input.
| Record | Produced by | Required quality | Verified against | Feeds |
|---|---|---|---|---|
| Submittal sent | Project or engineering | Dated at issue | Transmittal | Turnaround measurement |
| Submittal returned | Client or consultant | Dated at receipt, with status | Correspondence | Turnaround, readiness |
| Comment decision | Engineering | Who read the comments and what they concluded | The marked drawing | Whether work can start |
| Actual turnaround | Project controls | Observed, not the contractual period | The two dates | Programme durations |
| Informal request | Project controls | Logged after answering, even when trivial | The message | Workload visibility |
The fourth row is the one that is usually missing, and it is the one that decides whether work can start on a drawing returned with comments.
Practical insight
Take the last twenty submittals and write down two dates for each: sent, and returned.
Calculate the actual turnaround. Then compare it with the figure your programme assumes. Most projects find a gap, and most projects have never looked, because the assumption came from the contract at the start and nobody revisited it.
Then look at how many came back approved with comments rather than approved. If it is a large share, your readiness test for drawings is weaker than it appears, and the difference between the two statuses is being decided informally by whoever happens to open the file.
Key takeaways
- The client and the consultant supply duration and permission, not data.
- Turnaround is measurable and usually unplanned. The contractual period is a limit, not a forecast.
- Plan against observed turnaround, not the figure in the contract.
- Approved with comments looks like a decision and is not. Somebody has to read the comments and record what they decided.
- Informal requests carry no record, can't be prioritised, and account for real effort that appears in no plan.
- Answer them, then log them, so the volume becomes visible.
- An instruction has to reach quantities and baseline before the next report, or the report describes a project that has changed.
Records born here. Submittal log with actual turnaround · comment decision record · log of informal requests.
What is coming next
That is every source. From here the track turns round and looks at what you send back, starting with the thing that decides how much of it was measured.
Next week: the calendar — data date, cut-off, and why three departments closing on three different days is the most expensive unexamined decision on a project.
Enjoyed this lesson?
Join with Google to get each new lesson the moment it's published — and help me see which topics matter most to you. No spam, one email a week, unsubscribe anytime.
Already following on LinkedIn works too — this is just for the weekly email.