When Is a Program Not a Program?
Programs are strange beasts. We know they exist. We recognize they are complex. We acknowledge they take a different approach to manage successfully. And yet, what that different approach looks like is fuzzy (at best), ignored (at worst) and very often misunderstood (in the vast majority of instances).
It doesn’t help that there are multiple different definitions of a program. What is common across these definitions is that you are managing something large and complex, that there are multiple projects, that those projects are related and that there is some expectation of benefits being realized.
The astute reader will be aware that I’m not always a fan of the definitions contained in PMI standards (although usually for reasons of precision rather than principle). In this particular instance, however, PMI has what is in my view one of the clearest and most pragmatic definitions of what actually constitutes a program:
“A group of related projects, subprograms, and program activities, managed in a coordinated way to obtain benefits not available from managing them individually.”
The nuance here is an important one: It’s not about managing a group of related projects that intrinsically make sense to do on their own, which—for reasons of magnitude—are being bundled together. It’s about a group of projects that collectively
Please log in or sign up below to read the rest of the article.