Program Management

Program Management is ProBeya's module for coordinating groups of related PPM projects. A program is a container that links multiple projects together for unified reporting, cross-project dependency management, master schedule analysis, and aggregated health and budget monitoring.

Programs sit above individual projects in the PPM hierarchy. While a project delivers a specific output, a program delivers a strategic outcome by orchestrating the combined delivery of its constituent projects.

Overview

Large organizations run dozens of projects simultaneously. Without program-level coordination, interdependencies between projects go unmanaged, conflicting schedules are discovered too late, and leadership lacks a consolidated view of progress. ProBeya's program management module solves this by:

• Grouping projects under named programs with defined managers and sponsors.
• Aggregating health status using a worst-case rollup (any red project makes the program red).
• Computing timeline envelopes from the earliest start to the latest end across all projects.
• Managing cross-project dependencies with predecessor/successor links between projects.
• Generating a master schedule that consolidates all project WBS elements, milestones, and critical paths.
• Detecting schedule conflicts where cross-project dependencies are violated.
• Analyzing delay impact to understand how a delay in one project cascades across the program.

Getting Started

1. Navigate to the Programs section from the main PPM menu.
2. Click New Program and provide:
   • Name: A descriptive program name (e.g., "Site Expansion Program FY2026").
   • Description: The program's strategic objective and scope.
   • Program Manager: The person accountable for program delivery.
   • Sponsor: The executive sponsor providing governance and funding.
   • Planned Start/End Dates: The target timeline for the entire program.
   • Tags: Optional labels for categorization and filtering.
3. Add existing PPM projects to the program using the Add Project action.
4. Define cross-project dependencies to capture scheduling relationships between projects.
5. Use the program dashboard to monitor aggregated health, timeline, and master schedule.

Key Concepts

Term	Definition
Program	A container grouping related PPM projects for coordinated management. Programs have their own lifecycle: proposed, approved, active, on_hold, completed, cancelled.
Program Manager	The person accountable for program-level coordination, risk management, and stakeholder reporting.
Sponsor	The executive providing governance oversight and funding authority.
Program-Project Link	The association between a program and a project. Links can be soft-removed (marked with removedAt) without deleting the project itself.
Cross-Project Dependency	A scheduling relationship between two different projects within the same program. Specifies predecessor/successor, dependency type, and lag days.
Master Schedule	A consolidated Gantt-like view of all project WBS elements, milestones, and dependencies across the entire program.
Health Rollup	The aggregated health status of a program, computed as the worst-case status across all child projects.
Impact Analysis	A BFS traversal of cross-project dependencies to determine which projects are affected by a delay and by how much.

How It Works

Program Lifecycle

Programs follow a managed lifecycle with validated status transitions:

From	Allowed Transitions
proposed	approved, cancelled
approved	active, on_hold, cancelled
active	on_hold, completed, cancelled
on_hold	active, cancelled
completed	(terminal)
cancelled	(terminal)

Invalid transitions are rejected at the API level. For example, a program cannot move directly from proposed to completed.

Project Association

Projects are linked to programs through a join table. Each link:

• Records when the project was added to the program.
• Supports optional notes about the project's role in the program.
• Can be reordered (sort order) for display purposes.
• Is soft-removed (sets removedAt timestamp) rather than hard-deleted, preserving audit history.

A single project can belong to multiple programs if needed (e.g., shared infrastructure projects).

Aggregated Health

The health rollup uses a worst-case algorithm:

1. Fetch the health status of all active (non-removed) projects in the program.
2. If any project is red, the program health is red.
3. Else if any project is amber, the program health is amber.
4. Otherwise, the program health is green.

If the program has no projects yet, the health defaults to not_started.

Aggregated Timeline

The timeline envelope is computed by:

• Finding the earliest planned start date across all child projects.
• Finding the latest planned end date across all child projects.
• Returning the project count for context.

This gives program managers a quick view of the overall program span without drilling into individual projects.

Cross-Project Dependencies

Cross-project dependencies define scheduling relationships between different projects. Each dependency specifies:

• Predecessor Project: The project that must complete (or reach a milestone) first.
• Successor Project: The project that depends on the predecessor.
• Dependency Type: The scheduling relationship (finish-to-start, start-to-start, etc.).
• Lag Days: The minimum time gap between predecessor completion and successor start.

Validations enforce that:

• Predecessor and successor must be different projects.
• Both projects must belong to the same organization.
• No circular dependency chains are created (A depends on B depends on C depends on A).

Master Schedule

The master schedule consolidates data from all projects in the program:

• All WBS elements (tasks and milestones) from every project.
• Intra-project WBS dependencies (task-to-task within a project).
• Cross-project dependencies (project-to-project across the program).
• Critical path computation spanning the entire program (not just individual projects).

This enables program-level Gantt visualization and identifies the cross-project critical path -- the longest chain of dependent tasks that determines the program's overall duration.

Schedule Conflict Detection

The conflict detection procedure scans all cross-project dependencies and flags those where the successor project's start date precedes the predecessor project's end date plus lag. For each broken dependency, it reports the gap in days so program managers can quantify the scheduling problem.

Delay Impact Analysis

Impact analysis answers the question: "If Project A is delayed by N days, what happens to the rest of the program?" It performs a BFS traversal through cross-project dependencies, accumulating delay at each hop:

• The starting project receives the initial delay.
• Each successor project receives the delay minus any existing buffer (gap) in the dependency.
• The traversal continues until all downstream projects are reached.
• The result is a tree of affected projects with cumulative delay and traversal depth.

Configuration

Setting	Type	Description
Name	String	Program name, used in lists and dashboards.
Description	String	Program scope, objectives, and context.
Program Manager	User reference	The person accountable for program delivery.
Sponsor	User reference	The executive sponsor.
Planned Start/End	Date	The target timeline for the program.
Tags	String array	Labels for filtering and categorization.
Status	Enum	Lifecycle state with validated transitions.

Permissions

• PMO Coordinators and Program Managers can create programs, manage project associations, and define cross-project dependencies.
• Project Managers can view programs their projects belong to and access the master schedule.
• Workspace Admins have full access to all programs and their data.
• Team Members with project read access can view program dashboards and aggregated health.
• All program data is scoped to the organization via organizationId.

Tips & Best Practices

Define cross-project dependencies early

Do not wait until projects are in trouble to map dependencies. Defining them upfront enables proactive conflict detection and impact analysis before delays cascade.

Use the health rollup in executive reporting

The worst-case health rollup gives executives a reliable signal. If a program shows green, every project in it is green. This eliminates the common problem of hiding red projects behind aggregated averages.

Run impact analysis before approving schedule changes

Before accepting a delay on any project, run impact analysis to see which downstream projects are affected. The cumulative delay may be much larger than the initial delay suggests.

Keep program-project links current

When a project is descoped or cancelled, soft-remove it from the program rather than leaving a stale link. Stale links distort the health rollup and timeline calculations.

Troubleshooting

Issue	Cause	Solution
"Cannot transition program" error	Invalid status transition (e.g., proposed to completed).	Follow the allowed transition paths. Move the program through intermediate states first.
Cross-project dependency rejected	Circular dependency detected.	Review the dependency chain. Remove or restructure dependencies to eliminate the cycle.
Health rollup shows not_started	No active projects linked to the program.	Add at least one project to the program.
Master schedule is empty	All projects were soft-removed from the program.	Re-add projects or check that active project links exist.
Impact analysis shows no downstream effects	No cross-project dependencies defined for the starting project.	Define predecessor/successor relationships between projects.

Related Features

• Portfolio Management -- Programs roll up into portfolios for enterprise-level governance.
• Monte Carlo Simulations -- Run probabilistic forecasts at the project or program level.
• Resource Planning -- Allocate resources across projects within a program.
• Reports & Export -- Generate program-level status reports for steering committee presentations.