Outside Plant Construction Software Problems: The 5 That Keep Your Production Unbilled

Why does the scope of an outside plant build get set too small so often?

The brief usually arrives as a field reporting brief: foremen are texting footage into a group chat, so give them a form. What gets built is a daily report application with a task list, a percent complete field and a photo upload. It is genuinely better than the group chat and it does not move the number the owner cares about, which is how much production is billable this week.

The reason is that fiber construction is paid in units and the unit is the atom. A production entry is a quantity of a specific pay item, at a specific location expressed as a station range or coordinate, on a specific date, by a specific crew, against a specific work order under a specific program. Everything else in the system, billing, production reporting, subcontractor payment, program progress, is a view of that record. If the atom is a task, none of those views can be derived and each one becomes its own spreadsheet again.

The fix is a test you can run in the first meeting. Give a candidate developer your actual unit price schedule and ask them to model three items on a whiteboard, including one with a conditional rate. A developer who has done this asks how partial units are measured, whether the rate changes by jurisdiction, and what evidence the owner requires before a unit is payable. A developer who reaches for a task list with a completion percentage is going to learn unit price contracting on your budget, and you will find out during the first pay application cycle.

What goes wrong when the pay item schedule and design data come in?

The pay item schedule looks like a spreadsheet you can import and is actually a set of definitions that mostly live in two people's heads. The line says directional bore, and what nobody wrote down is the minimum measurement increment, whether a driveway crossing splits out, whether the rate changes in a particular municipality, whether a partial run counts, and what evidence the owner accepts before the unit is payable. Import the schedule without those rules and the system produces quantities that do not survive owner verification, which is exactly the failure you were trying to end.

Design data is the second problem. If your plans arrive as portable document files rather than as structured data, capturing redlines against them takes considerably more engineering than anyone assumes, because there is nothing in the file for a redline to attach to. Teams that discover this in week nine either accept a weaker redline capture or absorb a schedule hit.

The fix is to write the definitions down before the build rather than during it. Sit your project manager and your billing clerk in a room and produce a pay item catalogue with measurement rules, jurisdictional variations and evidence requirements per item. Contractors who arrive with that move considerably faster. On design, establish in the first two weeks what form your plans take for each owner, and scope redline capture accordingly rather than assuming structured data exists.

Why do the integrations that matter here break after launch?

Three connections carry the value and each fails differently. The locate ticket system you already use for 811 requests is the one worth doing first, because damage events are among the least controlled costs in outside plant work and a claim file that assembles itself beats one reconstructed from email six weeks later. It breaks when ticket formats or reference conventions change and nothing errors, so damages stop attaching to runs while the integration reports itself healthy.

Accounting breaks at the boundary between approved production and invoice lines. If the mapping aggregates pay items before they reach the accounting system, per item reconciliation dies there and you lose the ability to explain a rejected line back to the units that produced it.

The owner records system is the hardest. Writing into someone else's inventory or geographic information system correctly is real work, testing requires their cooperation, and their attribute expectations are nowhere documented in full.

The fix in all three is the same posture: name the specific system and interface in the contract rather than accepting a claim about supporting integrations, monitor on volume rather than only on error, and route anything unmappable to a human queue. For the owner system, get their engineering contact into the project early, because the constraint is their availability rather than your developer's.

What happens when restoration, permits and damages are not covered?

These three get deferred because they feel like punch list items, and they are the reason units sit unbilled.

Permits should gate the money rather than sit beside it. Model each permit with its jurisdiction, its conditions, its expiry and the pay items it authorises, so a production entry in a location with no open permit is flagged the same day rather than at month end. Inspection sign off should attach to the specific units it covers, so a partial approval releases partial billing instead of holding the whole run while two handholes get reset to grade.

Restoration deserves its own track because it behaves differently from everything else. It happens weeks later, often by a different crew or vendor, in a different weather window, and it is frequently the last thing standing between you and a closed permit. Give it its own backlog with an ageing view, because an unrestored trench in a municipality about to review your next permit application is a business risk rather than a punch item.

Damages sit alongside both. A strike at station 14 becomes a ticket, then a claim, and if the event is not attached to the specific bore or trench run with its photographs, crew and timestamps, the claim file gets rebuilt from memory. The fix for all three is to make them states on the same pay item record rather than separate lists, so one query answers which units are billable, which are blocked and by what. That query is why contractors fund these projects, because it surfaces blockers while a crew is still nearby.

Should you build custom or configure what you already own?

If you run two crews on one program for one owner, do not build. Well designed forms and a shared drive still work at that size, and the money is better spent on equipment or another crew.

Be accurate about the products, because several are credible and some contractors should simply use them. Sitetracker is strong at portfolio and site level program tracking and earns its place on carrier deployment programs where the unit of work is a site. Render Networks is built around production and works well where the design is complete and the work is broken into predefined tasks. Vitruvi is aimed squarely at this space. IQGeo is excellent at network records and spatial data, which is a genuinely different job from construction production.

Contractors hit the same three limits regardless of which they chose. Bespoke unit price schedules varying by owner and municipality, changing mid program when an owner adds an item. As built delivery into each owner's own format, attribute names, coordinate system and file structure, where a generic export becomes a week of rework and three owners means three translation processes maintained by hand. And multi tier subcontracting, where the unit you bill up is priced differently from the unit you pay down.

The signal is simple: if you keep a spreadsheet next to the tool for any of those three, that spreadsheet is the build scope, not a replacement of the whole product.

How do hidden costs get into the quote?

A focused first release runs $70,000 to $150,000 and ships in 12 to 18 weeks: offline field production capture against a real pay item schedule, permit and inspection gating, and a first as built export for your largest owner. A full platform at $180,000 to $400,000 phased over 6 to 12 months adds redline to record drawing workflow, subcontractor pay applications with retainage and compliance holds, restoration and damage claim tracking, program level forecasting and export profiles per owner.

Owner program count is the strongest driver, because each brings a pay item schedule and an as built format, and neither is a configuration row. Geographic information system integration is the second, and it is regularly quoted without accounting for the owner's cooperation being on the critical path. Subcontractor tier count is the third, since two tiers deep means rate sheets, retainage terms and prequalification status on every party. Design data format is the fourth, for the redline reasons above.

The fifth is offline behaviour, which contractors sometimes assume is included and developers sometimes price as a checkbox. It is a conflict resolution design with a local queue, a sync log and an explicit rule for who wins when the office and the field edit the same record. Vague answers here become lost production data in month three, which is the most expensive kind of missing data you can have.

What separates a build that works from one that fails here?

Field adoption, and it is decided by seconds. A foreman standing in a right of way at the end of a shift will use a form that takes ninety seconds and will not use one that takes eight minutes. Prompt the splits that matter for billing, such as a driveway crossing at a different rate, rather than expecting them to be remembered. Attach photographs with position and timestamp automatically, because photographs are what settle unit disputes months later. If crews are not using it on live work in week one of rollout, the project is already in trouble regardless of what the demo showed.

Second, scope the first release narrowly and deliberately: one owner program and your two highest volume pay item types. That covers most of the money and teaches you what the rest needs, and it gets a real as built export through a real owner's acceptance process while the team is still assembled.

Third, build as built delivery as a translation layer rather than a fixed export. Your internal record stays consistent and each owner gets a mapping profile converting attributes, naming and file structure. Adding a fifth owner then costs a mapping exercise rather than a rebuild, and you will win a fifth owner with a sixth format.

Finally, settle ownership before kickoff: repository, infrastructure accounts and the freedom to hire another firm. At Digital Heroes the client owns the code from the first commit. A developer uncomfortable with that is creating a bargaining position for renewal, which is a poor place to be when your billing depends on the system.