Portfolios and projects

How IntelliPPM models the portfolio → project → work breakdown hierarchy, and why the model is event-sourced.

On this page

The hierarchy

IntelliPPM models work in a strict hierarchy:

Tenant
  └─ Portfolio (strategic objectives + EVM rollup + governance policy)
        └─ Project (baseline + WBS + budget envelope)
              └─ WBS node (work that can be assigned, scheduled, costed)
                    └─ Activity / task (the unit imported from source systems)

The hierarchy is enforced — tasks always belong to a WBS node, WBS nodes always belong to a project, projects always belong to a portfolio. This is intentional. Tools that let work float free of a portfolio (we are looking at every "spreadsheet plus a status meeting" workflow) lose the strategy-to-ledger traceability that is the whole point of an enterprise PPM platform.

Portfolios

A portfolio is the smallest grouping where strategy meets execution. It holds the strategic objectives that the AI Prioritizer head ranks projects against, the consolidated EVM view that executives consume, and the governance policy that controls how aggressive the AI plane is allowed to be inside it.

A useful mental model: the portfolio is what an exec would want a status summary about. If a status summary across two pieces of work would not be useful, they probably belong in different portfolios.

Projects

A project is the unit of delivery. It owns a baseline, a budget, and the WBS that decomposes the work. Projects can be imported from source systems (Jira, Project for the Web, Planner) or authored natively in IntelliPPM. When imported, the canonical event bus and Identity Graph maintain the round-trip — a write in IntelliPPM lands back in the source system, with echo-loop prevention so you do not get a stutter.

WBS

The Work Breakdown Structure is hierarchical and event-sourced. Every mutation to the WBS — adding a node, re-parenting, changing dates, changing dependencies — emits a canonical event that downstream projections (the schedule view, the EVM view, the resource view) react to. Cycle detection is enforced at the placement step, not after the fact, so you cannot create a circular dependency and discover it later.

Why event sourcing

Two reasons:

  1. Audit. Every state change in IntelliPPM is a fact in the event

log. You can reconstruct the portfolio's state at any point in time, which is the foundation for AI HITL provenance — every AI recommendation cites the events it was computed against, and every AI-originated state change carries actor.type=ai plus the recommendation that produced it.

  1. Integration. The same event stream that powers internal

projections also powers the Integration OS — when a Jira issue updates, it lands as a canonical event, gets transformed by a declarative mapping, and flows into both the local projections and any other connected source system that subscribes to that canonical type.

Read further