How To Run A Project Without Chasing People For Updates

Nobody describes running a construction project as doing one thing at a time. The usual phrase is spinning plates and on a normal day the plates are a subcontractor issue, a variation that needs pricing, a design query that has been sitting too long, a client call, plus a safety matter that quite rightly takes priority over all of them. Behind that lot sit the programme, the procurement schedule and three people waiting on decisions, all of which are genuinely urgent to whoever is waiting.

The weekly report is one of those plates. It also happens to be the one with the least immediate consequence for dropping, since nobody rings you the moment it's late, which is why it tends to get picked up last. Usually on a Thursday afternoon and usually assembled from a handful of phone calls, a scroll back through messages and somebody's recollection of a Tuesday that nobody in the room was actually present for.

That isn't a failure of effort. It's the only method available when the detail was never written down anywhere it could be pulled from later and the detail absolutely did exist at the time. Somebody at the gate knew exactly when the truck arrived. Somebody on the floor knew precisely why the pour didn't start. Both of them could have told you in a sentence at four o'clock that afternoon and within a week most of it has faded.

So the Thursday afternoon gets spent gathering fragments that were perfectly clear on Tuesday and what comes out the other end is a sincere description of a week that has already finished, arriving too late to change anything that happened in it.

Being told is not the same as knowing

Most problems reach a project manager through a conversation, which means they arrive when somebody else decides they're worth mentioning.

That's a filter, though not a malicious one. People raise what feels worth raising and they calibrate as they go against how busy you look, so somebody watching you deal with four problems doesn't come over with a fifth that hasn't caused any damage yet. The delivery that turned up ninety minutes late without stopping anything gets absorbed into the day and the trade that waited half a morning only gets mentioned if you happened to be standing there at the time. Neither of them reaches the person who might have noticed both had happened four times that month.

Which is the frustrating part of the plate spinning. It isn't only that there's too much to hold, it's that being visibly busy quietly reduces what people bring you, so the picture you're working from gets thinner exactly when the job gets harder.

What is actually worth tracking weekly

Five things, none of which are extra tasks. That distinction matters, because the last thing anyone in this role needs is another list of jobs to fit in, so each of these should be a by-product of a record somebody on site is already in a position to make.

Whether the work planned actually happened and the reason when it didn't. This is probably the most useful measure available on a construction project, though it's also the one most often left half-done, because recording the reason takes more thought than recording the outcome. Completion on its own gives you the score without telling you anything about the cause.

Whether deliveries arrived inside the window they were booked into. Not simply whether they arrived, since they nearly always turn up eventually. What matters is whether they arrived when the work waiting on them expected them. Most of what a site loses to waiting sits in the gap between those two questions.

Which areas are consuming more programme protection than the work they're producing. Programme health, in other words, tracked zone by zone rather than across the job as a whole, since it tends to move before completion does. That's a subject of its own and it's covered properly in a separate piece.

What the same reason keeps turning out to be. A single blocked task is an anecdote, whereas the same reason appearing eleven times in a month is a finding and it stays completely invisible unless those reasons were recorded consistently enough to be counted.

What would be lost if the site manager left tomorrow. An uncomfortable question, though worth asking honestly, because on most projects the answer amounts to a fair proportion of everything anyone knows about how the job has actually run.

What changes when the detail is already there

The weekly report becomes something you read rather than something you rebuild, which gives back a few hours on a Thursday. The bigger difference is that it takes the plate away rather than making it lighter and there's a real distinction between the two. A lighter plate still has to be watched.

The conversations change as well. Asking a foreman why an area is behind lands very differently when the reasons from the last three weeks are already sitting in front of both of you, because it stops being a question about who is at fault and becomes a question about a pattern that neither of you had spotted.

The information also outlives the week it came from. When somebody asks in November what happened on a particular day in March and somebody always does eventually, the answer is already written down rather than being reassembled from four people's recollections.

Where SiteVector fits

SiteVector records deliveries at the gate in a few taps and logs task outcomes with the reason picked from a fixed list rather than typed out as a sentence. That constraint is deliberate, since free text can be read but it can't be counted, whereas a fixed list can be. Each day locks and is sealed when the site closes.

The site team records the day once and the shift diary is built from what they entered, along with the weekly reports, the supplier performance view and the breakdown of reasons. Nobody sits down to compile any of it, which is the entire point of doing it this way.

It isn't a programme tool, a cost system or a document register and it doesn't replace Procore, Aconex, Jobpac, Cheops or P6. It sits underneath whatever you're already running and hands the ground level detail back in a form those systems can actually use.

The part that outlasts the project

Almost everything a project manager knows about a job is currently stored in the project manager and it leaves when they do, taking the site manager's version, the foreman's version and every explanation that was never written down anywhere.

The next project then starts from roughly where the last one started, which isn't because nobody learned anything. It's because what they learned had nowhere to live.

SiteVector runs on a project already under way for sixty days, with no card and nothing to install. Sixty days is long enough to find out whether the site team finds it quicker than what they're doing now, which is really the only test that matters.