Construction project management: the complete guide for contractors

What construction project management actually covers

The common description — "delivering the project on time and on budget" — is true and useless, because it describes the outcome rather than the work. The work itself is a series of records that have to be written as they happen: who turned up today, what was built against which line, what materials arrived, what was approved and what was rejected, and what is waiting on somebody's answer.

And each of the ten consumes another's output: a payment application reads percent complete, percent complete is measured against bill-of-quantities lines, those lines are built by tasks with a programme, and the programme slips because an RFI is unanswered. That interlock is the reason construction management systems exist at all — not because every discipline needs a screen, but because separating them creates contradictions that only surface late.

Scope: the bill of quantities is the spine

Everything else is measured against the bill of quantities. The line is the unit progress is measured in, payment is calculated on, spend is attributed to, and material consumption is compared against. Which is why a project carrying a single lump-sum budget with no lines can know that it is over, and cannot know where.

The common failure is pricing the BOQ once at tender and never opening it again until a payment application is due. Used properly it is a live record: executed quantities recorded weekly per line, so a line running past its contracted quantity shows up in its own week instead of six months later.

Time: a schedule that moves when the site moves

A schedule is a network of logic, not a list of dates. The practical test is simple: push the first activity two weeks later, and if the handover date does not move, what you have is a drawing of a schedule. Dependencies — in their four types, with lag and lead — are what make the finish date derived from the network rather than typed beside it.

From that network comes the critical path: the activities whose total float is zero. The baseline is what later lets you prove what slipped — with no frozen snapshot of the approved plan, a live schedule rewrites itself and no measurable gap survives for an extension-of-time claim to be built on.

Cost: a closed loop, not a month-end report

Cost control is not a report assembled at month end, it is a loop: a budget with lines, actual cost reaching those lines as it happens, and progress measured against them. The only number that helps is the loop's output — what was spent against what was built — because spend alone says nothing about performance.

And because overruns accumulate from small gaps, a system is worth what it takes off the delay between a gap occurring and being seen: unpriced work, the difference between ordered and received, hours never reaching a cost line, material waste that appears on no invoice. Every one of them was visible in its own week.

Procurement and materials: three numbers that must cross

Every material entering a project carries three numbers: what the purchase order asked for, what the store received, and what the invoice claimed. Crossing them is the difference between "we paid what was invoiced" and "we paid for what we received". Its one precondition is that the receipt is an independent source — a receipt copied from the invoice makes the match pass permanently and catch nothing.

After receipt comes the part most systems skip: stock. A balance belongs to a specific site rather than to the company, its value is carried at a moving average cost, and issue is tied to a task so consumed can later be compared with expected — the only comparison that reveals waste.

Quality and safety: what closes, not what gets logged

An inspection is worth what its timing is worth: inspecting before the work is covered prevents rework, inspecting after it documents a problem. Safety runs on the same logic — a near miss is the full sequence of a serious accident without its outcome, the only lesson that arrives free. Both depend on recording being easier than not recording.

And the real metric in both is not how much was logged but how much closed: how many non-conformances closed with a documented rectification? How many corrective actions are past their due date? A register full of open items is not a quality system, it is a waiting list.

Documents: the revision people build from

RFIs and submittals are not administrative mail, they are waiting items in the programme. A question open for three weeks is stopped work on site, and approval turnaround belongs directly inside the duration of the activity depending on it. Recording the date raised and the date answered is what turns a wait from a complaint into a documented cause.

With drawings the error is more expensive: building from a superseded revision is complete rework. Which is why withdrawing the old revision is part of issuing the new one, not a separate step somebody is supposed to remember.

Roles: whoever records is not whoever approves

The most important organisational rule on a project is simple: the person doing the work does not approve it. The foreman who witnesses the work writes the daily report and a manager approves it; the storekeeper raises the material request and whoever owns the spend approves it; the engineer raises the change order and somebody else agrees it. Merging both roles turns an approval into a signature on oneself.

That separation does not run on policy alone, it runs on permissions: a system where any user can do anything makes the rule a verbal agreement. Alongside it there has to be an audit trail recording who changed what and when, because most project disputes are disagreements about the order of events rather than whether they happened.

Getting paid: the profitable project that runs out of cash

A contractor profitable on paper can still stop, because payment applications settle after 60 days while wages and suppliers fall due monthly. So a payment application is not an accounting exercise but an operational one: documented percent complete, calculated retention, approved variations included, and backup that makes rejection difficult.

And the same discipline has to travel one level down: paying subcontractors against a schedule of values that equals their contract exactly, rather than off a phone call. Retention is withheld in both directions, and the squeeze in the middle is real.

What a system actually has to do

Most comparisons between construction management systems are argued on feature counts, which is a weak criterion. The questions that genuinely separate a system that gets used from one that gets bought and abandoned are few:

1. 1Does field entry work with no signal? A site without coverage is the rule, not the exception.
2. 2Does it separate who records from who approves, with real permissions?
3. 3Does it keep an audit trail that cannot be edited?
4. 4Are records linked — does the change order know its budget line, does the payment know its progress?
5. 5Does it genuinely work in both languages, with two fields per record, not just a translated interface?
6. 6Can the site team use it from a phone without lengthy training?

Frequently asked questions