Building a Defensible Project Record

The project record is the memory of the contract. When the relationship is healthy, records may feel administrative. When a claim arises, records become evidence. The difference between a manageable commercial issue and a prolonged dispute often lies in the quality of records created before anyone expected a dispute.

A defensible project record is not a warehouse of documents. It is an organised, contemporaneous, reliable and retrievable account of what happened, when it happened, who was responsible, what was decided, what changed, what was delayed, what resources were used, what cost was incurred and what contractual action followed.

Contemporaneous records carry weight because they were created at or near the time of the event. They are less likely to be viewed as advocacy. They often show what the project team knew, what it did, and how it understood the event before commercial positions hardened.

Common examples include daily reports, site diaries, photographs, inspection records, delivery tickets, plant and labour returns, meeting minutes, correspondence, drawings, RFIs, submittals, approvals, cost reports, schedule updates, change registers, risk registers, non-conformance reports, test records and commissioning records.

A good record system is designed around future questions:

• What was the planned obligation?
• What actually happened?
• When did it happen?
• Who caused or controlled it?
• What activities were affected?
• What resources were affected?
• What decisions were made?
• What notices were issued?
• What mitigation was attempted?
• What time or cost impact resulted?

If records do not answer these questions, they may be voluminous but not useful.

Many projects confuse storage with evidence. A cloud folder full of files is not a defensible record. The records must be named, dated, version-controlled, indexed and connected to issues. Without structure, the cost of reconstructing the project history becomes enormous.

The best systems use registers. A drawing register, correspondence register, RFI register, change register, claim register, delay event register, instruction register, payment register and risk register create the skeleton of the project record. Documents then attach to those registers.

Daily reports are often undervalued. They should record work areas, activities, manpower, plant, weather, access constraints, deliveries, visitors, instructions, safety events, inspections, disruptions, delays and photographs. The language should be factual, not emotional. A report stating “delay due to employer failure” is less useful than a report identifying the exact access gate, activity, crew, time period, instruction or missing drawing.

Meeting minutes should record decisions, not just discussion. Each action should have an owner and due date. Commercial reservations should not be hidden. If a party disagrees with the minutes, the disagreement should be recorded promptly. Silence can later be argued as acceptance.

Photographs are powerful but easily weakened. They should be dated, located and connected to the relevant activity or issue. A photograph without context may be attractive but evidentially limited. Project teams should consider recurring photo points, drone captures, progress overlays and issue-specific image logs.

Claims for prolongation, disruption, acceleration or variation cost require cost evidence. Timesheets, plant logs, invoices, payroll records, subcontractor accounts, material invoices, site overhead records, supervision costs and equipment records should be captured in a way that allows allocation to events. If costs are only available at a high level, causation and valuation become difficult.

Digital workflows can improve records if configured properly. They can also create false confidence. A system must preserve audit trails, version history, approval status, timestamps, user identity, attachments and status changes. If people bypass the system through informal messaging, private emails or unrecorded meetings, the digital platform becomes incomplete.

The project record is weak when:

• Daily reports use generic language
• Meeting minutes are issued late
• Registers are not updated
• Notices are not linked to events
• Photographs lack date or location
• Programme updates are not archived
• Instructions are given verbally
• WhatsApp or informal messages replace formal communication
• Cost records cannot be allocated to events
• Different teams maintain different versions of the truth