Construction dashboard: 12 data points that need an owner
Łukasz Mikucki · Published Jul 20, 2026 · 8 min read
Most construction dashboards die the same way: for two months they look great, then someone notices that progress on one of the work fronts has been sitting at the same value for three weeks. Not because the works stopped — because the person entering the number stopped, and nobody noticed, since the field had no owner.
A field's owner is a role, not a named individual, accountable for the value being current and correct. A role survives a vacation, a change on the contract, and a person leaving the company.
How to read this list
Each field is described by its technical name, type, responsible role, and where the value comes from. The list is minimal — it does not cover everything that can be measured, only what the cockpit cannot stay credible without.
The technical names are our own — but every field has a counterpart in the contract documentation, and wherever such a counterpart exists, we name it explicitly. This is not decoration: a dashboard whose fields cannot be mapped onto the artifacts the employer requires will sooner or later start living next to the settlement instead of with it.
Layer 1 — where we are
work_frontreferenceowner: Contract managerThe shared dimension for all the other data. Without it, progress, materials, and acceptances cannot be combined. Definition: work front.
quantity_completednumber + unitowner: Works managerThe actual quantity, linked to a bill-of-quantities item. Source: as-built measurement, not a percentage estimate. Contract counterpart: „Rejestr obmiarów” (the measurement register). The GDDKiA specification describes it as a document that allows "the actual progress of each element of the works" to be settled, kept continuously, in the units adopted in the bill of quantities — with entries made by the Site Manager and confirmed by the Engineer. If your field lacks that confirmation, you have a number, not a basis for settlement.
event_datedateowner: Works managerWhen the works were performed — not when someone got around to entering them. Confusing these two dates is the most common source of false progress "jumps" on charts.
schedule_itemreferenceowner: PlannerThe link to the directive schedule. Without it you can compute progress, but not deviation.
Layer 2 — what is accepted and settled
acceptance_statusconfigurable enumowner: Engineer / works managerAn enum, never a free-text field — otherwise after six months you have twenty variants of the word "ok". But note: the values of this enum cannot be hard-coded. The GDDKiA specification lists four acceptance types (works that become hidden or covered up, partial, final, post-warranty). The PKP PLK PFU — six, with its own definitions, including the operational acceptance („odbiór eksploatacyjny”), after which the commission "determines the necessary restrictions for train traffic". The CPK OPW has no acceptance chapter at all. Three contracts, three different status dictionaries.
protocol_datedateowner: Commercial departmentThe date of the acceptance protocol. The starting point of the payment and warranty deadlines.
protocol_scopereferenceowner: Commercial departmentAn unambiguous statement of what the protocol covers: a BoQ item, a structure, or a work front. A verbal description is not enough for settlement. On a GDDKiA contract, partial acceptance has a document of its own — the Świadectwo Przejęcia (Taking-Over Certificate), issued by the Engineer under the sub-clauses on taking over the Works and Sections — while final acceptance is confirmed by a final works acceptance protocol drawn up to the Employer's template. Two different artifacts, and the register must tell them apart.
invoiced_valueamountowner: Commercial departmentCompared against the quantity completed. A gap between "completed" and "invoiced" is the earliest signal of trouble in contract settlement.
Layer 3 — what is blocking
material_statusenumowner: Procurement / works managerOrdered / delivered / approved / installed — four separate states, not one "quantity" column. Details: material register.
approval_stepenumowner: SystemWhich stage of the approval workflow the case is at. Answers the question "who holds the decision right now".
step_entry_datedateowner: SystemLets you measure idle time instead of guessing it. One of the cheapest fields with the highest analytical payoff.
schedule_riskenum + justificationowner: Contract managerAn expert judgment — but with a mandatory justification and date. The only field on this list that is an opinion, and precisely for that reason it must be clearly labeled as one.
Three rules without which the list will not work
Two roles responsible for the same field means zero roles responsible. Competence disputes are resolved at process-design time, not after go-live.
A field filled in only for head office degrades within a few weeks. If the data serves no purpose for the person entering it, either change the field or change the process.
Every dashboard tile shows when its data was last refreshed. A stale number without a date is worse than no number, because it looks exactly like a current one.
What this list deliberately leaves out
There are no synthetic indicators like "overall contract health in percent". Not because they are useless — but because they are computed from the fields above. An indicator built on data without owners inherits all of their flaws and additionally hides them behind one tidy number.
The order is always the same: field owners first, then the register, then the charts. The reverse order produces a cockpit nobody looks at after a quarter.
Sources
The substantive basis of this text. Items marked as own practice do not come from a document — they are delivery experience that cannot be verified with a publisher.
- DocumentGeneralny Dyrektor Dróg Krajowych i Autostrad / GDDKiA Oddział w KatowicachSTWiORB DM.00.00.00 (GDDKiA technical specification, in Polish), item 6.7.2 — „Rejestr obmiarów” (the measurement register): entries made by the Site Manager, confirmed by the Engineer (p. 31)
- DocumentPKP Polskie Linie Kolejowe S.A.PFU (TOM III SWZ) (PKP PLK employer's requirements, in Polish) — a catalog of six acceptance types with definitions (pp. 104–106)
- Own practiceObservations from building registers and management reporting on infrastructure contracts
Terms used in this article
Related articles
Excel or a custom application — where the break-even point lies
When a spreadsheet stops being enough in a construction process and how to tell. Decision criteria, hidden spreadsheet costs, and when a custom application pays off.
Where information gets lost in construction document flow
Seven points where information on an infrastructure contract disappears or loses credibility — and what can be done about them without deploying a system.