Fiber Network Planning Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the design get built as map rendering?

Because the map is what everyone can see. Stakeholders ask for a demo, a demo of a design is a map, and a team that wants to show progress in week three builds the map first. The routes become line features, cabinets become points, the premises become another layer, and the cost model stays where it has always been, in a spreadsheet that sums footage against unit rates.

What has happened is that the design got stored as geometry when it is fundamentally a constrained graph problem. Routes along a street network, splitter locations serving a set of premises, a loss budget along each path, cable sizing determined by the count downstream, cabinet capacity, and the physical cost of getting from A to B by each available method. Every one of those is computable. None of it is computable from line features on a map.

The tell is what happens when an input changes. If a new take rate assumption means a designer opens the drawing, the build failed at the modelling stage regardless of how good the map looks. The fix is to insist on the data model before anyone draws anything: premises as demand points, splitters and cabinets as facilities with capacity, the street and plant network as a routable graph, and the loss budget as a path constraint. Rendering comes afterwards and is the easy part. Ask a prospective developer how they would represent the design. If they start with map rendering, they have understood the visible half and missed the problem.

What goes wrong when street and premises data becomes a routable graph?

This is the schedule risk that operators consistently underestimate, and it is not engineering.

Municipal centreline data is built for cartography and addressing, not for routing. Segments do not always connect at intersections, one way and access restrictions are inconsistent or absent, private drives are sometimes present and sometimes not, and new subdivisions lag the real world by however long the county takes. A graph built naively on that data produces routes that a truck cannot drive and a crew cannot build, and the errors are invisible until someone who knows the area looks at a specific block.

Premises data has its own problems. Parcel centroids are not service addresses. Multi dwelling units appear as one parcel and represent forty units. Commercial buildings with several suites appear as one point or as several, depending on the source. If your build is funded against a defined location list, that list is authoritative for reporting and often does not agree with your parcel data, so you now need both and a reconciliation between them.

Budget data preparation as its own workstream with a named owner, not as a task inside development. The cheapest version is to clean one representative build area properly, use it to prove the graph, and then apply the same rules across the rest with exception reporting rather than trusting a bulk import.

Why do the GIS, inventory and permit integrations break after launch?

Three integrations matter and each fails in its own way.

The network records system is the first. Your design engine produces objects that need to land in 3-GIS, IQGeo or VETRO FiberMap, and those systems have their own identifiers, their own required attributes and their own idea of when an object becomes real. The break happens at as built time: the field crew changed the route, the records system was updated, and the design model was not, so the two diverge from the day construction starts and never reconverge. Decide up front which system owns each object at each lifecycle stage and build the reconciliation path in the first release, not the second.

Existing plant inventory is the second. Spare conduit, dark strands and cabinets with free ports are worth real money, and the data describing them is usually of mixed quality, especially after an acquisition. An integration that treats every record as true will design against duct that is not actually available. An integration that ignores the records designs as if the ground is empty, which is safe and expensive. The workable answer is a confidence level per record and a field verification queue for reuse assumptions above a value threshold.

Permitting is the third, and it usually is not an integration at all. Many jurisdictions accept submissions only through their own portal or by email in a specific drawing format. Do not let anyone promise automated submission. Model the deadline, the required artefacts and the status, and accept that a human presses send.

What happens when the construction handoff is not covered?

A design that cannot be handed to a crew is an academic exercise, and this is the gap where fiber programmes lose their schedule.

What construction needs is different from what an optimiser produces. Permit drawings in the format each jurisdiction accepts. A bill of materials against the part numbers your warehouse actually stocks, not generic cable descriptions. Splice schedules. Work packets scoped to a crew week with dependencies respected. Pole application data in the format the pole owner's process demands. When those are produced by exporting, reformatting and rebuilding a material list in a spreadsheet against a catalogue that has changed since last quarter, every handoff introduces errors, and the errors surface as a crew standing on a corner with the wrong cable.

The second half of this gap is as built reconciliation. Field changes are normal. What is not normal is having no path for them to return against the same objects the design produced. Without that path your records decay from day one of construction, and the next design in that area starts from data you do not trust, which sends you back to designing as if the ground is empty.

Scope the construction output layer explicitly, even if you phase it. A design engine with no buildable output is a scenario tool, which has real value, but do not let it be sold to you as a planning platform.

Should you build custom or configure what you already own?

For a lot of operators, buy or engage as a service. If you build a few thousand passings a year in one town, or your architecture is conventional, Comsof Fiber or Biarri Networks as a design engagement will beat a build on both cost and time, and the money is better spent in the ground. We would tell you that rather than quote. They do automated design well and they can be bought as software or as a service, which suits a single market campaign far better than owning an engine.

Keep your records system whatever you decide. 3-GIS, IQGeo and VETRO FiberMap are the right tools for network records and field operations, and a custom design engine should feed them rather than compete with them. A developer proposing to replace your records system alongside building a design engine is proposing two projects and calling it one.

The build case starts when two or more of these hold: you design continuously at scale rather than in one campaign, your architecture rules differ enough from the standard patterns that configuring a product means fighting it, your cost model needs to be spatial and derived from your own completed jobs, you have substantial existing plant whose reuse materially changes designs, or your output has to flow into systems you already run in formats those systems define. The tipping point is not design quality, since the commercial engines are good. It is iteration speed when the business case gets rebuilt monthly.

How do hidden costs get into the quote?

Data preparation is the largest and it is rarely a line item. Cleaning centreline and parcel data into a reliable routable graph is real work with a real duration, and it belongs in the quote with a named owner.

The number of architectures is the second. Centralised and distributed splitting with different reach conventions are two engines rather than one option with a toggle, and operators who support both in different density bands should price both. Aerial is the third: modelling make ready properly from pole attachment data is a different project from applying a per pole allowance, and the difference is usually not clarified until someone asks.

Multiple jurisdictions with different permit formats add cost linearly, since each format is its own output template and someone has to read the actual rules. And the optimisation itself grows expensive if your build areas are large, because a design covering tens of thousands of premises needs the problem decomposed sensibly rather than thrown at a solver whole.

The cost nobody quotes is the validation run. Hand the engine one completed build area where you know the real as built cost, and require it to reproduce the design and the cost within a sensible margin. That takes weeks and it is the only evidence that matters.

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

Three things.

First, the cost model is spatial. Flat unit rates per foot hide the variance that actually decides routes: rock, restoration requirements in a downtown core, a state highway crossing with its own permit and bore, a railroad crossing with its own agreement and timeline, and make ready on a heavily attached pole route. An optimiser running on uniform rates is optimising against a fiction, and it will never surface the alignment that accepts a longer route to avoid one expensive crossing. Derive the rates from your own completed jobs and vary them by surface, jurisdiction and known constraint layers.

Second, the engine is honest about optimality. A developer who has done this will talk about decomposition, clustering and solving in tractable pieces with sensible boundaries, and will say plainly that a globally optimal answer across a city is not the goal. Anyone promising optimality at that scale has not run one.

Third, ownership and proof. Get the repository, the infrastructure accounts and the data in writing before kickoff. Then validate against a build you have already paid for. If the engine cannot match a design you know the true cost of, nobody will trust it on the next one, and an untrusted engine is the same as no engine with a licence fee attached.