The last months of the year have a particular rhythm in telecommunications. And this year more than ever.
When the FIFA World Cup is on the calendar, the whole sector knows there is a date that does not move: before it starts, everything has to be in production. What does not make it on time waits until after — and “after” means reaching year-end with the accumulated pipeline on top of you.
The result is the usual thing, but tighter: changes competing for the same windows, upgrades that depend on another project finishing first, migrations coordinated across several countries with different freezes and local teams with their own calendars — the same kind of friction I described when moving from local team in Chile to coordination from Europe. Suddenly you are looking at a pipeline where everything is urgent, everything has dependencies, and in a few days you have to present the real status to management — without alarming them, but without hiding anything either.
The problem is not the amount of work. The problem is visibility. What comes first? What blocks what? Where is there a capacity conflict? Before answering any of those questions, you first have to build the picture. And that used to take days.
1. 🔍 The problem that lives between the tools
Jira exists. Runbooks exist. Documentation exists — or it should. The problem was never a lack of tools. It was that none of them told you what happens over time.
Jira tells you what exists. It does not tell you when something goes, in what order, what depends on what, whether two changes are fighting for the same window in the same country. A generic planner lets you move tasks. But it does not understand that if there are changes in the backoffice that serves local services, you cannot run a complex video component upgrade in parallel — because if something fails, nobody will know who was responsible.
When you have to coordinate upgrades across several countries, different platforms, local teams with their own timelines, and on top of that report with an honest view of risks — not a task list, but a real read of what is happening — you need something that does not come packaged in any product on the market.
And the other pain nobody names: runbooks. Hundreds of Excel files with different versions, numbered updates, variants by country. Country A’s runbook on version 3, country B’s on version 1 with local modifications, country C’s that nobody knows if it is up to date. Every maintenance window starts with hunting for the right file. That is a real problem, and it has gone unsolved for years.
2. 🛠️ What I built — and how it works
Using experience I had been accumulating on other personal projects — including NeuraPRO — and with Claude as a building tool, I developed two pieces that today work integrated: a team portal and a planner. You reach the planner from the portal, but each has its own role.
The portal gives visibility per project. Connected to Jira, it shows the full structure from the EPIC down to the implementation task — progress percentage, planning, status. But it is not just a Jira view. It has a runbooks section where each implementation task has its own standardized, versioned runbook, without Excel. It has a learnings section where what used to get lost in chats and emails is recorded. And it lets you export an executive project summary — blockers, status, next actions — ready for a report without building it from scratch.
The planner is where planning over time lives. The core logic is chain templates: a chain of tasks that represents everything that has to happen for something to be considered delivered. An upgrade has its sequence — preprod, DR, prod batch 1, prod batch 2. A migration has its own. I can filter by country, environment, change type. If I have an upgrade for country X and a different upgrade for the same country weeks later, I see them on the same timeline and manage separation and dependencies without losing the thread. I drag a chain on the calendar, tasks adjust themselves — release, sprint, owner — and it reflects automatically in Jira.
Illustrative image with sample data only. It does not show real operational information and does not expose private data from any market.
And on top of all this, Claude. I ask it to analyze an EPIC, to generate a phased structure with parents and children ready to create in the project. I review, adjust what does not match the team’s reality, and execute. What used to take hours now takes minutes.
Today I use it as a TPM. The idea is first to get the most out of it in this stage — we have a lot in the pipeline — and in a next phase open it to the team with role-based access: each engineer with visibility of what applies to them, without everything going through one person.
A real pipeline example
In one market (unnamed) we had three critical items at once: platform 1 upgrade, platform 2 upgrade, and a DRM migration — three EPICs in Jira. Management was not asking if there was a window; they were asking what goes first, what hits prod hardest, and how to align network, services, main and backup.
In the planner all three are chain templates on the same country. That is where you see what Jira does not: one engineer with two tasks the same day, a backup change clashing with something else, or the most complex operation run too early and blocking the rest with no way to attribute a failure.
The rule is simple: preprod for all three → validation with the teams → DR with the upgrades (one week between chains) → improved runbook → whichever upgrade went best → DRM → most complex operation last. If something fails, we know where it came from.
When the issue is a person, I filter by owner. For network and services, I export main, backup, dates, and risk from the portal — without rebuilding slides from scratch.
3. ⚡ What actually changed
Yes, I save time. But that is not the main point.
Before, a large share of the week went into building the picture so others could decide: pulling data from Jira, cross-checking emails, opening runbooks in Excel, drawing a timeline in PowerPoint, and hoping it was still valid on meeting day. That is not leading a change in production. It is assembling information — the same distinction I wrote about in I Never Studied to Be a Project Manager. And if you spend three days putting it together, the pipeline has already moved by the time you present.
Now I walk into the meeting with the picture ready — or refresh it in minutes. Time goes to something else:
- Does this change go before or after the other one?
- Is there real capacity and a real window that week, or just dates on a calendar?
- Does what we are seeing in one country connect to something that already happened in another market last month?
The hard work did not disappear: still many countries, many activities, a lot of coordination. The tool does not simplify that. It changes the type of problem. You stop fighting to see what is going on and start fighting to decide what to do — which is what a TPM should be hired for.
4. 🤔 What I keep turning over
The tool exists, works, keeps improving. But there are two things I cannot ignore.
The first: the same reasoning I used here works in any industry where there are processes and coordination. A mid-size hardware store. A pharmacy. A bakery with several locations. Not the large companies with IT teams — the ones with some technology but no idea where to start with AI. With a small group of people who know how to use AI, think clearly, and have worked under pressure, I think you can do quite a lot. The limit is not technical.
The second is more uncomfortable: in two or three years, at certain points in the chain there will be fewer and fewer people needed. Not as a prediction — as something already happening. What I built in weeks used to need a team and several months.
The issue is not whether to automate. It is at which point someone still needs to be watching — and how that gets decided. Today everyone resolves it as they can. At some point that will have structure: roles, policies, defined responsibilities.
What I do see from the inside is that the industry is still waiting for this to resolve itself. Very little real action. Management in many cases is still in observation mode, without fully understanding that the moment to experiment has passed — we are in the moment to build. And those who did not start will be late to that conversation.
✍️ Claudio from ViaMind
“Dare to imagine, create, and transform.”
Also available in Spanish: Cuando Jira no alcanza.
FEATURED POSTS
ABOUT ME
ViaMind Ecosystem
- ViaMind — The brand hub for ideas, technology and strategy.
- NeuraPRO — Practical software for managing real operations.