Please login or join to subscribe to this thread
In fact, there are grey zones. Mainly, if you see inside the standards. No matter you are talking about programs or projects the focus is the solution to be created. When that in hand, in the case where I am working today, we think about the architecture of the solution or talking in other way we think about the components and the relations between the components. That helps us to split the solution into programs. The intention is to help in the control and monitoring of the whole solution.
There is no standard operating definition for what constitutes one vs the other - it varies industry-to-industry and company-to-company. I would suggest that when you manage an initiative as a program, there is likely to be more focus on the benefits and operational state of the deliverables from components completed before the program ends than there might be with projects.
Governance-wise, you would usually see differences in structure and responsibilities. For example, a program management office might exist for large programs whereas a PMO would usually not be serving the needs of a single project.
As my colleagues said, don't get too concerned with the terms project and program. I work in a massive enterprise where the lines blur and there are programs within programs. When people ask what I do, it can be hard to describe.
At the same time, I'm one of the people who are expected to define the terms so that we are all speaking a common business language.
On a program, you are often looking at the whole life-cycle of a product. There is the first item development, low rate production, ramp-up to full scale production, product support, product improvements, production system improvements, office process improvements, and everything else in the greater scale of how you launch to retire a product.
A project might consider all of those, but focus on a specific target, among many competing agendas. A program often has to balance the intents of many projects/agendas to achieve a larger goal. What makes sense at the program level, often does not at the project level.
A project is a single endeavor to attain a specific objective, while a program is a set of related projects that are managed in a coordinated manner to obtain benefits not available from managing them individually.
See my slideshare upload about some key differences.
and an article about program management being agile in it's core
Thank you so much for your contributions to a very interesting discussion.
yes, a great question.
When I became a program manager in 2002, I quit acting as a project manager (or I would have been micromanaging). For example I did no longer care much about budgets and schedules. A good program manager creates the funds needed and delivers at the times that provide the greatest sustained value.
The biggest difference in my view is the mindset (and Pellegrinelli's research is showing this).
I contribute the lack of understanding about the differences between projects and programs to the failure of what people think are large and complex projects.
Indeed there are good and established standards about program management, both from PMI and Axelos (MSP), as of late by the EU Commission (PgM2) and there is also an ISO standard. All of which are quite similar, for example all focus on benefits instead of products. So there is a sound and practical global reference companies and governments could follow, and US federal government signed a law in 2015 to promote program management in their organizations (PMIAA).
It is not simple though to grasp it, only about 3000 people ww managed to obtain the PMI PgMP certificate (think MSP are more, but do not have the numbers) vs. more than a million PMPs.
No wonder that many practitioners and organizations continue to confuse project and program management.
Kiron and Sergio made good points.
When I am asked about this, I have a bit of a different answer than others seem to give.
A project has a definite end. However a "program" may not.
For example a project might be to set up a new assembly line (perhaps for manufacturing light bulbs or whatever). That project might be part of an overarching program to produce a new product (light bulbs) - and the program (production of light bulbs) will live on potentially forever even though the project has been completed.
There may be additional projects as part of the program as well - for instance in a few years there might be a required upgrade to the assembly line which requires a new project. The program to manufacture light bulbs may live on forever and require new projects over time, but each project under the program has a defined scope and endpoint where the program does not. And a program may also include non-project related aspects (such as maintenance of the assembly line, weekly scheduling of workers on the line, etc.).
This is in contrast to a portfolio, which is a collection of projects (typically related). But even within a portfolio, each of the projects as a defined scope and endpoint whereas a program may have no end.
As stated above there are gray zones galore, and what I say is not strictly based on any sort of industry definition, and perhaps my example isn't all that great, but this is how I typically talk to people about it based on my own background and experience.
Please login or join to reply