Decoding A Program – What It’s and What It’s Not!

Recently, I was interacting with a few project managers who have years of experience in the field and they wanted to pursue program or portfolio management. They quickly understood portfolios, because it’s sharply different and distinct compared to projects. 

However, they struggled to understand program and its management – particularly the PMI way. 

Certain questions came-up:

1. Why not take a big project in place of a program?
2. If programs have strategic alignment, then why we need portfolios?
3. What exactly are the components of a program? Are operations part of it?
4. In my organization, many projects are running, but there are no programs. Why is that?
5. I tried to run a program in my organization, but the Project Management Office (PMO) rejected the proposal.
6. And more…

In this article, I'll elaborate on the program management in what it's and what it's not. It'll follow my CIPSA Article Series. CIPSA is world’s only practical, hands-on Scaled Agile certification. You can read the series here:

CIPSA – What It's and What It's Not

This approach benefits both the CIPSA aspirants and successful CIPSAs. Hence, we’ll take a similar approach here.

Such articles can NEVER be written by Gen-AI. It takes deep understanding, adherence to program standards, years of personal practice and experience to write on program management. Artificial intelligence (AI) can not do that.

Now, let us dive-in.

-- 

1. Not Disparate Goals, but Common or Complementary goals.

Program components will have common or complementary goals, not disparate ones. 

Program can have components such as projects and subprograms. Projects are usually the core components of a program. Subprogram is a group of related projects managed as a program within a program. 

All the program components will have common goals. These goals will be documents in the Program Management Plan. In fact, the goals are in the Program Governance Plan, which is part of the Program Management Plan. 

2. Not Outputs or Outcomes, but Benefits.

Projects provide the outputs/results (deliverables). Programs deliver the benefits. 

The definition of a program given by the Project Management Institute (PMI) says it clearly. It's noted below:

"A program comprises related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually."

Did you notice? In programs, it's about benefits. We manage the related group of projects and subprograms in order to deliver benefits to the organization. This is not possible if you  run them separately. 

3. Not Disparate Benefits, but Common Ones.

Program components jointly produce common benefits. 

This is related to the first point. However, it's with respect to the benefits – not goals. It’s possible that the program components don’t jointly contribute to the delivery of common benefits, but disparate ones.

In such a case, if the program components are related only by common sources of technology, stakeholders, or geographical locations etc., they are better managed as portfolios rather than as programs. It's very important to understand.

For example, it's possible in an organization you've multiple business units (BU). One BU is very specific to North American region. Within this portfolio, you have a collection of projects, programs, subportfolios, operations. 

What's the commonality here? The commonality here is geographical location.  

4. Not Isolated, but Related.

Program components are related to each other. It's a group of related projects and/or subprograms.  

The components in a program are always related. It's a group, not a collection of components as in portfolios. This relatedness is always there among the program components.

Because of this related, we have interdependencies among the program components. These interdependencies can be visually shown by the Program Roadmap.

5. Not Alone, but can be Stand-alone and a part of.

Programs can be stand-alone and directly part of the organization.

Usually, programs are part of a portfolio, which is used to directly achieve the organization's strategic business objectives. 

Programs can also be stand-alone, i.e., not part of any portfolio. When a program is stand-alone, it may inherit some of the characteristics of a portfolio. In such a case, the role of a Program Manager has to be modified. 

6. Incremental or Collective Benefits, but not without any Benefits.

Programs are there fundamentally to deliver benefits and hence value to the organization.

Program benefits can be incremental in nature. Taking an example consider a community development program – parks, library, play area etc. The outcomes, coming from projects, start delivering benefits when they are finished. The benefits here are incremental. Is not it? 

Program can also deliver benefits all at once, i.e., as a unified whole. In this case the benefits of a program are not realized until the entire program is completed. 

7. Not Controlling Uncertainty, but Embracing Uncertainty.

Unlike projects where uncertainties are to be constrained and controlled, at program level, uncertainties are embraced. 

Projects try to minimize uncertainty and risks. The idea is to minimize threat and maximize opportunity. Programs, on the other hand, operate a higher organizational level. Hence, they have more authority and vision. Uncertainty is embraced and used as a tool to drive opportunities or find ways to reduce risks.

8. Not Reactive, but Proactive.

This is with respect to change management. In Programs, changes are managed in a proactive way, not in a reactive manner. 

For program components such as projects, program managers expect consistent level of performance - on time, within budget etc. In addition, program Managers can create new components or cancel existing components. This is to ensure benefits are in alignment with strategic objectives.

One can you say that a program proactively uses change management to keep the program and its components aligned with the various aspects of the environment. 

9. Not Manage and Control, but Accept and Adapt.

This is with respect to change management. 

In a program, changes are accepted and adapted for optimization of benefits delivery. 

Projects focus on keeping change managed and controlled. The idea is to control with the project baseline. In portfolios, we continuously monitor change in the broader internal and external environments and consider strategic changes with an overall focus on value. Portfolios have organizational horizon for change management.

Programs, on the other hand, accept and adapt to change. This is done to optimize benefits delivery. Benefits are realized as a program’s components deliver outcomes. 

--

Summary Table: Program – What It’s and What It’s Not

Conclusion

I’ll elaborate a bit more on Change. In fact, there is Change Principle for Program Management in the Standard for Program Management, which tells this: 

Manage program change to improve effectiveness and efficiency of benefits realization, delivery, and sustainment during the program life cycle and after its transition to an organization’s operations.

Simply put, you embrace change with an overall focus on program benefits realization, transition, and sustainment.

To know more on change management flow in Program Management, you refer to this article: 

Program Change Request Management (PgMP) and Flow – The Standard for Program Management

You may also like:

[1] PfMP Live Lessons - Guaranteed Pass or Your Money Back

[2] PMP Live Lessons - Guaranteed Pass or Your Money Back