Project

Origin & evolution

The canonical definition comes from the Project Management Institute's Guide to the Project Management Body of Knowledge: "a temporary endeavor undertaken to create a unique product, service, or result." Temporary fixes the boundary in time, which is what gives a project a defined scope and a finite resource envelope. Unique separates it from operations, the repeatable work of keeping a product alive once it exists.

Alongside the definition sits the triple constraint, popularly the iron triangle: scope, time, and cost, with quality bounded inside. The triangle's enduring lesson is that the three sides are coupled. Add scope without adding time or cost and quality absorbs the strain. The constraint was formalised as a critique as much as a model. Roger Atkinson argued in 1999 that judging projects on the triangle alone was too narrow, and proposed measuring the resulting system and the benefits to stakeholders🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → as well. Modern practice keeps the triangle for control and adds outcome🏆OutcomeStrategyA desired business or user outcomeView reference → measures for success.

The framing matured again with PMBOK's seventh edition (2021), which shifted from a process-heavy model toward principles and performance domains, reflecting two decades of agile practice that treats scope as something discovered through delivery instead of fixed at the start.

How it works in practice

A team commits to a redesigned checkout flow: scope defined, eight-week schedule, two engineers and a designer costed in. Three weeks in, research surfaces a demand for saved payment methods. That is new scope. The iron triangle says it cannot be free.

The project lead has three honest moves. Extend the schedule to ten weeks, add a third engineer to hold the date, or cut something of equal size from the original scope. What she cannot do is absorb the new work silently and keep the same date, team, and quality, because the fourth option is the one that quietly produces a slipped, defect-ridden release🚢ReleaseProduct SpecificationA shipped version of the productView reference →. Naming the trade-off out loud is the whole point of treating the work as a project rather than open-ended effort.

Project vs. its neighbours

• Program: A program coordinates several related projects toward a benefit none could deliver alone. A project is one bounded endeavour with a single deliverable and a hard end. A project rolls up into a program; a program is never a bigger project.
• Product: A product is permanent and evolving; it has no end date and is judged on outcomes over time. A project is temporary and is judged on delivering its defined scope. A team can run many projects against one long-lived product.
• Operations: Operations is the repeatable work of running and maintaining what already exists, with no unique end state. A project ends when its unique result is accepted. The line is repeatability: routine equals operations, one-off equals project.

In the graph

In the Unified Product Graph, a project lives in the delivery region as the unit of bounded execution. It connects upward through program_contains_projectProgramcontainsProjecthierarchy to the program that coordinates it and through project_implements_initiativeProjectimplementsInitiativecross-domain to the strategic intent it serves. Its forward-facing edges encode the iron triangle's scope side as concrete commitments: project_targets_milestoneProjecttargetsMilestonehierarchy pins the time boundary, and project_produces_deliverableProjectproducesDeliverablehierarchy names the unique result that defines done. Modelling the deliverable as a separate connected node, instead of a property on the project, is what lets the graph answer whether a project actually shipped what it promised, rather than merely whether it closed.