Case study · The origin
A national wireless carrier issued a relocation portfolio and gave 60 days to return feasibility and permitting recommendations across it. Assembling it by hand was not achievable in the time. I had never written a line of code. I built the pipeline in three days, and the three of us working the programme delivered 317 packages across 316 sites inside the window.
This is the first case study on this site, and it predates the software practice by design. It happened inside the land work, under a deadline, two years before Synergistic Solutions Unlimited existed. The practice is downstream of this week, which is the reason the method here is the same method everywhere else on the site.
The situation
A relocation portfolio is not a batch of identical tasks. Every candidate sits in its own jurisdiction, under its own ordinance, on its own ground, next to its own existing structure. The recommendation that comes back has to account for all of that or it is not worth returning.
Done the way this work is normally done, each site takes a person opening the database, transcribing the attributes into a template, drawing the review area, reading the local code, and writing the analysis. Multiply that across the portfolio and set it against 60 days. It does not fit in the window, and neither does hiring for it: staffing takes time the deadline does not have, and every additional hand is another source of variation in a deliverable the client is going to compare site to site.
The constraint was not effort. It was that the assembly work was being done by people, one site at a time, when none of it required judgment. Judgment was needed for the feasibility conclusion. Everything upstream of the conclusion was transcription.
What I built
The carrier’s own site list was treated as authoritative. Nothing was retyped, so no second version of the truth existed for the project to drift against, and nobody spent the portfolio transcribing what the client already held.
Coordinates, ground elevation, and urban or rural classification, combined so the size of each search area followed from the site’s own characteristics rather than from someone’s judgement. Python generated the radius on that logic, half a mile urban and one mile rural. The search area stopped being a decision made hundreds of separate times.
A macro built the folder structure for every site, so the filing convention was a product of the pipeline rather than a rule people had to remember.
A macro-enabled Word template produced a pre-populated feasibility analysis per site. One template meant one place to fix anything wrong, and 316 sites that could be read against each other.
Each generated document arrived already carrying its site number and name, state and jurisdiction, coordinates, ground elevation, existing tower height and structure type, carrier centerline and height above ground, and review radius, plus structured sections for search-area feasibility, permitting paths split between raw land and colocation, feasibility maps, and the relevant zoning ordinance excerpts.
What the automation did not do is decide anything. It removed the transcription and left the analysis, which is the part a client is actually paying for.
Handling the client’s data
The analysis used four attributes. Coordinates, structure height, city, state. That is what the spatial logic required and it is all the pipeline ever touched. A portfolio-scale automation is an easy place to reach for more than you need, because having everything on hand is convenient, and that convenience is how client information ends up somewhere nobody decided to put it.
What the pipeline would use was decided before it was written, not reviewed afterwards.
Evidence
| Date | Artifact | What it establishes |
|---|---|---|
| Oct 7, 2024 | Executed scope of work | Engagement scoped |
| Oct 22, 2024 | Carrier site list received | Source of truth established |
| Oct 22, 2024 | KML containing 315 review-radius polygons | Python radius generation working |
| Oct 23, 2024 | Folder-generation macro | Directory structure automated |
| Oct 24, 2024 | KML containing 315 site placemarks | Candidates plotted |
| Oct 25, 2024 | Production macro-enabled template | Pipeline complete |
What changed
317 feasibility packages across 316 sites, delivered inside the 60-day window. The client received a portfolio in which every site was documented the same way, so the recommendations could be compared against each other rather than read one at a time as separate documents by separate hands.
The filing convention survived the project. Structure that is generated does not decay the way structure that depends on discipline does. Every site landed where the next person would look for it.
The correction cost went to near zero. One template governing every output means a defect found at site 200 is fixed once, not 200 times, and the fix reaches sites 1 through 199 on the next run.
This is where the software practice started. The pipeline was written inside infrastructure work to deliver an infrastructure portfolio. It was not a career change. It was the same problem the land work had always presented, which is how to make something repeatable and hand it to someone else, answered with a different tool. Everything I have built since is downstream of these three days.
Mapped to the method
The method
What is not claimed
Stated as an estimate: the labor hours this removed run to several hundred. That figure is a considered estimate, not a measurement, and it is not presented as one.
The delivery counts are exact: 317 packages, 316 sites, a 60-day window, a three-day build, and dates that come from file timestamps rather than memory.
The client is not named here. That is deliberate and applies across this site.
Read next
The hearing record: several hundred hearings, three denials, all three described.
Two contested outcomes: the sites where the ordinary path had already failed.
Contact