Pilot mobile progress capture with reviewed corrections

Choose a package with clear physical locations and units, such as a defined piping area or floor-level installation scope. Agree WBS/activity mappings, location identifiers, units, work stages and the reporting cutoff. Avoid starting with every discipline and several incompatible measurement conventions.

Decide whether each input is an increment or a cumulative reading. A supervisor entering “80 metres today” and another entering “500 metres to date” must not feed the same addition rule. Label the form accordingly and test a corrected cumulative reading; the system should replace the relevant reading through a versioned correction, not add it as new work.

The site lead owns capture and supervisor review. Quality retains technical acceptance. The planner owns interpretation and import into the programme. The integration owner controls the interface and recovery. If the records also feed billing, the QS needs a separate reviewed mapping; the pilot should not imply that a DPR row is automatically billable.

Include enough ordinary and difficult work to test the process: a partial installation, a repeated location, a correction and an offline shift. Agree the supported devices and languages with the people who will enter the data.

The proposed flow is: mobile observation → field validation → supervisor review → approved progress export → planner review and import. Quality status is linked from its authoritative process, rather than inferred from the supervisor’s completion flag.

Procore’s daily-log documentation illustrates separate operational records and change history. The pilot’s exact review stages should reflect the project’s process, not simply inherit a product’s default meaning of “complete”.

Illustrative example: device A records 30 metres on segment P-17. Device B independently records the same 30 metres. These are different event IDs describing overlapping work. The system should flag the shared segment, stage and date for supervisor review, rather than accepting 60 metres.

After review, one record is linked as duplicate evidence or corrected according to the agreed process. The accepted physical quantity remains 30 metres, and both original observations remain traceable.

Now replay device A’s upload because its acknowledgement was lost. That is the same event, so it should be recognised as a retry without producing another observation. Safe retry design addresses this transport-level problem. It does not, by itself, detect two people describing the same physical work. The pilot needs both controls.

Do not automatically reject every repeated location. Different work stages or items may legitimately share it. The rule should flag likely overlap with enough context for an accountable person to decide.

Suppose reviewed progress of 80 metres is corrected to 76 after a location check. Preserve the original value, reason, reviewer and accepted correction. If the weekly report has already been issued, generate a visible revision or adjustment according to the project’s reporting convention.

Retain the work date and the date the correction was entered. A late correction should not silently rewrite the historical dashboard. Distinguish a recording error from physical removal or rework, because the planner may treat them differently.

Bind supervisor review to the record version. Changing a reviewed value requires renewed review and an alert to any report or export that used it. For a quantity already imported into planning, the planner must know whether the next file replaces an absolute value or supplies an adjustment. Sending 76 as an additional increment would turn a four-metre correction into a substantial overstatement.

For offline work, show whether the device has current activity and location data. If a package mapping changes while a device is disconnected, route its later upload for validation. An old form should not create a new activity because its original code no longer exists.

Start with a reviewed export to the planning system. The planner can compare quantities and mappings before import. For a P6 workflow, its WBS reference documents selectable earned-value methods. Confirm which field the export is meant to update; daily installation quantity, activity completion and earned value are not interchangeable inputs. Preserve the project's chosen method and data date.

Do not let a mobile app automatically rebaseline the schedule or declare technical acceptance. A later automated import should be a separately approved extension with reconciled test evidence, explicit permissions and a recovery procedure.

Use role-based access to restrict project records and attachments. Photos can contain people, drawings or restricted areas; agree what is necessary to collect and how access, retention and device loss will be handled. A progress pilot rarely needs unrestricted access to all project documents.

Baseline report preparation time, supervisor review time, correction effort, late-record frequency and unmatched activity/location rows. Use a fixed set of included crews and workdays. Count failed uploads and rejected records, rather than reporting only successfully completed forms.

During the pilot, compare like-for-like workdays and retain the awkward shifts: poor connectivity, late uploads and returned records. Show whether effort moved from supervisors to the planner, and whether unresolved corrections grew while form completion became faster. Agree any improvement target after the baseline. The acceptance gates are reproducible reviewed quantities, traceability from report to observation, and preservation of review authority. Flagging a real overlap is useful; allowing it to inflate accepted progress is a failure.

Stop expansion if the accepted quantity cannot be reproduced, a duplicate changes progress, an unauthorised user gains access or a review step is bypassed. Pause the affected export, mark the last accepted cutoff and return the team to its controlled reporting process.

Retain raw observations and logs for investigation. The site reviewer resolves physical-record conflicts; the technical owner repairs the interface; the planner reconciles any imported update. Resume only after the failed case is retested and the affected report position is agreed.

1. Define one package’s activity, location and quantity conventions.
2. Baseline capture, review and correction effort.
3. Test both duplicate events and duplicate descriptions of work.
4. Run reviewed daily capture and a controlled planning export.
5. Expand only after the site lead, quality owner and planner accept their parts of the workflow.

When discussing mobile capture, start with a typical reporting shift: how many supervisors contribute, where connectivity fails and who consolidates the DPR. Add the package and planning tool to make the first trial specific.