For PMO Directors

You run a program office. You need visibility across the work, capacity you can plan against, and a compliance story you can defend — and you evaluate tools professionally, so you want the line drawn honestly. Here it is up front: the community edition is built for the program level — one or more related projects run by a team. Portfolio governance across many programs is the enterprise edition, by design.

That split is deliberate, not a gap. TruePPM’s whole model is adoption-first: a program gets fully productive on the open-source core, and the organization adds the enterprise layer for portfolio coordination, org-wide identity governance, and compliance evidence when it needs to govern across programs. This guide covers what the core gives you today, and exactly where enterprise begins.

What you get today (community edition)

Program-level rollup

A program groups related projects under one team. The program view rolls up KPIs, cadence, and a shared risk policy across its projects, so a program manager sees the whole effort in one place — not one project at a time. This is the staging ground beneath a portfolio: real cross-project coordination, within a single program.

→ See Programs and Program rollup settings

An operational audit log

Every consequential change — membership edits, role changes, settings updates, lifecycle actions — is recorded in a workspace audit log that Owners and Admins can read. It answers “who changed what, and when” for day-to-day operations.

Be precise about what this is and isn’t: it is an operational log for running the workspace. The immutable, compliance-grade audit trail with retention guarantees and SOC 2 evidence export is an enterprise capability. If your hard requirement is tamper-evident audit for an auditor, that’s the enterprise line.

→ See Audit log

Role-based access control

TruePPM enforces a five-role model (Owner / Admin / Scheduler / Member / Viewer) on every project, at the engine level — not just hidden in the UI. People see and change only what their role allows. This is the access-control foundation. Basic OIDC/OAuth single sign-on against your own identity provider shipped in the community core in 0.4; the org identity-governance layer — SAML 2.0 federation, SCIM provisioning, LDAP/AD directory sync, and enforced org-wide SSO — sits on top of it in the enterprise edition.

→ See RBAC and Sharing & access

Self-hosted, so data residency is yours

The core runs entirely on your infrastructure — PostgreSQL, Valkey, and a Helm chart for Kubernetes. No data leaves your network, which is the foundation of any residency or regulatory story. (The compliance evidence layer on top — immutable audit, approval workflows — is enterprise.)

→ See Deployment and Security

Confidence-weighted forecasts you can repeat upward

Each project carries a Monte Carlo forecast — P50 / P80 / P95 — instead of a single optimistic date. When the CEO asks “will this deliver by Q4?”, the answer is a probability, not a guess. That’s the same number your PMs commit on, so the story is consistent from team to board.

→ See Scheduler engine — Monte Carlo

Evaluate it yourself (~10 minutes)

Run these steps in order — they start from a machine with nothing running.

1. Start the stack and load the program data set. From your TruePPM checkout (if you have not installed yet, start with Installation):

   make up
   docker compose exec api python manage.py load_sample_project --with-personas   # Atlas (default)

   Atlas is the bundled data set that contains an actual program — three related projects under one lead, which is what steps 4 and 5 are about. The command prints the sample’s persona logins (atlas-alex, atlas-priya, …) and their shared password when it finishes. On a local Docker stack (DEBUG=True) that password is demo; anywhere else it is $TRUEPPM_DEMO_PASSWORD if you set it, otherwise a random token printed once — copy it before you clear the terminal.

2. Sign in as the person who spans two teams. Open http://localhost:5173 and sign in as atlas-jordan — Jordan Blake, Product Owner, who holds unfinished stories in both of Atlas’s active sprints: Platform Core’s Sprint 5 and GTM Readiness’s Enablement 2.

3. Open the multi-team sprints lens. In the left navigation rail, under Deliver, click Sprints (/projects/:id/sprints), then flip the [ This project | My Teams (2) ] toggle in the breadcrumb row to My Teams. It aggregates the active sprints across projects into one view — day-of-sprint, remaining points, capacity, trend, and forecast, sorted most-behind first — without opening each project.

   The lens is per person, not per program

   The toggle appears only for someone who owns unfinished work in two or more simultaneously active sprints — it aggregates your sprints, so it is a delivery lead’s view rather than a PMO rollup. That is why this step signs in as Jordan and not as the PMO director; the program-level picture is steps 4 and 5. Signed in as anyone else, the control stays hidden until you assign yourself a task in each project’s active sprint.

4. Open the program view. Sign in as atlas-alex (the Atlas program lead) and use the top-bar location switcher to select the Atlas Platform Launch program rather than a project inside it. Open its Overview (/programs/:id/overview) — the rollup across its three projects, the cross-project picture a program manager works from.

5. Follow the cross-project critical path. Click Schedule in the same rail (/programs/:id/schedule). Platform Core gates Migration, which gates the public-launch milestone — one critical path running straight through three project boundaries.

6. Open the audit log at Settings → Audit log, signed in as the admin account you created at install. Confirm that operational changes are recorded with who and when. The audit log needs the workspace Admin or Owner role, and the sample data grants none: every Atlas persona — including atlas-priya, who is a Program Manager on Atlas — is an ordinary workspace member, while the install’s superuser is the implicit workspace Owner.

Then judge it against your real bar. Your top criteria — a one-glance portfolio dashboard across 40 projects, enforced org-wide SSO with directory sync, and a tamper-evident audit trail — are enterprise, and intentionally not in this repo. The honest question for the community edition is narrower: does a single program run cleanly on the open core, so adoption can start before the portfolio layer is bought?

Where the line is: community vs. enterprise

Capability	Edition	Why
Program-level rollup (related projects, one team)	Community	Cross-project coordination within one program
Operational audit log (who changed what)	Community	Day-to-day workspace operations
Five-role RBAC, self-hosted	Community	Access-control and residency foundation
Per-project confidence forecasts (P50/P80/P95)	Community	The number you repeat to the board
Basic single sign-on (OIDC/OAuth via your own IdP)	Community	Login federation a self-hoster expects (shipped in 0.4)
Portfolio dashboard & health scores	Enterprise	Visibility across many programs
Org identity governance (SAML 2.0, SCIM, LDAP/AD sync, enforced SSO)	Enterprise	Directory-driven provisioning and enforced org-wide SSO
Immutable audit trail, SOC 2 evidence export	Enterprise	Tamper-evident compliance, not operations
Cross-program resource leveling & heat map	Enterprise	Capacity across programs
Demand intake & prioritization workspace	Enterprise	Portfolio investment governance

The test

“Would a program manager need this to run their program?” → community. “Is this coordination across programs, org-level policy, or compliance evidence?” → enterprise. The community edition has to be fully functional for one program on its own — that’s the adoption flywheel the whole model depends on.

Where to go next

• Installation — stand up an instance, or send this to whoever will
• Evaluation guide — the Atlas sample, a three-project program at scale
• Programs — the program entity and its rollup
• RBAC and the Audit log — the governance surface available today
• Roadmap — the enterprise portfolio layer and when it lands