Programs Going Sideways

Beginning of Programs Going Sideways

This week was supposed to be Part 5 of our Fiber Underground 101 series. The outline’s there. The notes are there. But if I’m being honest, the week got away from me, crews in one market and meetings in another.

Over the years, I’ve seen programs stall, stumble, or implode entirely. Different markets, different companies, same pattern. While there is a lot we can address I am going to focus on:

1. Being absolutely clear on who owns what.

2. Knows who can decide what.

3. Follows a single, disciplined communication flow.

When these among other things fail, the program will start burning time and money faster than you can track it.

What We See

1. Roles and Responsibilities in Name Only

Every kickoff meeting starts with an org chart. Job titles are assigned: Project Manager, Construction Manager, Permitting Lead, Design Lead, Inspector. It all looks good until work starts moving.

Then:

• A CM signs off on a change order one week, but the PM reverses it the next.

• Permitting updates go to whoever answers their phone, not the person actually responsible for closing them.

• Design approvals bounce between three different people.

• Contractors don’t know if they answer to the GC, the ISP, or “whoever picks up.”

It’s not just unclear deliverables, it’s unclear decision-making authority. And when authority is unclear, every question stalls while people figure out who’s “allowed” to answer it.

2. Communication Plans

In most programs, communication is tribal knowledge, not a system.

The result:

• A foreman with a field issue calls an engineer because “he helped me last time,” bypassing the CM entirely.

• Updates get sprayed out via group text with no confirmation that the right people saw them.

• The same status gets reported three times in three places, all slightly different, so nobody knows which one is right.

• Crews make on-the-spot calls to keep moving, but those decisions never get back to the people paying for the work.

When there’s no enforced flow, information gets scattered. And scattered information means scattered execution.

A Framework That Fixes Both

The only way to keep a program moving in a straight line is to define what each role delivers, what they can decide without escalation, and how information moves through the system.

Step 1: Assign Deliverables and Decision-Making Authority

Don’t just say “The CM manages field operations.” Spell out what they own and what they’re empowered to decide.

Example:

Project Manager

• Deliverables: Master schedule, budget tracking, milestone sign-off, client reporting.

• Authority: Approve scope changes, sign off on budget adjustments within limits, reallocate resources between crews/markets.

Construction Manager

• Deliverables: Daily field oversight, production tracking, as-built accuracy, crew performance.

• Authority: Approve minor field changes that don’t alter scope or cost, direct crew sequencing, halt work for safety or spec violations.

Permitting Lead

• Deliverables: Complete and submit applications, track approvals, handle close-out documentation.

• Authority: Negotiate permit conditions within pre-approved parameters, escalate only if conditions impact cost/schedule.

Design Lead

• Deliverables: Issue constructible designs, manage revisions, ensure compliance with jurisdiction specs.

• Authority: Approve design changes within defined tolerances, reject unbuildable field requests.

QC/Inspector

• Deliverables: Document compliance, report deficiencies, verify corrective work.

• Authority: Halt work that fails inspection, approve rework for compliance.

If a role doesn’t have clearly defined ownership and decision power, you’ve left a hole. In the field, holes get filled by guesswork.

Step 2: Lock the Chain of Command

A foreman should be able to answer these three questions without thinking:

1. Who do I report this issue to?

2. Who has the final say on fixing it?

3. Who closes the loop after it’s decided?

That chain should be visible in kickoff decks, posted in the project management platform, and included in every contractor onboarding packet. Once it’s set, you protect it, no quiet reshuffling mid-project.

Step 3: Build a Communication Flow That Matches the Work

A communication plan should function like a map, guiding information where it needs to go, when it needs to get there, and in what form.

Example Field Issue Escalation Flow:

1. Foreman → CM: Logs the issue in the field system and calls CM.

2. CM → PM: If cost/scope/schedule are affected, CM briefs PM with documented options.

3. PM → Client: PM delivers the update and final decision to the client.

Anything outside that flow creates parallel conversations and parallel conversations create conflicting instructions.

Step 4: Train and Enforce

Walk every person, internal team, contractors, subcontractors, through the deliverables, decision rights, and communication plan. Show examples of what happens when the process is bypassed. Then enforce it every single time, even when someone says “it’s faster this way.”

Step 5: Review Without Constant Change

Programs evolve. If decision rights or flows need to change, make the change visible to everyone at the same time. Random, mid-project changes without formal rollout are how you end up right back in chaos.

The Bottom Line

Fiber programs fail because the people doing the work don’t know exactly what they own, what they can decide, and how they’re supposed to move information.

Get these right, deliverables, decision-making authority, and disciplined communication flow and the program runs clean. Get them wrong, and you’ll spend the rest of the build cleaning up problems that should have been prevented in the first place.

And while all of this may seem obvious and most of you reading this probably feel like you already “know” it, very few programs actually implement and execute it in full. The gaps aren’t in knowledge. They’re in discipline and consistency when the pressure to “just get it done” shows up. That’s the difference between a program that finishes strong and one that spends the last quarter putting out fires it created for itself.