My View on Project Management — From Execution to Strategy

Practical lessons from over a decade delivering technical projects, from field work to leadership.

Introduction

I have seen many project management styles, but here is mine: how I went from installing networks in the field to leading multiple projects in parallel — and the lessons that stayed with me.

Back in 2011 I started with operational tasks: execute, follow instructions, deliver. Over time I moved closer to management and realized leading a project is far beyond coordinating tasks: it is understanding the end-to-end, defining deliverables, goals and milestones, and breaking down big objectives into actionable steps.

For me, PM is mainly about managing people, expectations and resources. It is not only about following a plan, but adapting it when reality changes — without losing sight of the outcome.

From execution to strategy

My first projects were in telecommunications, installing IP telephony. I was on site, doing cabling and network setup. Management was minimal, yet I learned a fundamental truth: if you want things to happen, you must communicate well. From day one I trained client communication, explaining the action plan, no matter how simple.

As I mastered the technical stack and the business context, organizing installations and talking to clients became natural. I progressed quickly, taking larger responsibilities every ~3 years, often in multinational environments. Key lesson: less is more. If the plan is solid and you thought through the angles, execute with confidence and measure to adjust.

From execution to strategy

My current view: advice for a technical PM

  • Review the scope first: if it is not clear, a future blocker is guaranteed.
  • Understand the context and deliverables: define what you ship, the business problem it solves, and how it integrates with current systems. Map dependencies from the start.
  • Leave room for surprises: anticipate risks, add buffer time, and keep a plan B for vendors and key dates.
  • Speak clearly and get to the point: who needs what, by when, and why. Keep it simple: one line with status, blockers, and next steps.
  • Delegate to the team, run check-ins and update status: short meetings to confirm alignment, keep momentum, and unblock issues.

My role has been more about making promises real (from sales/architecture) than about commercial or contractual prep. That made me obsessed with scope and early alignment.

Governance and tracking (Jira)

We use Jira to provide visibility and control. Once the scope is defined, I translate it into EPICs, user stories and tasks. I build the structure myself because I know the stages, dependencies and flows: from the macro down to the smallest tasks. By estimating each story in story points, we get a global view to measure real progress and anticipate misalignments.

While I currently use Jira because it is the standard in my company, in other organizations I have worked with more traditional methods or different software. In the end, the tool matters less than the logic: breaking down work into manageable parts without losing sight of the main objective.

In large organizations with multiple parallel commitments, this aggregated information helps estimate the value and cost of future projects, prioritize initiatives, and allocate resources more precisely.

Governance and Jira - structure and visibility

From planning to execution

With governance defined, I move to concrete tasks, owners and timing. At this stage, stakeholder meetings are key: the scope is clear, but there are multiple paths to achieve it. I present an initial plan and listen to alternatives that could be more efficient or less risky.

My simple structure

  • Parent task (e.g., Connectivity X)
  • Several subtasks (meetings, troubleshooting, testing, etc.)

I assign story points to subtasks with a simple rule: 1 SP = 1 working day (8h).

Example for Connectivity X:

  • Meetings → 1 SP
  • Testing → 0.5 SP
  • Troubleshooting → 1 SP

Estimated total: 2.5 SP (in practice connectivity tends to be 4 SP or more). SPs are not rigid control; they are an effort estimate that improves with experience.

I prefer many detailed tasks/subtasks rather than a few generic ones. It is easier to spot blockers, prioritize and understand bottlenecks.

Meetings, prioritization and parallel projects

I usually run several projects in parallel sharing the same resources. Any delay or priority change cascades. Jira becomes strategic: it focuses the team on the highest priority tasks and keeps everything moving.

Collaboration and unblocking

I run progress meetings with my team. Even when tasks are assigned to others, my experience lets me advise, guide or simply listen. I strongly believe a good leader must always create space to listen.

If a task is not moving forward, I connect the person with someone who already solved something similar. Most blockers are not technical — they are about scope, internal politics or economic factors — and that is where management support becomes key.

How I organize progress reporting

We work with releases and two-week sprints, with one session per sprint together with stakeholders:

  • I present ongoing tasks, highlighting the most important.
  • We review what comes next.
  • We agree timings and deliveries.

After every meeting we share a short agreement file. In the next session we review the same document to check progress. We also schedule focus meetings for specific tasks with only the necessary people.

Releases and sprints - delivery cadence

Final reflection

In my opinion, the key for any PM is good communication, empathy and —above all— perseverance. Many times things will not go as planned, but it is important to keep going and look for alternatives; there are always options, even when it does not seem so.

Continuous learning is essential. In my case, I took several postgraduate programs and studied for the PMP certification —although I never completed it—, but many of its lessons stuck with me. Maybe one day I will finish it… though honestly, in today’s world I believe experience weighs more than titles.

Be honest, do not belittle others, do not act like a know‑it‑all, be humble, listen, be patient and —above all— be a good person. That is what matters most. The people you work with will feel it: some will like you, others maybe not, and that is fine. What matters is that, at the end of the day, you gave your best without harming anyone.

You can have the best tools and processes, but without communication, empathy and clear values, a project will never reach its true potential.

Shine with your own light, without dimming anyone else’s.


✍️ Claudio from ViaMind

“Dare to imagine, create and transform.”


How do you manage your projects and teams? I would love to read your experience.

Recommended links:


Comments
Comments are shared between English and Spanish versions.

Subscribe

Get a monthly email with the best posts on innovation, technology, and the future. No spam.

* required

Intuit Mailchimp