We frequently receive emails enquiring into the difference between projects and programs (or programs as they’re referred to in the UK). Many of those who email us are under the impression that a program is simply a really big project, and that there are many similarities between projects and programs.
Nothing could be further from the truth! But in order to understand the difference we need to begin by understanding the definition of projects and programs.
Defining a Project
According to PRINCE2, a Project is defined as “A temporary organization that is created for the purpose of delivering one or more business products according to a specified Business Case”.
Defining of a Program
As posted in our very first article, a Program is defined as “A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually”.
Well, if you’re like most people, then probably not, so let’s break it down. The table below highlights the key differences between projects vs programs:
Programs | Projects |
---|---|
Program success is measured in terms of business benefit, ROI, or new capabilities. Benefits (outcomes) are managed using a benefits realization plan. | Project success is measured in terms of producing specific deliverables in terms of time, quality, and cost. |
Because they are concerned with benefits and not deliverables, programs are more strategic than programs – they are concerned with “doing the right things”. | Because they are more concerned with deliverables than benefits they are concerned with tactics – “doing things right”. |
Programs have a wide scope, focussing on benefits, and may have to change scope dramatically during their execution to meet the changing needs of the organization. | The scope of projects is tight – they are limited to producing deliverables. |
Programs will typically span multiple functional units within an organization. | Projects are typically confined to a single functional unit (vertical unit) within an organization. |
Programs are typically executed over a much longer timescale than projects, often several years. | Projects are typical of a shorter duration than programs, often just a few weeks, and by definition have a finite duration. |
Another way to understand the difference between projects and programs is to look at how the roles of a Project Manager and Program Manager differ. Again, this is broken down by project vs program:
Program Manager | Project Manager |
---|---|
Program Managers create high-level plans used to provide guidance to projects. Detailed plans are created from this guidance by the Project Managers. | Project Managers perform detailed planning to manage the delivery of the products of the Project. |
Program success is measured in terms of business benefit, ROI, or new capabilities. | Project success is measured in terms of budget, time, and scope delivered. |
Focus is on leadership, as Program Managers manage managers. Program Managers need to facilitate and manage political aspects, relationships, and conflict resolution. | The focus is on the management of the people (specialists and technicians) involved to deliver the product. |
Program Managers manage managers. | Project Managers manage technical people. |
Program managers monitor and control projects. | Project Managers monitor and control tasks. |
Programs and Projects and Portfolio
The diagram below shows a simplified view of how projects and programs fit within the hierarchy of a business.
Think of a diagram showing the people running the business at the top of the triangle – the CEO and board. At the bottom of the triangle, we have the individual specialists who are working as part of a project.
At the top of the diagram, we have the Business Level where the board runs the business. People at this level are concerned with, amongst other things, setting strategic direction to realize the vision, and managing a portfolio of programs to move towards the vision.
The next level in the diagram is the Program Level. Here a program can initiate and control multiple projects to realize benefits. Projects could also be canceled by the program if it was felt they wouldn’t be the best way to realize the needed benefits due to a change in the business environment.
Finally, we reach the Project Level. Here projects are initiated by the Program Level (or in smaller organizations without a program level, directly by the business level). Projects have a defined scope (set of deliverables) and must work efficiently to deliver these to time, budget, and quality constraints.
This diagram also highlights the difference between the project and program and portfolio levels of management. The Business Level is responsible for managing a change portfolio, essentially a number of programs. Within the portfolio, each program is responsible for managing a number of projects.
Difference between Projects and Programs: An Example
To make the difference between projects and programs more concrete let’s look at a practical example of the difference between projects and programs. In this case, we’re going to be building a mobile phone.
In our example, a software project exists concerned with the operating system of the device – making sure it’s updated so that it works with the new hardware, as well as making updates to some key applications. The project will aim to deliver the operating system and applications on time, on budget, and to the required quality level.
The program that sits above this project will be much broader in scope. It’s targeted with delivering a mobile phone that maximizes profit for the business. As such our software projects will be just one of the projects controlled by the program.
Other projects could include: Go To Market, Hardware, Tooling, Legal, Business Affairs, Support.
Let’s quickly describe that each of these projects might be responsible for:
Project | Task |
---|---|
Go To Market (GTM) | The project concerned with marketing creation, working with marketing partners, and selling the devices into the countries with the biggest return on investment. |
Hardware | Responsible for creating new hardware for the phone. |
Tooling | Responsible for setting up the factory that will produce the devices, along with ensuring the supply of raw materials to make the phone is secured. |
Legal | Responsible for ensuring that all laws have been complied with or that a plan exists where this hasn’t been possible. |
Business Affairs | Responsible for all 3rd party deals needed for a successful launch, for example, commercial deals with network operators. |
Support | Responsible for ensuring the device contains the right support materials, and that the organization is geared up to handle any new support phone calls caused when the device is launched. |
Software | As discussed above. |
In fact, some of these projects may be so large and complex that they themselves may be programs. A good candidate for this in our example is the Go-To-Market, but for the purposes of this example, we’re going to assume it’s a project.
One of the key jobs of the program is to manage dependencies between projects, for example, the program must coordinate between the Tooling project and the Go To Market project to ensure alignment around the number of devices that the factory must produce to meet the market demand. This will obviously change over time and requires careful coordination so there isn’t over or undersupply, both of which would result in a reduced return on investment.
The major difference between projects and programs is usually that projects are concerned with producing deliverables, whereas programs are concerned with delivering business outcomes.