That was when I realized that, despite all the discussions about the technology, some basic project questions were still unanswered. Who is responsible for preparing each spreadsheet? When does each one need to be ready? Who validates the information before it is sent? Can the vendor start working with one file while waiting for the others? How long will the upload take? Who will validate the data after it is imported? And, most importantly, who is waiting for this information to be available in the new application and by when?

Without these answers, I could understand many things about what the application might eventually do, but I still could not build a reliable initial schedule or define the first version of the scope. That made me think that perhaps we sometimes confuse technical understanding with project understanding.

Does a Project Manager Need Technical Skills?

I believe the answer is yes, but perhaps not in the way we sometimes imagine. A Project Manager working in technology should understand the environment well enough to follow the conversation and understand its consequences. If an integration is involved, we should understand what is being integrated and why. If an API is required, we should understand the role it plays in the solution. If data needs to be migrated, we should understand where that data comes from, who owns it and what could prevent the migration from happening as expected.

If an API is required, for example, I need to understand who owns that work, what depends on it, when it needs to be available and what happens to the project if it is delayed. If a vendor needs spreadsheets to load information into a new application, I need to know who produces them, what format is required, when they are due and who validates the result. For me, this is where technical knowledge becomes valuable to project management. The objective is not to become the most technical person in the room. It is to understand the technology well enough to identify what it means for the project.

Buying Software Is Not the Same as Implementing It

This distinction becomes especially important when a company is buying an existing application rather than developing a new one. The software already exists, the vendor already knows the product, the contract may already be signed and the licenses may already be purchased. But the project is far from finished. Someone still needs to define what will be implemented first, provide the data, review the configuration, coordinate with the vendor, prepare the users, manage integrations and decide what is part of the current implementation and what belongs to a future phase.

In this kind of project, much of the complexity does not come from software development. It comes from coordination. The vendor needs something from the company, one internal team depends on another, users are waiting for the platform, the security team may need to approve access, another application may need to provide information and a business area may need to validate the data. These are project dependencies, even when no software is being developed internally.

Technical Discussions Can Easily Become Scope Discussions

Another challenge appears when people begin exploring everything the new platform could do. Someone says that the application could integrate with another system, another person suggests automating a manual process and someone else asks whether the platform could also be used by another department. Very quickly, the conversation moves from the current implementation to future possibilities.

There is nothing wrong with that. The problem begins when nobody separates those possibilities from the actual project scope. A Project Manager needs to understand whether an idea is part of the current phase, a future enhancement or simply something technically possible. Otherwise, scope becomes a collection of expectations that nobody has formally agreed to deliver.

This is why I believe one of the most important things a Project Manager can do in a technology project is translate possibilities into commitments. Technology discussions often focus on what can be done, while project management needs to establish what will be done.

A Project Schedule Starts With the Flow of Work, Not With Dates

The example of the spreadsheets also reminded me of something else: a project schedule does not begin by choosing dates. It begins by understanding how the work flows. If five spreadsheets need to be delivered, I first need to know who prepares each one, whether they can be produced in parallel, whether anyone needs to validate them and whether the vendor needs all of them before starting.

Then I need to understand what happens next. Does the vendor upload the data immediately? Is configuration required afterward? Who checks the result? When can users begin using the system? Only when this sequence becomes clear do dates start to make sense. Data preparation, validation, delivery, upload, verification, user readiness and go-live become connected activities rather than isolated dates on a calendar.

Understanding these relationships is also important for identifying the critical path and the dependencies that can delay a project. If one activity cannot begin until another has been completed, that relationship needs to be visible before commitments are made. Without understanding the sequence of work, the dates in a schedule are little more than guesses.

Technical Fluency vs. Technical Expertise in Project Management

For this reason, I prefer to think about technical fluency rather than technical expertise for Project Managers. To me, technical fluency means understanding the environment well enough to connect what is being discussed with what it means for the project. If an integration requires security approval, I need to recognize that this may become a dependency. If the vendor explains that a requested customization is outside the standard product, I need to understand that we may be introducing additional scope, cost or delivery risk. If a team cannot provide data until another department validates it, I need to see not only a technical constraint, but also an ownership and schedule issue.

The technical detail matters because it gives context to the management decision. The goal is not to master every part of the solution, but to understand enough to see where a technical decision, limitation or dependency can affect the project and what needs to be done about it. This understanding also helps us recognize the early warning signs of project delays, particularly when technical constraints begin affecting dependencies, estimates or delivery forecasts.

How Technical Should a Program Manager Be?

The required technical depth starts to change when we move from a project to a program. A Project Manager usually works relatively close to execution, where technical constraints can have immediate consequences for schedule, scope and delivery. A Program Manager operates at another level. The individual technical issue still matters, but what becomes increasingly important is understanding how that issue connects different projects, teams and outcomes.

Imagine that three different projects depend on the same integration team. For each Project Manager, this may appear as a dependency inside an individual project. For the Program Manager, however, it represents something broader: a shared capacity constraint that could affect several initiatives at the same time. Or imagine that one project is replacing an application that several other projects currently depend on. The technology decision is no longer confined to one project. It becomes part of the program's technical landscape and may influence sequencing, benefits, resources and delivery across multiple initiatives.

So the Program Manager may need less implementation detail than the Project Manager, but more understanding of how the technical pieces connect. The focus moves from managing the consequences of technology within one project to understanding how those consequences affect the outcomes of an entire program.

How Technical Should a PMO or Portfolio Manager Be?

At the PMO or Portfolio level, the questions become broader again. A Portfolio Manager probably does not need to know why a particular data import failed or which API is preventing one application from communicating with another. But the Portfolio Manager may need to understand whether several strategic initiatives depend on the same platform, whether multiple projects are competing for the same technical specialists, whether different areas are purchasing applications with overlapping capabilities, or whether one technology decision is creating risk across several important initiatives.

At that level, technical knowledge increasingly becomes business context. The questions move toward investment, capacity, prioritization, benefits and organizational risk. A technical limitation affecting one project may be relatively small when considered in isolation, but its importance changes if several strategic initiatives rely on the same system, supplier or specialist team.

This is perhaps the distinction I find most useful: a Project Manager needs to understand how technology affects delivery. A Program Manager needs to understand how technology creates dependencies across initiatives. A PMO or Portfolio Manager needs to understand how those dependencies affect investment, capacity, risk and strategy.

The amount of implementation detail may decrease as we move through these levels, but the need to understand the consequences of technology does not disappear. This is also connected to the broader role of a modern PMO, which should help organizations understand not only whether projects are progressing, but whether those projects are creating business value. I explored that distinction in more detail in my article on AI Project Management and how to build a PMO that creates business value.

Technical Project Manager vs. Project Manager

This is also where I think it is useful to distinguish between a Project Manager working on a technology initiative and a Technical Project Manager. The distinction is not simply that one understands technology and the other does not. Any Project Manager responsible for a technology initiative needs enough technical knowledge to manage it effectively.

A Technical Project Manager will normally operate closer to the technical solution and may be expected to participate more deeply in discussions about architecture, engineering constraints, environments, integrations or implementation decisions. A Project Manager may work at a slightly higher level, relying more heavily on technical specialists while focusing on delivery, coordination and business outcomes. The exact boundary will always depend on the organization and the nature of the project, but labeling someone a Project Manager should never mean that technology becomes a black box they do not need to understand.

So, How Technical Should a Project Manager Really Be?

Perhaps the original question needs to be reframed. Instead of asking only how technical a Project Manager should be, I think a better question is: how much technical understanding do I need in order to make the management decisions that belong to my role?

A Project Manager should understand the technology well enough to recognize how technical decisions, limitations and dependencies can affect scope, schedule, cost, risk and delivery. The objective is not necessarily deep technical specialization, but enough technical fluency to ask the right questions, identify consequences and turn technical information into management decisions.

If I cannot understand the technology well enough to see how it may affect the project, then I probably need to deepen my understanding. At the same time, if I start making architectural decisions that properly belong to specialists, I may be moving beyond the boundaries of my role. The balance is somewhere in between: enough technical understanding to interpret the consequences, without taking ownership of decisions that require deeper technical expertise.

And sometimes, especially when a company is buying a new application, the most important questions are much simpler. What exactly are we implementing? Who needs to provide what? Who is waiting for the result? What depends on it, and when does it need to happen?

Those questions may look simple, but without them it is very difficult to create a meaningful scope, build a realistic schedule or understand whether a project is actually moving forward.

See you soon!

Erik Scaranello