What Is a Project? Definition per PMBOK 8 (2025)

This what is a project covers everything you need to know. Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Have you ever worked on an initiative that everyone called a “project,” yet it had no defined end date, no clear deliverable, and no one could explain when — or how — it would finish? Or worse: have you watched an entire team spend months on something that ultimately delivered zero value to the organization, because from day one nobody had a precise understanding of what a project actually is?

This problem is far more common than it should be. And the root cause is surprisingly simple: most professionals — including many project managers — lack an accurate, up-to-date definition of what constitutes a project. Without that foundation, every subsequent decision — scope, schedule, budget, risks — is built on shaky ground.

In this comprehensive guide, fully updated for PMBOK 8, you will learn:

• The official definition of a project according to PMBOK 8 — and what changed from previous editions
• The essential characteristics that distinguish a project from operations and ongoing processes
• The 6 Principles and 7 Performance Domains that underpin the new vision of projects
• The project life cycle across the 5 Focus Areas of PMBOK 8
• How to adapt the concept of a project in predictive, agile, and hybrid contexts
• The 5 most common mistakes when defining and running projects — and how to avoid them
• A quick-application checklist to validate whether your initiative is, in fact, a project

1. WHAT IS A PROJECT — DEFINITION ACCORDING TO PMBOK 8

Straight to the point

According to PMBOK 8 (2025), a project is a temporary initiative in a unique context, undertaken to generate value.

This definition rests on three fundamental pillars:

• Temporality: Every project has a defined beginning and end. It is not a continuous activity — it is an effort with a deadline.
• Unique context: Every project takes place under singular circumstances. Even if two projects appear similar, the context (team, organization, market, technology, timing) always differs.
• Value generation: A project exists to create value — economic, operational, social, environmental, or strategic. If it does not generate value, it does not justify its existence.

This definition represents a significant evolution from earlier editions of the PMBOK. In previous versions, the focus was on “creating a unique product, service, or result.” Now, the central focus is generating value. This changes everything: project success is no longer measured solely by scope, schedule, and cost — but by the value it delivers to the organization and its stakeholders.

What does “value” mean in the context of projects?

Value in PMBOK 8 is not limited to financial return. The concept is broad and can include:

• Economic value: Revenue growth, cost reduction, return on investment
• Operational value: Process improvement, efficiency gains, automation
• Social value: Positive community impact, inclusion, accessibility
• Environmental value: Emission reduction, sustainability, conservation of natural resources
• Strategic value: Market positioning, innovation, competitive advantage, regulatory compliance

This expanded notion of value is one of the most important changes in PMBOK 8. It reflects the reality that modern projects are evaluated across multiple dimensions of impact — not merely by compliance with technical requirements.

2. WHAT CHANGED IN THE PROJECT DEFINITION: PMBOK 7 VS PMBOK 8

The definition of “project” has undergone a significant evolution between PMBOK editions. For anyone transitioning from PMBOK 7 to PMBOK 8, understanding these differences is essential.

In PMBOK 7 (2021), a project was defined as “a temporary endeavor undertaken to create a unique product, service, or result.” This definition had been in place since PMBOK 5 and placed the emphasis on the deliverable — what the project produces.

In PMBOK 8 (2025), the definition evolves to “a temporary initiative in a unique context, undertaken to generate value.” The focus shifts from deliverables to value — the impact the project generates.

What this means in practice: If you are accustomed to PMBOK 7, the transition is not a disruption — it is an evolution. The concept of a project remains temporary and unique. But PMBOK 8 raises the bar: delivering is not enough; the project must generate value. To ensure this, the new edition brings back structured processes (40 processes with ITTOs), establishes a clear hierarchy among principles, and integrates sustainability as a requirement — not an option.

3. ESSENTIAL CHARACTERISTICS OF A PROJECT

For an initiative to qualify as a project, it must exhibit a set of characteristics that differentiate it from day-to-day operations and organizational processes. These characteristics are fundamental to project management and are reinforced by PMBOK 8.

3.1. Temporality — a defined beginning and end

Every project is temporary. It has a starting point (when the need is identified and the project is authorized) and an ending point (when objectives are achieved, the project is cancelled, or resources are exhausted).

This does not mean the project is short. A highway construction project can last ten years. But it has a planned conclusion. Unlike a continuous operation — such as maintaining that highway once it is built — which has no termination date.

In practice: If your initiative has no planned end date or clear closure criteria, it is probably not a project — it is an operation in disguise.

3.2. Unique outcome

Every project produces something that did not exist before — or that exists in a different context. Even if you have already built ten ERP systems, the eleventh is unique: different team, different organization, different requirements, different technology.

This uniqueness brings an important consequence: uncertainty. Because every project is different, there are always unknown elements. This is precisely why risk management is one of the 7 Performance Domains in PMBOK 8.

3.3. Resource constraints

Projects operate within limits. A finite budget. A team with limited capacity. Technology with constraints. A deadline that cannot be extended indefinitely. These constraints are what make project management necessary — without them, there would be no need to plan, prioritize, and control.

3.4. Inherent uncertainty and risk

No project operates in an environment of total certainty. There are always risks — technical, organizational, external, financial. PMBOK 8 acknowledges this by including Risks as one of the 7 Performance Domains and by establishing specific processes for risk identification, analysis, and response.

3.5. Focus on value delivery (not just deliverables)

This is the characteristic most emphasized by PMBOK 8. A project does not exist merely to produce deliverables — it exists to generate value. The difference is crucial: you can deliver every feature in the scope and still fail to generate value if those features do not solve the real business problem.

Practical example: A team delivers a complete CRM system on time and within budget. But the sales team never adopts it because the interface is too complex and it does not integrate with their existing tools. The project delivered scope, but it did not generate value.

4. PROJECT VS. OPERATIONS — WHAT IS THE DIFFERENCE?

One of the most common confusions in project management is failing to clearly distinguish a project from an operation. This distinction is critical because projects and operations require different management approaches.

Critical point: The transition between project and operations is one of the most neglected moments. When the project ends and operations take over, there is a knowledge transfer that needs to be planned. PMBOK 8 addresses this in the closing processes — but in practice, many projects fail at this transition because it was not considered from the planning phase onward.

Common area of confusion: A team is responsible for “maintaining and evolving the management system.” Is this a project or an operation? It depends. Maintenance is an operation. Evolving with significant new features is a project. When the two are treated as one, typically neither receives adequate attention.

5. THE 6 PRINCIPLES OF PMBOK 8 — AND HOW THEY REDEFINE THE CONCEPT OF A PROJECT

PMBOK 8 establishes 6 Principles that guide behavior and decision-making in project management. These principles are not rigid rules — they are guidelines that shape the mindset of the project manager and the team. They represent a significant shift from the 12 principles of PMBOK 7, with a clearer focus and a defined hierarchy.

Why does this matter for the definition of a project? Because these 6 principles expand what it means to “manage a project” in PMBOK 8. It is no longer just about controlling scope, schedule, and cost. It is about leading with a systems perspective, focusing on value, embedding quality and sustainability, and empowering teams. The definition of a project gains depth when read through the lens of these principles.

6. THE 7 PERFORMANCE DOMAINS OF PMBOK 8

The Performance Domains are the competency areas that must be managed throughout the entire project life cycle. In PMBOK 8, there are 7 domains — each representing an essential dimension of project management.

These domains work in an interconnected manner — not as sequential phases. Governance, for example, is not something that happens only at the start of the project: it permeates every decision throughout the entire life cycle. Similarly, Risks are not managed only during planning — they are monitored continuously.

Connection to the project definition: The 7 domains demonstrate that managing a project in PMBOK 8 means simultaneously managing 7 interdependent dimensions. This reinforces Principle 1 (Holistic View): you cannot manage scope without considering schedule, finance, risks, and stakeholders.

7. THE PROJECT LIFE CYCLE — THE 5 FOCUS AREAS

PMBOK 8 organizes the project life cycle into 5 Focus Areas. Unlike earlier editions that used “process groups,” PMBOK 8 adopts the concept of focus areas to indicate that these activities are not strictly sequential — they can overlap and repeat as the project demands.

7.1. Initiation — identify the problem and authorize the project

This is the moment to understand why the project exists. What problem does it solve? What opportunity does it capture? Who are the key stakeholders? What value does it intend to generate?

In practice, initiation includes:

• Identifying the business need or opportunity
• Defining the high-level project objective
• Identifying the key stakeholders
• Assessing preliminary feasibility (technical, financial, organizational)
• Formally authorizing the project (Project Charter)

7.2. Planning — define the path

Planning transforms the high-level objective into an executable plan. It answers the questions: what will be done, when, by whom, with which resources, and how risks will be managed.

• Define the detailed scope and the WBS (Work Breakdown Structure)
• Estimate timelines and costs
• Plan risk management, quality, resources, and communications
• Establish the project baseline
• Define success criteria — including value metrics

7.3. Execution — perform the work

This is where the plan becomes reality. The team executes activities, produces deliverables, and manages stakeholders.

• Execute the project plan
• Manage the team and resolve conflicts
• Implement planned risk responses
• Ensure the quality of deliverables
• Communicate progress and status

7.4. Monitoring and Control — track and correct

Monitor progress against the baseline and take corrective action when necessary. This focus area is continuous — it runs in parallel with planning and execution.

• Measure actual performance against planned performance (scope, schedule, cost)
• Monitor existing risks and identify new ones
• Control changes through the integrated change control process
• Verify that value is being generated as expected
• Report performance to stakeholders and governance

7.5. Closing — capture lessons learned and formalize completion

Closing is not merely “finishing the project.” It is the moment to ensure that the promised value was delivered, that lessons learned were captured, and that the transition to operations was properly planned.

• Confirm that all deliverables have been accepted
• Document lessons learned
• Release resources and close contracts
• Transfer knowledge to operations
• Evaluate whether the expected value was generated — and if not, why

8. TYPES OF PROJECTS — EXAMPLES ACROSS DIFFERENT CONTEXTS

Projects exist in virtually every area of human activity. Here are some examples:

• Information Technology: Software development, system migration, ERP implementation, digital transformation, cybersecurity
• Construction and engineering: Buildings, highways, bridges, urban infrastructure, industrial facilities
• Marketing and communications: Product launch, rebranding, digital marketing campaign, corporate event
• Business and strategy: Opening a new branch, mergers and acquisitions, organizational restructuring, international expansion
• Social impact: Public health projects, education, social inclusion, sustainable development
• Innovation and research: New product development, applied research, R&D projects, startups
• Personal projects: Building a home, organizing a wedding, planning a complex trip

Regardless of the industry, what all these examples have in common is that they fit the definition: they are temporary initiatives, in unique contexts, undertaken to generate value.

Practical tip: Use this question as a quick test: “Does this initiative have a planned ending and will it produce something that does not exist today?” If the answer is yes, it is likely a project. If the answer is “it is a continuous activity we perform to keep something running,” it is an operation.

9. WHAT CHANGED — PMBOK 6/7 VS PMBOK 8

For practitioners transitioning from earlier editions, the table below summarizes the key differences in how a project is defined, structured, and managed across the three most recent PMBOK editions.

Key takeaway: The evolution across these three editions shows a clear trajectory — from a process-heavy, deliverable-focused framework (PMBOK 6), through a principle-based, flexible approach (PMBOK 7), to a balanced model that combines structured processes with value-driven principles and sustainability integration (PMBOK 8). The definition of a project has evolved with it, and practitioners who still operate with the old “scope-schedule-cost” mindset will need to update their mental model.

10. TAILORING — HOW TO ADAPT THE CONCEPT OF A PROJECT TO YOUR CONTEXT

PMBOK 8 emphasizes that there is no one-size-fits-all approach to projects. The concept of tailoring (adaptation) is central: the project manager must adapt practices, processes, and tools to the specific context of the project. This applies from the very way the project is defined and structured.

In predictive (traditional) projects

In predictive environments, the project is defined in detail from the start. Scope is documented thoroughly, the schedule is built with sequential activities, and milestones are set in advance.

• Project definition: Formalized in the Project Charter and the Project Management Plan, with detailed scope, complete WBS, and an integrated baseline
• Life cycle: Sequential phases with approval gates — each phase must be approved before the next one begins
• Governance: Strong — governance committees, active sponsor, formal change control processes
• Best for: Projects with stable requirements, strict regulations, fixed-scope contracts (civil construction, infrastructure, regulatory projects)
• Watch out: Do not confuse rigor with rigidity — even predictive projects need flexibility to handle uncertainties

In agile projects

In agile environments, the project is defined progressively. The high-level scope is established at the start (Product Vision, Roadmap), but the details are elaborated iteratively throughout the sprints.

• Project definition: Product Vision defines the “why”; the Backlog defines the “what” — but the backlog evolves continuously based on feedback
• Life cycle: Iterative and incremental — partial deliveries each sprint, with value being generated continuously
• Governance: Lightweight — Product Owner makes prioritization decisions; agile ceremonies replace formal gates
• Best for: Projects with volatile requirements, dynamic markets, need for rapid feedback (software, innovation, digital marketing)
• Watch out: “Agile” does not mean “unplanned.” The project still needs clear objectives, defined constraints, and value metrics

In hybrid projects

Hybrid projects combine predictive and agile elements. Some parts of the project follow a predictive approach (e.g., infrastructure, compliance), while others use agile practices (e.g., software development, design).

• Project definition: The Project Charter and the macro plan are predictive; the execution of specific workstreams is agile
• Life cycle: Predictive phases with embedded agile sprints — the challenge is synchronizing both worlds
• Governance: Dual — formal governance for the project as a whole; agile governance within the iterative workstreams
• Best for: Complex projects with multiple components requiring different approaches (digital transformation, ERP with customization, organizational programs)
• Watch out: The biggest risk is the lack of integration between predictive and agile parts. Frequent synchronization meetings are essential

11. 5 COMMON MISTAKES WHEN DEFINING AND RUNNING PROJECTS — AND HOW TO AVOID THEM

Most problems in project management begin before the first task is executed — they begin at the definition stage. These are the 5 most frequent mistakes:

Mistake 1 — Calling an operation a “project”

Why it happens: Many organizations label any initiative that receives special attention or a dedicated budget as a “project.” System maintenance, ongoing support, and repetitive activities end up being treated as projects — without a clear start and end, without a unique deliverable, and without closure criteria.

How to avoid it: Apply the definition test: does the initiative have a defined deadline? Will it produce a unique result? Does it have closure criteria? If the answer is “no” to any of these questions, it is an operation. Treat it accordingly — with operations management, not project management. This changes resource allocation, governance structure, and stakeholder expectations.

Mistake 2 — Defining the project by scope instead of value

Why it happens: The natural instinct is to start with “what” — “we are going to implement a system,” “we are going to build a facility.” But defining the project by its deliverable, without clarity about the expected value, leads to projects that deliver scope but do not solve the real problem. The team follows the plan, but the result fails to generate the needed impact.

How to avoid it: Before defining scope, answer: “What value will this project generate for the organization?” If the answer is not clear, the project is not ready to begin. Use the Business Case and benefits analysis as a prerequisite — not a formality. Include value metrics in the Project Charter.

Mistake 3 — Ignoring the organizational context when defining the project

Why it happens: The project manager focuses exclusively on the project itself — scope, schedule, cost — without considering the ecosystem in which the project operates: corporate strategy, organizational culture, other concurrent projects, actual capacity of shared resources.

How to avoid it: Apply PMBOK 8 Principle 1 — Holistic View — from the project definition stage. Map how the project connects to organizational strategy, which other projects compete for the same resources, and which organizational constraints could impact it. Use the Project Canvas to visualize these connections on a single page.

Mistake 4 — Not planning the transition from project to operations

Why it happens: The project team focuses on deliverables and milestones. When the project ends, operations take over — but nobody planned that transition. There is insufficient documentation, no training, and no stabilization period. The result is that the project’s value is lost in the handover.

How to avoid it: Include the transition to operations as part of the project scope, not as something that happens “afterward.” Define operational acceptance criteria (not just technical ones), plan training and documentation, and establish a post-implementation support period. In PMBOK 8, this is part of the closing processes.

Mistake 5 — Overlooking sustainability in the project definition

Why it happens: Sustainability is still seen by many as a secondary concern, disconnected from “real” project management. The project manager focuses on schedule, cost, and scope and leaves environmental, social, and long-term considerations to “whoever handles that.”

How to avoid it: PMBOK 8 establishes “Integrate Sustainability into All Areas of the Project” as Principle 5 — it is not optional. From the project definition onward, consider: what is the environmental impact? What is the social impact? Do today’s decisions create problems for tomorrow? Include sustainability criteria in the Business Case and in the project’s success criteria.

12. QUICK-APPLICATION CHECKLIST

Use these 7 items to validate whether your initiative is truly a project and whether it is properly defined before moving to detailed planning:

1. ☐ Does the initiative have a defined beginning and end — or is it a continuous activity disguised as a project?
2. ☐ Is the expected outcome unique — or is it a repetition of something you already do?
3. ☐ Is the value the project will generate clearly defined — with measurable metrics, not just aspirations?
4. ☐ Is the project connected to organizational strategy — or is it an isolated initiative without strategic alignment?
5. ☐ Have the main risks been identified — and is there an approach to manage them?
6. ☐ Have the key stakeholders been mapped — with their expectations and potential conflicts?
7. ☐ Has the transition to operations been planned — or does the project end at delivery with “someone” picking it up afterward?

If you answered “no” to any item, stop and address it before moving forward. These are the fundamentals. Without them, the project is born compromised.

13. USEFUL TOOLS AND RESOURCES FOR DEFINING A PROJECT

To put into practice everything covered in this guide, these are the most useful tools and techniques for defining and structuring a project:

• Project Charter: The document that formalizes the project’s existence, defines the objective, high-level scope, constraints, assumptions, and the designated project manager. It is the project’s “birth certificate.”
• Business Case: The document that justifies the project from a business perspective — analyzing benefits, costs, risks, and alternatives. In PMBOK 8, it is essential for demonstrating expected value.
• Project Canvas: A visual tool that summarizes the project on a single page — ideal for quickly aligning stakeholders and maintaining a holistic view.
• Stakeholder Analysis: A mapping of interested parties with their expectations, influence, and engagement strategy. Fundamental for the Stakeholders Domain.
• Initial Risk Register: A preliminary list of risks identified during the project definition, with probability and impact classification.
• WBS (Work Breakdown Structure): A hierarchical decomposition of the project scope into manageable deliverables. The foundation for schedule and cost planning.
• Project Roadmap: A high-level view of planned deliverables over time. Especially useful in agile and hybrid projects.

14. CONNECTION TO PMBOK 8 PROCESSES

PMBOK 8 brings back structured processes — 40 processes with Inputs, Tools, Techniques, and Outputs (ITTOs). The definition and structuring of a project connect directly to the processes in the Initiation and Planning Focus Areas.

The processes most relevant to defining a project include:

• Develop Project Charter — formalizes the project and authorizes its existence
• Identify Stakeholders — maps who is impacted and who has influence
• Develop Project Management Plan — integrates all subsidiary plans
• Collect Requirements — defines what the project must deliver to generate value
• Define Scope — establishes the boundaries of the project
• Identify Risks — maps the uncertainties that could affect the project

These processes are not bureaucratic exercises — they are tools to ensure the project starts on solid foundations. The depth of application for each process should be tailored to the context, as discussed in the tailoring section.

CONCLUSION

Understanding what a project truly is — not superficially, but at a foundational level — is the first step toward managing it successfully. PMBOK 8 redefines this concept by placing value at the center of the definition and by surrounding the project with principles, domains, and processes that ensure that value is planned, monitored, and delivered.

Three essential takeaways for practice:

• A project is a temporary initiative, in a unique context, undertaken to generate value. If it has no deadline, is not unique, and does not generate value — it is not a project. And if it is a project but lacks clarity about value, it was born compromised.
• PMBOK 8 has raised the bar: with 6 hierarchical principles, 7 performance domains, and 40 processes with ITTOs, the new edition provides a complete framework for managing projects of any type and scale — from predictive to agile, from small to complex.
• Sustainability and holistic thinking are not optional: PMBOK 8 requires that projects consider systemic, environmental, and social impact from the definition stage onward. Projects that ignore these dimensions are misaligned with the current global standard.

Concrete next step: Take the project you are working on right now. Apply the Quick-Application Checklist (Section 12). If any item lacks a clear answer, set aside 30 minutes this week to fill that gap. Start with value: “What value is this project generating — and how am I measuring it?”

Free resources to apply now

• Template: Project Canvas (PMBOK 8) — map the holistic view of your project on a single page
• Template: Project Charter — formalize your project with all the essential elements

See all PMBOK 8 articles in the Complete Index

🇧🇷 Leia este artigo em português

Leia em Portugues: Versao em Portugues deste artigo

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.