Project, program, or portfolio. And Waterfall or Agile. What is the real difference

In the previous blogs, we covered the five elements of the Quilyx VERDER method: predictability, ownership, calm, objective, and result.

Now that the method itself has been outlined, it is time to step back and look at a set of concepts that are often mixed up in practice. Many discussions about approach, governance, and roles already begin with confusion about a more fundamental question.

Are we talking about a project, a program, or a portfolio.

And are we working predictively or adaptively.

Those concepts are often blurred in practice. In this blog, we therefore set out the differences clearly.

What is a project

According to PMI, a project is a temporary endeavor undertaken to create a unique product, service, or result.

IPMA describes a project as a unique, temporary, multidisciplinary, and organized effort to deliver agreed results within predefined requirements and constraints.

A project is therefore the right form when you need to realize a defined result. Think of implementing a system, migrating an application, or delivering a new infrastructure component.

When does it become a program

According to PMI, a program is a group of related projects, subprograms, and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually.

IPMA similarly describes a program as a temporary organization that coordinates related projects and business activities in order to implement change and realize benefits for a strategic objective.

That immediately shows when something is no longer just a project. As soon as you are not only delivering one result, but are steering a coherent change involving multiple projects, multiple workstreams, organizational impact, and benefits that only become visible in combination, you are really dealing with a program.

Culture change is a good example. It usually cannot be captured in a single project result. A large digital transformation with multiple projects, change tracks, business activities, and benefit steering is also more likely to belong in program management than in classic project management.

When do we speak of a portfolio

According to PMI, a portfolio is a collection of projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.

IPMA formulates this in a similar way. A portfolio is a set of projects and programs that are not necessarily directly related, but that are brought together to make optimal use of the organization’s resources in support of strategic goals.

A portfolio is therefore not primarily about one single change. It is about the total set of changes in which an organization invests. It is about which initiatives get priority, how resources are distributed, and which mix of projects and programs best supports the strategy.

The difference in one sentence

A project delivers a unique result.

A program coordinates related projects and activities to realize change and benefits.

A portfolio governs the total set of projects and programs in order to make strategic choices and allocate scarce resources effectively.

Predictive and adaptive project management

Once the concepts of project, program, and portfolio are clearer, the next discussion usually follows quickly.

Are we working Waterfall or Agile.

PMI prefers a different way of describing that distinction. In the Agile Practice Guide and PMBOK, the terms predictive and adaptive are used more often.

Predictive refers to an approach in which most planning takes place up front and the route is more stable and sequential. Adaptive refers to approaches in which scope, requirements, and the best route are refined and adjusted during the journey.

In common language, those ways of working are often referred to as Waterfall and Agile.

That opposition is much less black and white than it used to be.

Why this is not a religious choice

Around the beginning of this century, Agile emerged with the Agile Manifesto. For a while, some people believed this meant traditional project management would no longer be needed.

In practice, those worlds have now largely found each other.

Rather than a hard opposition, there is now a spectrum between highly predictive and highly adaptive working. The question is not whether something should be Agile or Waterfall by definition. The question is which approach best fits the issue, the uncertainty, the risk profile, and the context.

That is also how we look at it.

A highly predictive approach is useful, for example, when working on something like a nuclear reactor, a space mission, or another environment where requirements, sequence, safety, and control are dominant.

A highly adaptive approach is more useful in research-oriented questions, in initiatives where the end state is still unclear, or in changes that simply do not fit neatly into a traditional project structure. Culture change is a good example of that.

And in many real-life situations, the answer lies somewhere in the middle.

What works when

A predictive approach works well when requirements are relatively stable, the route is largely known, and predictability is more important than flexibility.

An adaptive approach works well when requirements still need to emerge, the problem is not yet fully understood, or rapid feedback is needed in order to discover what truly adds value.

A hybrid approach is often the best choice when some parts of the change are highly predictable while other parts are experimental or subject to change.

And what about the roles

There are also many misunderstandings about roles.

The project manager

The project manager is the person assigned by the performing organization to lead the team responsible for achieving the project objectives.

The strength of a project manager lies in realizing a defined result within a temporary change, with control over scope, planning, dependencies, risks, and progress.

The program manager

The program manager operates at a different level. The role is to realize intended benefits by coordinating the activities of program components and by managing dependencies, budgets, risks, and benefits at program level.

Can a project manager manage a program. Not without the right experience, knowledge, and often additional training or certification.

Can a program manager manage a project. In principle, yes. You may expect a program manager to understand how a project should be managed. But the strongest qualities of a program manager usually lie elsewhere, namely in direction, coherence, governance, and benefit realization.

The portfolio manager

The portfolio manager operates at a different level again. This role focuses on strategic change, prioritization, resource allocation, aggregate risk, and the performance of the total portfolio.

A portfolio manager should understand how projects and programs are managed, but the key strengths are different. The emphasis is on investment logic, strategic choices, governance, capacity, timing, and prioritization.

The PMO

The term PMO is used in different ways in practice, which is exactly why confusion often arises.

In some organizations, PMO stands for Portfolio Management Office. In that context, it refers to an organizational unit that supports portfolio management by helping with prioritization, governance, capacity distribution, and strategic alignment between projects and programs.

In other contexts, PMO refers to a Project Management Officer or Program Management Officer. In that case, it is more about a role or function within a project or program environment.

PMO is also often used in practice to describe what could broadly be called project management support. And this is where you see a wide spectrum in maturity and interpretation.

At one end of that spectrum, the role is more administrative or supportive in nature. Think of scheduling meetings, maintaining action lists, collecting status information, and supporting reporting. That is the version that is sometimes unfairly dismissed as little more than a glorified secretary.

At the other end of the spectrum is the mature PMO function. This is someone who not only supports, but also understands how a project or program should be structured and governed, both operationally and administratively. Such a PMO not only helps with administration, but also helps build and safeguard the full management structure around the initiative.

Think of setting up and safeguarding governance structures, reporting rhythms, decision making processes, planning discipline, dependencies, action tracking, risk overviews, and the quality of project documentation. A strong PMO also ensures that the right information reaches the right place at the right time, and that the program manager or project manager retains overview.

That is particularly valuable in complex projects and programs.

A strong PMO is then not merely supportive, but truly the right hand of, for example, a program manager. Not because the role takes over substantive leadership, but because it helps bring structure, rhythm, and consistency into the steering of the change. As a result, calm, overview, and manageability increase.

That is exactly why it is important not to underestimate PMO. A strong PMO function can make the difference between a project or program that is constantly chasing the facts and an environment in which decision making, progress, and governance are professionally organized.

The core

Project, program, and portfolio are therefore not interchangeable words. They are different levels of governance with different purposes, different success criteria, and different roles.

The same is true for predictive and adaptive working. That is not a matter of identity, but of selecting the approach that best fits the objective, uncertainty, risk, and context.

It is precisely by keeping those concepts clear from the start that it becomes easier to set up the right governance, create the right expectations, and place the right people in the right roles.