Construction progress tracking software covers two connected things. The daily progress report, which records what happened on a site on a given day, and physical progress, which says where the project stands against what was planned. The first is the input and the second is what it should produce, and in most companies the connection between them does not exist. With Pentoggle, a contractor can describe its DPR format and programme structure and generate the starting application around them.
The DPR is usually already being produced. On many contracts it is a contractual obligation, submitted to the client or the project management consultant, and it contains manpower by trade, machinery deployed, material received and consumed, work executed, hindrances, instructions and incidents. It can be one of the richest daily records a construction business generates.
Many contractors already run Tally or a comparable system for accounting and a scheduling tool for the programme. What sits outside both is the daily record, and the scheduling tool holds a plan that is only as good as what gets fed back into it.
Key takeaways
- The DPR is usually written to satisfy a contract clause and then never read again, which wastes a dataset the site is already collecting.
- Percentage complete depends on the measurement method. Quantity- or value-weighted physical progress can give a stronger picture of work actually executed than counting activities or elapsed days, provided the weighting method is defined and applied consistently.
- Progress against plan requires a baseline that was preserved. Where the original programme is overwritten by revisions, it becomes difficult to say what slipped.
- The hindrance field is the most valuable part of a DPR and the least completed.
- A useful number is physical progress against planned progress, computed on the project's defined weighting basis, at a stated cut-off date.
The DPR is a write-only document
Many construction sites produce one. Very few companies ever read one after the day it was submitted.
It is treated as compliance. The contract requires a daily report, somebody fills it in the evening, it goes to the client, and a copy is filed. When a question arises three months later about what happened on a particular week, the answer is technically in a folder and practically unavailable, because it is ninety loose pages and nobody is going to read them.
This is a waste of something unusual. The DPR already contains, for every single day, how many people of each trade were on site and under which contractor, what machinery was deployed, what material arrived and what was used, what work was executed and where, and what stopped. There is no other document in construction with that density, and the cost of collecting it has already been paid.
Making it queryable is the cheapest large improvement available to most contractors, because it does not require anybody to do additional work. It requires the same entry to be made in a form that can be added up. The site fills what it already fills. The difference is that afterwards you can ask how many mason-days went into the fifth floor, or which weeks lost time to drawing delays, or what the manpower trend for a particular subcontractor has been.
That last point is worth stating plainly. Several numbers that are hard to produce any other way, including labour productivity, material consumption against theoretical and machine utilisation, are computable from data the DPR already carries. The obstacle is the format, not the collection.
What progress tracking software holds
The daily entry
Manpower by trade and by contractor, machinery deployed, material received and consumed, work executed by activity and location, weather, visitors and instructions.
Planned quantity against executed quantity
What was planned by date and what was actually done, in the units the activity is measured in, tied to the location and the item it belongs to, so progress is derived from the underlying data rather than entered as a percentage.
Hindrances
What stopped or slowed work, the affected activity or work front, start and clearance dates, the party responsible or affected, and the supporting record, captured on the day.
The approved baseline programme
The plan as originally agreed, preserved separately from revised and recovery programmes, with each revision carrying its number, date, reason and approver, so progress can be reported against both the baseline and the current programme.
Physical progress using the project's defined weighting
Progress computed using the project's defined methodology, such as value- or quantity-based weighting, with the basis documented and applied consistently.
Planned against actual
Progress on a stated date against what the programme said, at project, package and activity level.
Safety and incident entries
Inductions, toolbox talks, permits and any incidents, held with the day they occurred.
Submission record
What was sent to the client or PMC and when, since on many contracts the DPR is itself a contractual deliverable.
Percentage complete is the most abused number in construction
A project reported at ninety percent for four months is a familiar joke and it comes from a real methodological problem.
There are three common ways to compute progress and they give different answers. Counting activities treats a foundation and a coat of paint as equal units. Elapsed time treats the calendar as a proxy for work, which it is not. Weighting progress by executed quantity or an appropriate value basis generally gives a closer representation of physical work completed than counting activities or elapsed time.
The first two are popular because they are easy and because they flatter. Activity counting moves quickly at the start of a project when many small items get ticked off. Elapsed time measures the passage of the programme rather than the amount of work physically completed, so it should not be treated as a substitute for physical progress.
At project level, physical progress can be calculated by assigning each activity a defined weight and applying its measured percentage complete to that weight. The weighting basis should match the project's agreed progress methodology rather than being assumed universally.
Weighted progress is harder in one respect, which is that it requires quantities. The executed quantity has to come from somewhere, and the reliable source is measurement rather than a supervisor's estimate. Where the two are connected, progress is a derived figure rather than an opinion. Where they are not, progress is somebody's judgement, and judgement about one's own performance drifts optimistic in a consistent direction.
That drift is worth naming rather than moralising about. A site engineer reporting progress is reporting on their own work to people who will judge them by it, under pressure to show movement. Nobody is lying. The estimate is simply made generously, week after week, until the gap between reported and actual becomes too large to close and surfaces all at once late in the project, at the point where it is most expensive.
Progress against plan needs a plan you did not overwrite
Slippage is difficult to state without a baseline. On some projects the original programme is effectively replaced in day-to-day reporting by successive revisions, and if the original approved baseline is not preserved it becomes difficult to quantify subsequent slippage against the position that was originally agreed.
The pattern is ordinary. The programme is prepared and agreed. The project falls behind. A revised programme is prepared showing how the remaining work will be completed, and it replaces the original in the file everyone uses. This happens again. By the middle of the project the only surviving plan is the most recent revision, against which the project is, by construction, roughly on track.
The consequence is that the question of how much time has been lost, and to what, becomes unanswerable from the company's own records. That matters commercially wherever entitlement to time depends on demonstrating what was planned, what happened and why, though whether any entitlement arises is a contract question for your contracts team rather than a matter of record keeping alone.
Keeping the baseline is a filing discipline more than a software feature. The original programme preserved and untouched, each revision kept separately with its date and the reason, and progress reported against both. It costs nothing at the time and is impossible to recreate later.
Hindrances are the field everybody skips
The hindrance section of a DPR is usually blank or contains a word.
It is one of the most valuable fields on the form. It is where work fronts not available, material not received, drawings awaited, approvals pending, another agency in the way, weather and power failures get recorded, and it is often the only contemporaneous record of why a project is where it is. For time-related claims, the record is most useful when it identifies the affected activity or work front, start and clearance dates, and the contemporaneous evidence supporting the event.
Hindrance records can support later assessment of delay and any contractual entitlement to additional time, but the entitlement itself depends on the contract, causation, programme impact and the required notices.
It gets skipped for understandable reasons. Filling it feels like documenting failure, and on a day when several small things went wrong it is tedious. The person filling the form is often the person the entries implicitly reflect on.
Two changes make it more likely to be completed. The first is making it structured rather than free text, so the entry is a reason selected, a location, a duration and an optional note, which takes seconds. The second is making the output visible, so the site team sees hindrance patterns being used to unblock things rather than disappearing into a file. A site that has seen drawing delays escalated because the DPR quantified the time lost to them will be more inclined to fill the field the following month.
The infrastructure and MEP guides cover what this record is worth in businesses where blocked access is a structural feature rather than an occasional event.
Where progress tracking looks different by business type
- Infrastructure and Road Contractor Software, where progress is reported by stretch and layer along a chainage rather than by floor.
- General Contractor Software, where the DPR consolidates the work of several firms on one site.
- MEP Contractor Software, where progress depends heavily on access granted by other trades.
- Interior Fit-Out Contractor Software, where programmes are short enough that a week of slippage is material.
- Home Builder Software, where progress is also what the owner is waiting to hear about.
Why contractors choose Pentoggle for progress tracking
The DPR your client already expects
Your existing format, filled on a phone at site, submitted as required and queryable afterwards.
Progress using your defined methodology
Derived from the project's agreed progress methodology and underlying execution data rather than an arbitrary activity count or unsupported estimate.
Baseline preserved
The original programme kept alongside revisions, so slippage can be stated rather than argued.
Hindrances in seconds
Structured entry so the field actually gets completed, and visible enough that completing it feels worthwhile.
Works alongside your scheduling tool
Programme software keeps the plan. This holds what actually happened.
A useful number for progress tracking
Physical progress against planned progress, computed on the project's defined weighting basis, at a stated cut-off date.
The two qualifications carry most of the weight. A defined weighting basis, so a hundred small activities do not outrank a structure. At a stated cut-off, because progress figures compared across different dates are an easy way to report something misleading without intending to.
Read it at package level rather than as a project total. A project two percent behind overall may contain one package eleven weeks late that will determine the completion date, and the total conceals exactly the thing worth knowing.
The number depends on quantities coming from measurement rather than estimation, and on the baseline still existing. Where progress is self-reported and the baseline has been overwritten, the figure will still compute and will describe a project that does not exist, which is worse than having no figure at all.
Ready to build progress tracking software?
Your sites have been collecting the answer every evening for years. It just went into a folder.
Related resources
- Measurement and Quantity Tracking Software →
- Construction Site Management Software →
- Construction Project Management Software →
- Construction Labour Management Software →
- Construction Cost and Budget Management Software →
- Construction Client Communication Software →
- AI Software for Construction Companies →