It arrives next week. It has arrived next week for two months
An activity in the look-ahead depends on a piece of equipment. Every week the question is asked, and every week the answer is that it arrives next week.
Nobody is lying. Each answer was the best information available on the day it was given, and the date genuinely was next week each time somebody said it.
The problem isn't the slippage. It is that the programme still shows the date it slipped from, because a revised delivery date is a piece of information that has no defined route
from procurement into the schedule.
The list and the people
Mature projects have an expediting report or a procurement status report. It is real, it is maintained, and it is usually behind.
The live information sits with people. Somebody in procurement had a call with the vendor yesterday and knows the shipment has not left. That knowledge reaches the report at the next update cycle, and reaches the planner when somebody thinks to mention it, which is why planners on well-run projects still spend a lot of time in procurement's office.
This isn't a criticism of the report. Any status document describes a moment that has passed. What it means is that the report is the record and the conversation is the input, and a planner who relies only on the first is always a cycle late.
The date that goes in the programme
Which of the dates should a planner plan against? Not the original one, which is a commitment rather than a forecast. Not the latest verbal one either, if it has moved three times.
What matters is the last date somebody is willing to stand behind with a reason. A date backed by a shipping document, a manufacturing completion, a confirmed booking, is different in kind from one that is simply the previous date plus a week.
Two fields make this visible: the current promised date, and how many times it has moved. An item on its fourth revision is a different risk from one on its first
, and the count costs nothing to keep.
One chain, three departments
The larger problem is that procurement isn't one process but three, watched by three groups who each see their own part.
Engineering follows the vendor documents: the drawings and data the supplier has to produce and get approved before manufacturing can start. Procurement follows the order and the shipment. Construction cares only about the date the item is on site and ready to install.
These are links in one chain.
An approval sitting for three weeks on the engineering side delays manufacturing, which delays shipment, which delays installation. But because each department tracks its own segment, the delay is usually visible only at the end, when it appears as a late delivery rather than as a late approval two months earlier.
Reconstructing that chain is planning work and nobody else will do it. It is also where the earliest warning on a plant project comes from, well before anything shows in a progress figure.
Four documents that already exist
If you are building the report, use one line per critical item, with the four dates that matter — vendor documents approved, manufacturing complete, on site, released to construction — and a revision count against the promised date.
Inherited: the report exists in some form. Rather than replacing it, add the revision count. It is one column, it requires no new source, and it converts a status list into a risk list within two months.
System design
One line per critical item, four dates, and a count. The count is the field that turns a status report into a risk report.
| Record | Produced by | Required quality | Verified against | Feeds |
|---|---|---|---|---|
| Vendor documents approved | Engineering | Dated, with the approval status | Transmittal record | Manufacturing release |
| Manufacturing complete | Procurement | Confirmed by the vendor, not assumed | Vendor confirmation | Shipment forecast |
| On site | Logistics | Date of arrival and acceptance | Delivery note | Readiness test |
| Promised date | Procurement | Backed by a document or a booking, not last week plus seven | Shipping record | Programme |
| Times revised | Project controls | A count kept from the first promise | The date history | Risk register, forecast |
Rows one to three are the chain three departments watch separately. Putting them on one line is what makes a late approval visible before it becomes a late delivery.
Practical insight
Take the ten items on the critical path with the longest lead times. For each, find the delivery date in the current programme and the date procurement is currently working to.
Count how many differ. On most projects it is more than half, and the reason isn't carelessness — there is simply no defined moment at which a revised date becomes a programme change.
Making that moment explicit, even monthly, is worth more than any improvement to the report itself.
Key takeaways
- The expediting report is the record. The live information is with people, and it arrives earlier.
- The failure isn't slippage. It is that no defined route exists from a revised date into the programme.
- Plan against the last date somebody will stand behind with a reason, not the first commitment.
- Count how many times a date has moved. A fourth revision is a different risk from a first.
- Vendor documents, manufacturing and delivery are one chain watched by three departments.
- A delayed approval appears months later as a late delivery, and the connection is rarely made.
- Reconstructing that chain is the earliest warning available on a plant project.
Records born here. Expediting report with revision count · long lead register · the chain view per critical item.
What is coming next
Material and drawings release work. One department can stop it entirely, and it doesn't report to project controls.
Next week: permits, safety holds and stand-downs — lost time as a delay event with a record behind it.
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.