What a difference between large Project and Program

Question

In PMI's "The Standard for Program Management" I have read following:

Other organizations refer to large projects as programs. These "programs" include large individual projects or a single large project that is broken into more easily managed subordinate projects.

and

Some programs deliver benefits only after all of the component projects have been completed.

I am a little bit confused now. Are there any criteria by which we can choose a representation of a work: project with sub projects or program? I thought before that projects within program are related with each other but have value itself (not so big, of course, in case if there are completed together).

---

P.S. Definition of program by PMI:

A group of related projects, subprograms, and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually.

Answer 1

The key is here....

...to obtain benefits not available from managing them individually

A Project is the smallest element that has self-contained benefit.

A Programme aggregates those benefits into a strategy.

Building a hotel is a project. It has a benefit. You can create 'sub-projects' out of each floor but their benefit is not realised until the hotel is complete.

Building a chain of hotels is a programme as you have a 'brand', a referral and discount system to encourage return custom, economies of scale during both project execution and during operation etc. Benefits which are not achievable from any single element of the programme.

After-Thoughts

Considering further on this, the definition of a Project is highly contextual, e.g. the completion of a module of code may or may not be considered a project:

1. If it is an upgrade for insertion into an existing framework then its benefit is realised when it is inserted and functional.
2. If the rest of the framework has not been written yet then it isn't a project because it does nothing without the context. Although if the context is only to code to an interface then the framework is the interface and you are back in item 1 above.

I suppose the simplest way to consider this is just to ask the question "if I stop here, do I have something that can be delivered to the key stakeholder/client or just a pile of physical/digital/intellectual stuff that just sits there?".

In my field (construction contracts) this concept is called 'beneficial use', where Works are considered complete when the Employer has put them into operation for the intended purpose.

Also, don't get confused by non-PM's using words which have specific meaning to our profession in a colloquial way, and be prepared to speak 'non-PM' when communicating outside your team. Something which may be called a "project" by the Employer, your own company, or even your boss can in fact be a programme (the "build a chain of hotels" example).

Art, of course provides it's own, rather eclectic and opinion based, context where analytical thinking breaks down completely and it is best to just go for a beer or other beverage of your choice.

Answer 2

Program consist of projects that are somehow related or orchestrated to a common target.

For example, in my company we have a customized SAP solution. We implement this solution to every country and cover that country' processes within this customized solution. Each roll-out project including tasks and developments for that roll-out is called a project. And all countries' roll-in target is managed by a single program.

This approach is parallel with the 3rd definition.

Similarly the first definition is also related with the sample Program I've given. Big projects (covering all company countries) can be divided into smaller projects (each country itself) and managed in smaller chunks, although a program manager can coordinate all projects' efforts under a single program.

Answer 3

My definition is far simpler. A project has a defined start, defined scope, and defined finish. A program has an indefinite time and indefinite quantity. It differs from an operations in that operations are intended to be an ongoing concern in perpetuity while a program is intended to end but not known when or to what degree value and quantity are delivered.

I've seen all kinds of definitions being used in practice and, at the end of the day, I don't think it much matters.

Answer 4

Well, consider you as an IT service provider signed a deal (~size of USD 10 Million) with your esteemed telecommunication client. Assume this deal includes all the operations pertaining to Information Technology (IT) and Information Technology Enabled Services (ITeS).

Now, how will you as a "service provider" identify this deal? Will you consider this deal as a Portfolio? or as a Program? or as a Project?

It depends is the answer. Right? But, it depends on what? It depends on your internal policies defined by your own organization. It could be for various reasons such as easier tracking, easier accounting cycle, etc. Let us look at each of the scenarios separately.

As-a-PROJECT:

You might consider the entire deal as a project and create sub-projects based on activities or by domain - for example, you would name the main project as 'Fictitious Telecommunication Company, Norway'. And create many sub-projects under the main project like 'FTC - Adaptive Maintenance', 'FTC- Corrective Maintenance', 'FTC - Billing', etc. You see, these are sub-projects now. It does offer value to your Customer.

As-a-PROGRAM

Your company would need to manage it as a program rather than projects. Why? That's your way of handling the business. Okay, so you create a Portfolio by named 'Fictitious Telecommunication Company, Norway'. Later, create programs under the portfolio and name it as 'FTC - Adaptive Maintenance', 'FTC- Corrective Maintenance', FTC - Billing', etc. Under these programs you will further create the projects that would possibly say 'FTC - Data Warehousing', 'FTC - Open Systems', etc.

Now you see, they are further decomposed for further tracking and monitoring.

At times, you might mirror your organization setup as per your Client's requirements. This is because your Client would want you to mirror it exactly as-is. You cannot say NO and no businessman would say so.

Kindly understand, whether it is a portfolio, or a program or a project, the plain objective of these segregation is to provide value to your esteemed Customer. Nothing else. All these segregation is all virtual and can be applied in various ways to achieve the results.

Hope this helps you understand the context better. Should you need more information, do not worry, just shoot.

Answer 5

Their is many specialized software/computer programs to help with "large project" management based on the critical path technique. The critical path technique is a graph that show you the most profitable/shortest way to achieve your goals : deadlines and budget. Each step of your project is shown on the graph. When their is a technical side in what you start and manage we talk about a "project". When their is more a social services side we talk about "programs". So, if you develop a phone, you will start a project establishing first its critical path. If some of your employees need a social service for their wellbeing, you will register them into a program.