How to Run a Procurement Log So Long-Lead Materials Arrive Before the Crew Does

The three-week look-ahead says pile driving starts on the 22nd. The barge is booked, the crane is coming off another job that Friday, and the crew has been told. Then the supplier calls: the pipe piles are still at the mill, coating is another two weeks after that, and trucking to the dock is a week on top. The purchase order went out in June, which felt early at the time. Nobody had worked out that June was already three weeks late.

This is how long-lead materials break a schedule. Not because the lead time was a secret, but because the order date was decided by when somebody got around to it, not by when the crew needed the material in their hands. The fix is a procurement log that runs backwards from the need-by date, and a weekly habit of reading it.

Why orders go out late on jobs that look organised

The project schedule shows install dates. It rarely shows the date you have to release the order to hit them, and it almost never shows the date the shop drawings have to go in for the order to be releasable. Those two dates live in someone's head, usually the PM's, and a PM's head is full.

Three things compound it. The lead time everyone is working from was quoted at tender, by a supplier who was pricing a different quarter. The submittal cycle gets counted as zero, when a consultant's review plus one resubmittal can eat a month. And ownership is split: the estimator bought the item, the sub is supplying it, the PM is scheduling it, and each assumes one of the others is watching the calendar.

Work backwards from four dates

For every item that matters, the log carries four dates, calculated from the end:

1. Install date. When the crew actually puts it in. This comes from the schedule and moves when the schedule moves.
2. Required on site. Install date minus a buffer. A few days for something you can stage anywhere, longer for anything that has to be inspected, coated, or loaded onto a barge first.
3. Release date. Required-on-site date minus the lead time, including shipping. This is the last day you can tell the supplier to go.
4. Submittal due. Release date minus your contract's review period, minus an allowance for one resubmittal. Suppliers won't start fabrication on an unapproved shop drawing, so this is the real start of the clock.

A hypothetical to make it concrete. Fabricated steel needed on site November 3. Eight weeks in the shop plus a week to ship puts the release date at August 31. The contract gives the consultant ten business days to review, and you budget one resubmittal, so the shop drawings need to be in by mid-July. In mid-July nobody on the job is thinking about November. That's the whole point of the log: it thinks about November for you.

Which items belong on it? Anything with a lead time longer than the window you plan in. If you run a three-week look-ahead, anything over three weeks needs a row, because it can't be caught by the look-ahead alone. On a civil or marine job that's piles, fabricated steel, precast, timbers of any real size, coatings, specialty hardware, and anything crossing a border.

What the log actually needs

One row per item, not per purchase order, because one PO can carry six items with six different lead times. Columns that earn their place:

• Item, spec section, quantity
• Supplier or sub, and the one person on your side who owns the row
• Submittal due, sent, returned, and status (approved, revise and resubmit, rejected)
• Lead time as quoted, and the date it was quoted
• Release date required, PO number, release date actual
• Ship date, required-on-site date, delivered date
• Where it's going when it lands: site, laydown yard, supplier's yard, barge

That last column matters more in marine work than people expect. A pile "delivered" to a laydown yard in Delta is not on the job until it's trucked, loaded, and towed, and the tow has its own weather window. Count the whole trip as lead time.

The column people skip is the date the lead time was quoted. A number from tender is stale by award. Re-confirm at award, again before release, and write down when you asked. When a supplier's eight weeks becomes fourteen, you want to know on the day it changed, not the day the crew shows up.

Run it by release date, not by item

A log sorted alphabetically is a filing system. Sorted by release date, it's an agenda. Every week, the rows whose release date falls inside the next four weeks and whose status isn't "released" are the conversation. Same for submittals due inside the next four weeks that haven't gone in. Everything else is background.

This is the same discipline as the RFI log we wrote about, applied to material instead of answers: the date that matters is the date the crew needs it, and the log's job is to count backwards from that date and start making noise early enough to do something. The look-ahead's "is the material on site" constraint should be read straight off this log, not from someone's memory of the last supplier call.

One owner per row, named. Not "procurement" or "the office". A person whose job on Friday is to say yes it's released, or no and here's the new date.

The BC wrinkle: windows, not weeks

On land, a late delivery costs you the days it was late. In the water, it can cost you the season. Instream and marine work in BC runs inside reduced-risk timing windows that vary by region and species, and a pile that lands two weeks after the window closes waits for the next one. Barge and crane availability stack on top: the equipment you booked doesn't sit idle for free while the material catches up.

So the buffer on marine long-lead items isn't a few days. It's set by the window. Work out the last day the material can arrive and still get installed inside the window, and treat that as required-on-site, whatever the schedule says the install date is.

Where the spreadsheet holds and where it breaks

A spreadsheet is fine for this. A mid-size civil job might carry twenty to forty long-lead rows, and one sheet with the columns above, sorted by release date, run in a weekly meeting, beats most software that isn't being used. The rule is that the dates are calculated, not typed: install date comes from the schedule, and the three dates behind it are formulas. Retyping dates is how a log drifts from the schedule without anyone noticing.

It breaks in two predictable places. When the submittal log lives in the consultant's portal and the procurement log lives on your server, someone is copying dates between them, and they stop. And when the same supplier feeds three of your jobs, three PMs are each keeping their own version of that supplier's lead time. If you're already on a platform that carries a procurement log, use it and connect it to the schedule. Buying software just for this is rarely worth it; fixing the ownership and the arithmetic usually is.

If your jobs keep discovering lead times the week the crew mobilises, the cause is usually how the dates are set up, not the people. That's the kind of thing we work through in a discovery call: which items need a row, who owns it, and what it takes to wire the log to the schedule you already run.