A time-bound effort to deliver specific outputs
A project is a temporary endeavour undertaken to create a unique product, service, or result. Two words carry the definition: temporary means it has a defined start and end, and unique means it is not the routine running of an existing thing. A project is judged on three constraintsConstraintStrategyA limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundaryView reference → at once, and tightening any one of them loosens the others.
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 stakeholdersStakeholderTeam & OrganisationA person with influence over the productView reference → as well. Modern practice keeps the triangle for control and adds outcomeOutcomeStrategyA 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.
A team commits to a redesigned checkout flow: scope defined, eight-week schedule, two engineers and a designer costed in. Three weeks in, research surfacesSurfaceExperience DesignA place inside a screen, the features that occupy it, and the rule that decides who wins itView reference → 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 releaseReleaseProduct 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.
Scott Berkun's Making Things Happen examines software project management from the practitioner's side and reaches a compatible conclusion: a project lead's central obligation is to keep decisionsDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → moving, surfacing trade-offs the team would otherwise defer rather than absorb them silently. By that reading, the checkout-flow scenario above is a decision problem as much as a constraint problem — the iron triangle only helps if someone is willing to say out loud that the triangle has changed.
In the Unified Product Graph, a project lives in the delivery region as the unit of bounded execution. It connects upward through program_contains_projectproject_implements_initiativeproject_targets_milestoneproject_produces_deliverable
The work a project delivers rides project_delivers_work_item
0.41.0 gave the project the other half. Teams model in Linear, where an initiativeInitiativeStrategyA large coordinated effort to achieve a strategic goalView reference → holds projects and a project holds issues, and until then UPG carried only the upper relation. The concrete containment pairs project_contains_epic, project_contains_feature, project_contains_user_story, project_contains_task and project_contains_bug each name a real type at both ends, which is precisely what the polymorphic edge could not do, and all five joined the project's valid children, so an imported issue resolves its parent without an adapter special case. Per-instance parentage is untouched: a work item still carries exactly one parent, and what widened is the set of parents it may take, which now includes a project alongside its feature or its epic. project_delivers_work_item
The same release gave the project the strategic reach that had belonged only to the coarser initiative. project_advances_key_result, project_drives_outcome and project_assumes_assumption point outward, while constraint_constrains_project and strategic_theme_pursues_project point in, so a team that keeps its dated, owned bet in a project rather than an initiative does not lose its line to strategy. The forward verbs are the initiative's own, so a reader moving between the two granularities is not relearning the vocabulary. What was not copied down is as deliberate: a project does not enter a market segmentMarket SegmentMarket IntelligenceA distinct group of potential customersView reference →, realise a value propositionValue PropositionBusiness ModelA unique value offered to customersView reference →, unlock a revenue streamRevenue StreamBusiness ModelA source of revenueView reference →, or raise a strategic questionStrategic QuestionStrategyAn open strategic question a plan must resolve (of coordination, ownership, sequencing, or which bet to place), held explicitly until a decision retires it; the strategy sibling of research_question and design_questionView reference →. That reach stays at the initiative level, because a delivery-scoped project carrying it would be a synonym for an initiative rather than a finer grain of one.
Type-specific fields on BaseNode
start_datestringProject start date (ISO format)
end_datestringProject end date (ISO format)
methodologyenumDevelopment methodology used
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
5 phases, initial: planning · template: OPERATIONAL
6 edge types connected to this entity.
program_contains_projectproject_targets_milestoneproject_produces_deliverableproject_implements_initiativeaccount_implements_via_projectlaunch_coordinated_via_project