We frequently receive emails enquiring into the difference between projects and programs (or programmes 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.
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.
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”.
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”.
Clear? 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 and programs:
|Program success is measured in terms of business benefit, ROI, or new capabilities. Benefits (outcomes) are managed using a benefits realisation 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 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 organisation.||The scope of projects is tight – they are limited to producing deliverables.|
|Programs will typically span multiple functional units within an organisation.||Projects are typically confined to a single functional unit (vertical unit) within an organisation.|
|Programs are typically executed over a much longer timescale than projects, often several years.||Projects are typically 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:
|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 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.||Focus is on 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.|
The diagram below shows a simplified view of how projects and programs fit within the hierarchy of a business.
Think of diagram as 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 run the business. People at this level are concerned with, amongst other things, setting strategic direction to realise 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 realise benefits. Project’s could also be cancelled by the program if it was felt they wouldn’t be the best way to realise 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 organisations 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.
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 more broad in scope. It’s targeted with delivering a mobile phone that maximises 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:
|Go To Market (GTM)||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 the 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 organisation 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 market demand. This will obviously change over time and requires careful coordination so there isn’t over or under supply, both of which would result in a reduced return on investment.
This article provides several ways to think about the difference between projects and programs, but in very simple terms you can think of programs being concerned with doing the right things, and projects concerned with doing things right.
If you enjoyed this article then don’t forget to sign up to the EPM newsletter for regular advice, tips and information that will help develop your project or programme management skills.
The Ultimate Guide to Project Management
Benefits Management, Part 1: Introduction
Required Skills to be a Program Manager
What Does a Program Manager Do?
Program Management Primer
The Change Equation
What is the Long Tail?
Program Management: Understanding Effort and Influence