Climbing flight is a project, climbing them all is a program

Climbing flight is a project, climbing them all is a program.


Release planning generally focuses on the process needed to deliver functionality from projects. Projects are a central fixture of business, so it is easy to overlook program and portfolio release. Release planning for portfolios, programs and projects each has similarities and differences.

Project Level Release Plans: The project release plan describes what the team plans to deliver and when they intend to deliver.  These are a reflection of the team’s capability (reflected in the team’s velocity) and the product owner’s prioritization and strategy. An individual project’s release plan is very focused on the team’s ecosystem and generally has more a tactical orientation.  Project release plans are typically very granular, showing individual stories.

Program-Level Release Plans: Program release plans have to reflect a significantly larger number of moving parts than an individual project. The Project Management Institute (PMI) defines a program as a group of related projects, subprojects and program activities. Programs, because of their breadth, have more dependencies between projects and subprojects and will require more coordination, which impact both technical and business components. For example, earlier in my career I participated in a number of bank merger projects. Those projects were classic programs that included account conversions, application changes, signage/branding changes and business process changes. A change in the plan for one component could potentially cause a change in all of the rest of them. Also after a point the cutover date was nearly impossible to change. Developing a program release plan reflecting the needs and worries of a wide range of product owners is more than just assembling a view of all of the project release plans. Typically program-level release plans are less granular than project release plans showing the delivery of features and epics (collections of stories).

Portfolio-Level Release Plans: Portfolio management exists to help organizations maximize the impact of IT or project budget. In a perfect world, the portfolio of IT projects would be driven by the organization’s strategy and anticipated business value. Projects that are critical to business strategy and deliver the highest value would be prioritized, and then magically there would be capacity within the organization to tackle the project/program in the prioritized order. That magic is reflected in portfolio release plan. Portfolio release plans use inputs that include the organization’s strategy, estimates of business value and budgetary cost, the projected capacity AND technical capabilities to generate a plan that forecasts the evolution of the overall organization. A typical portfolio release plan will be at a high level showing product, programs and projects.

All three release plans are related. Project release plans influence program release plans and program release plans influence portfolio release plans. However, each release plan is not simply an aggregation from one level to the next. Project-level release plans are the most granular and are generally a reflection of the product owner’s needs and team performance.  Program-level release plans require negotiating the needs of multiple product owners, recognition of potential dependencies and reflect the performance of multiple teams. Portfolio release plans must integrate and balance organization level needs, capacities, capabilities and even politics. All three are important and having one does not lead linearly to the next.