Four months after the release of the PMBOK Guide 8th Edition, the discussion has been active, and at times, polarized.

Before getting into the substance, as a member of the core development team, it is worth offering a bit of context on how a guide like this comes together. The development team members are not a single, uniform group. They are practitioners from different industries, alongside those with academic backgrounds in project management. Inevitably, that means there is no single, fully aligned viewpoint behind every line. What exists instead is a convergence of perspectives, some grounded in practice, some informed by research, and many shaped by the tension between the two.

The guide does draw from established thinking, definitions, and literature. But it is not an academic publication, nor is it intended to be one. It has to remain usable in practice. That means striking a balance between conceptual clarity and practical applicability, without turning it into a document that requires citations every few sentences to justify its position. Moreover, in many cases, practice moves faster than research. The guide therefore leans toward what is observable and applicable in real project environments.

Scope of the PM Body of Knowledge (PMI, 1987)

It is also important to remember where the PMBOK sits. Project management does not exist in isolation. It operates at the intersection of general management, technical or industry-specific domains, and supporting functional disciplines such as finance, safety, and sourcing. Trying to produce guidance that is equally relevant across that spectrum is inherently challenging.

Two themes worth unpacking

There has been no shortage of criticism since the release. Some question the reintroduction of processes, even though they never really left. Others ask why the principles were reduced to six, and not three or eight. There are also views around the reduced visibility of areas like procurement. These are not noise. They are valid questions, and I’ve had the chance to engage with many of them across talks, webinars, and community discussions.

Among these, two themes tend to come up most consistently: the perceived over-emphasis on value, and the new definition of a project. These are the two I want to focus on here, and offer some perspective on how we, as a team, worked through them.

Over-emphasized talk of “value”

The emphasis on “value” has drawn criticism, but the underlying issue isn’t new. If anything, it has been sitting in plain sight for years.

Most organizations talk about value. Fewer define it precisely. Even fewer align around it. In some cases, that’s perfectly fine. If an organization has made a conscious decision that projects are about delivering outputs, and that success is measured accordingly, then there is nothing inherently wrong with that model. In that context, project managers should focus on delivering those outputs reliably and efficiently.

The problem is that this level of clarity is not common. What we have seen, both before and during the development of the guide, and reinforced through feedback, is a persistent disconnect between what projects deliver and what they were meant to achieve.

Take a typical commercial setup. A contractor operates under a time-and-material model, performs well, delivers with minimal quality issues, and meets all contractual obligations. Internally, the project is seen as a success. Revenue is strong. Execution is clean. But the client is over budget. Delays come from adjacent scopes, or from the client’s own operations. From their perspective, the project has failed.

Both views are technically correct. And that is exactly the problem.

Without a shared understanding of value, success becomes relative, and often contradictory.

The same misalignment shows up in how organizations define priorities. In high-risk industries like oil and gas, safety is often described as the primary value. Many would argue, correctly, that a project with a fatality cannot be considered successful under any circumstance.

Yet in practice, safety is not always reflected that way in project scorecards. It may carry 10% weighting, while efficiency carries 40%. In some cases, it is excluded altogether on the basis that it is a “minimum expectation.” The message that sends to project teams is not always intentional, but it is clear.

What gets measured gets prioritized.

This is the gap the emphasis on value is trying to address. Not by redefining what every project should be, but by forcing a more explicit conversation. Because without that alignment, projects can be executed extremely well, and still miss the point entirely.

Are we demanding too much of project managers?

Projects operate within a wider system, shaped by business strategy, funding decisions, operating models, and stakeholder actions. Value is not created by delivery alone, and it is not owned by a single role. In that sense, expecting project managers to be solely accountable for value would be unrealistic.

But that is not the intent.

The expectation is not ownership of value in isolation, but awareness and alignment. In practice, project managers negotiate trade-offs constantly. Scope, schedule, cost, quality, stakeholder expectations. These decisions are made every day, often under pressure.

When the intended value is clear, those trade-offs become more meaningful. Priorities are easier to align. Decisions are more consistent. Without that clarity, decisions are still made, but they are made in isolation, often optimizing for local success rather than overall outcomes.

This becomes even more visible in complex projects. In joint ventures, proof-of-concept projects, or new operational models, the stakes go beyond delivery. The outcome of a single project can influence whether a business continues in that market.

In these cases, project managers are often the ones presenting the final outcome, even though they do not control all the variables that determine success. That disconnect is real.

Which is why, in practice, the lifecycle of a business project does not start at project initiation, and it does not end at project closure. It starts with opportunity shaping and ends with a handover back to commercial or operational teams. That is a broader discussion, but it reinforces the same point.

Anchoring delivery to value is not an overreach. It is a way to keep execution connected to intent.

And if your experience is that projects in your organization are already well aligned, that value is clearly defined, and no additional emphasis is needed, then that is fair.

In that case, this shift may simply not speak to your context.

The definition of a project is not being simplified. It is being reframed.

Another point of contention is the updated definition of a project. Most of the criticism focuses on the first sentence:

“A temporary initiative in a unique context undertaken to create value.”

On its own, it can feel broad.

But the full definition goes further:

Project. A temporary initiative in a unique context undertaken to create value. The temporary nature of a project indicates a beginning and an end to the project work or a phase of the project work. A project’s unique context can be driven by its distinct goals, environmental conditions, approaches, stakeholders, or other dimensions. Projects can be stand-alone efforts or part of a portfolio or program.

Some of the concerns are understandable.

“Temporary” is seen as less explicit than defining start and end points. “Value” is viewed as ambiguous. There is also concern that the definition blurs boundaries with programs and portfolios, and no longer reflects a clear continuum.

That last point comes up often. It is not entirely unfounded, but it is also largely a matter of how the definition is read. Projects are described as stand-alone efforts that can also sit within programs and portfolios, which are defined separately. When viewed through the lens of a value delivery system, the relationship is still there, but less rigidly prescribed.

Project as part of a value delivery system (PMI, 2025)

The guide offers a way to frame that system, not the only way.

There is also a more practical reason behind the change.

The previous definition relied on the word “endeavor.” While familiar in English, it does not translate consistently across languages. In Spanish, Indonesian, or even other widely used languages, it can become “effort,” “initiative,” or something closer to a general activity.

In Indonesian, for example, it may be translated as upaya or even perjalanan, which leans closer to an effort or a journey than a structured undertaking. This may seem minor, but it has been a consistent piece of feedback over the years. Moving to “initiative” provides a more stable and translatable anchor without losing the intended meaning.

Why make the definition more inclusive?

The previous definition has been in place for decades. There was no immediate urgency to change it, but there was value in refreshing it to better reflect how work is structured today.

In practice, almost any body of work can be structured as a project. That does not mean everything should be treated as one. People projectize work all the time. An engineer may structure their tasks as a project, coordinate stakeholders, track progress, and manage dependencies. That does not mean they are formally recognized as a project manager, or that the organization governs that work in the same way.

Organizations decide those boundaries. The new definition does not override that. It allows for it. It gives organizations room to define what a project means in their context, and how governance, roles, and expectations should scale accordingly.

Final thought

No single guide will ever represent the full body of knowledge of project management. And it shouldn’t.

Project management draws from multiple sources, industry practices, regional approaches, academic research, and, often most importantly, the lived experience of practitioners.

The PMBOK Guide is one of those references. It is not intended to be the only one. There is value in looking beyond it, whether that means exploring other frameworks, industry-specific practices, or simply learning from those who have worked on different types of projects.

But if you are just starting out, there is nothing wrong with starting here. The guide is facilitated by the Project Management Institute, the largest professional body in project management, reflecting ongoing engagement with practitioners and evolving industry trends.

It was certainly my starting point.

I first picked it up in 2005, when I was assigned to my first project as a network engineer, working on upgrading a wide area network backbone for one of the largest state-owned banks in Indonesia. I returned to it again in 2018, when I was asked to manage the first integrated geothermal campaign for a major operator.

Different contexts. Different levels of complexity. But the same need to make sense of how work is structured, delivered, and connected to outcomes. That is what a guide is meant to support. What comes next is how we build on it.