Years ago, during a conversation with one of my directors at VTR, I received advice that stayed with me.
“You have to make things happen.”
At the time it seemed like a simple phrase. Even obvious.
Over the years I understood that it probably sums up much of what managing complex projects really means.
Because managing projects is not about filling calendars, creating tickets, or sending emails. Managing projects is about making something actually happen in the real world.
And that difference is far more important than it seems.
The illusion of progress
In many projects there is a constant sense of forward movement.
Emails get sent. Meetings happen. Tickets get created. Dates get set. Plans get updated.
Everyone seems aligned. Everything seems to be moving.
But often that progress is an illusion.
I have seen projects where the change date was set weeks before there was clarity on who would do each task, which dependencies were resolved, or whether teams were truly ready to execute.
And when change day arrives, reality shows up.
An approval is missing. A configuration is missing. A validation is missing. A key person is missing.
Then the meeting drags on. The change gets postponed. The client waits. Teams lose time. And trust starts to erode.
The date existed. But the conditions for success did not.
What really makes a change happen
Over time I learned that a change is not ready because it appears on the calendar.
It is ready when the necessary conditions exist to execute it.
That involves several things.
Clear owners
Not teams. Not departments. Not areas.
People.
Every important task must have a specific owner. Someone who knows exactly what to do, when to do it, and what happens if something fails.
Diffuse responsibility is one of the biggest enemies of execution.
Dependencies identified and closed
Many problems do not appear during execution. They are created weeks earlier.
When someone assumes another person already finished something. When a validation was never done. When a prerequisite stayed pending because nobody was tracking it.
The more complex the environment, the more important it becomes to understand dependencies.
Real availability
I have heard phrases like this many times:
“Don’t worry, we will support you.”
But supporting is not enough.
I need to know who will be present. At what time. In what role. And for how long.
Availability must be confirmed before the change, not during the change.
Preproduction that reflects reality
This is probably one of the most important points.
Preproduction does not exist to prove everything works. It exists to discover what still does not work.
If the procedure we will run in production is different from what we tested in preproduction, then we are not really testing the change. We are testing something else.
And that creates one of the most dangerous risks in technology: a false sense of security.
In production environments, especially when real customers are using the services, surprises are expensive. They can impact revenue. They can affect SLAs. They can trigger penalties. They can damage customer trust.
That is why I have always believed preproduction should resemble as closely as possible the reality we will face afterward.
Forty-eight hours before
Something critical happens at that point.
Reviewing documents in silence is no longer enough. You have to reach out to people. Ask if everything is truly okay. Confirm resources, roles, and timing.
Do not assume that because something was said in a meeting two weeks ago, it is still true.
If doubt appears, if something is unclear, if open points remain, it is worth organizing a meeting two or three days before and honestly assessing whether the change should proceed.
In my experience, it is not worth rushing something that is not ready when the risk is very high. Sometimes the right call is to cancel or move the window.
Nobody wants that. It looks like a defeat. But it is not.
Sometimes, to move forward, you first have to take a step back.
And that does not apply only to work. It applies to any area of life.
Discipline does not mean bureaucracy
That instinct does not remove judgment.
You start to tell when a project is on the right track and when something does not quite fit.
Sometimes processes can be simplified. Sometimes calculated risks can be taken. Sometimes it is even reasonable to skip a minor step.
But when we talk about complex changes, multiple teams, interdependent systems, and distributed responsibilities, discipline stops being bureaucracy.
It becomes a tool to reduce uncertainty.
The difference between a smooth execution and a complicated night is usually built long before the change begins.
The real meaning of that phrase
After many years working on deployments, migrations, upgrades, and production changes, I still remember that phrase.
“Make things happen.”
Today I interpret it differently.
It does not mean pushing more meetings. It does not mean sending more emails. It does not mean creating more documentation.
It means creating the conditions necessary for execution to succeed before change day arrives.
Because in the end, calendars do not deliver projects. Prepared people do.
Related reading:
- I Never Studied to Be a Project Manager. I Learned in Production. — hundreds of live changes and what no course teaches.
- My View on Project Management — scope, governance, and disciplined execution.
- When Jira Is Not Enough — planning what comes first when the bottleneck is not execution.
- About me — career in telecom and project management across Chile and Europe.
✍️ Claudio from ViaMind
“Dare to imagine, create and transform.”
How many times have you seen a date on the calendar without the real conditions to execute?
Because in the end, it is not about having everything planned. It is about being ready when the moment arrives.
FEATURED POSTS
ABOUT ME
ViaMind Ecosystem
- ViaMind — The brand hub for ideas, technology and strategy.
- NeuraPRO — Practical software for managing real operations.