From Cell Towers to Project Plans: My Telecom-to-IT Pivot

The pivot nobody plans

I did not start out trying to become a project manager. I started in telecom field work — infrastructure deployment, site installations, auditing final cellular designs. It took me a few years to notice what I was actually doing: coordinating people, schedules, and deliverables across multiple sites, under real deadlines, for demanding clients. That is project management. It just wore work boots.

The pivot into IT project coordination isn't a career change so much as a career translation. The work was already project-shaped. What I needed was the vocabulary, the frameworks, and the credentials to make that visible — to employers and to myself.

Field telecom is project management in disguise

A multi-site telecom rollout has everything a textbook project has: scope, schedule, budget, stakeholders, dependencies, and risk. The difference is that the classroom examples never include a concrete crew waiting on an electrical inspection while the client's go-live date doesn't move.

Coordinating civil and electrical installation lifecycles across sites meant sequencing work so crews weren't idle and nothing was installed out of order. That's schedule management and dependency planning, learned the hard way — when you get the sequence wrong, you pay for it in crew downtime the same day.

Enterprise work orders for tier-1 clients added the stakeholder dimension. When the client is a national carrier, "done" has a precise definition, the documentation standard is non-negotiable, and status updates need to be accurate, timely, and written for people who weren't on site. I learned to communicate progress the way executives consume it: what happened, what's next, what's at risk.

Auditing designs taught me scope verification

One of my core responsibilities was auditing Final Cellular Designs — reviewing installation plans against standards before and during deployment. In project management language, that's scope verification and quality control: confirming the deliverable matches the requirement before it becomes expensive to fix.

This is the skill I now lead with. Catching a design mismatch on paper costs nothing; catching it after installation costs a crew day. The discipline is the same in IT: verify scope early, control changes formally, and never assume the plan and the build are the same thing until you've checked.

A rollout that taught me risk management

On one multi-site deployment, a design revision arrived after civil work had already started at two locations. The revision changed equipment mounting specs — small on paper, significant on site. The old way of working would have been to push ahead and "make it fit." Instead, I flagged the mismatch, documented the impact on both active sites, and got the revised design formally approved before installation continued.

It cost us two days of schedule. It saved us from installing equipment that would have failed inspection and needed rework — which would have cost far more. That experience rewired how I think about change: a delay you choose is always cheaper than rework you didn't. In PMI terms, that's integrated change control. On site, it's just not pouring concrete twice.

Risk management in the field is refreshingly honest. Risks aren't theoretical entries in a register — they're weather, permit delays, a crew short two people, a design that doesn't match the terrain. You learn to identify them early because the cost of being wrong shows up the same week. That instinct — name the risk early, quantify what it costs, have a response ready — transfers directly to any project environment.

What I had to add: the formal toolkit

Experience teaches the instincts. Credentials teach the language — and in a hiring process, language is what gets you past the first screen.

The CAPM gave me the PMI framework: process groups, knowledge areas, the vocabulary that lets me describe what I already did in terms employers recognize. The CSM added the Agile side — sprint discipline, servant leadership, iterative delivery. The graduate certificate in IT Project Management from Conestoga closed the loop on the technology context: software lifecycles, systems thinking, and how infrastructure projects differ from pure software ones.

None of these replaced the field experience. They translated it.

Where this goes

I'm targeting project coordinator and IT project management roles where infrastructure meets technology — the exact intersection I've been working in for years. Telecom taught me delivery under physical constraints. The certifications taught me delivery under methodological ones. The combination is rarer than either alone.

If you're hiring for a role like that, here's my pitch in one paragraph: I bring five years of coordinating complex, multi-stakeholder field deployments — sequencing crews, verifying scope against designs, managing change without breaking the schedule, and reporting to tier-1 clients who accept nothing vague. I've added the formal frameworks (PMI, Scrum) and the IT context (systems, lifecycles, stakeholder management) to match. I don't need to learn how projects work. I need a project to run.

The pivot is still in progress, and I'm honest about that. But it's not a leap into the unknown. It's a field-tested project manager finally getting the title to match the work.