Projects Versus Programs
When the notion of ‘programs’ as opposed to ‘projects’ gained popularity the challenge was to create a helpful distinction between the two.
Those who took on this definitional task unfortunately focused on the differences in terms of the outputs they were to deliver:
- “A Project is a temporary undertaking to create a unique product or service to specification.” [1]
- “A Program is a group of related projects managed in a coordinated way to deliver (business) outcomes and benefits.”
Projects were also defined as ‘tactical’ whereas programs are deemed to be ‘strategic’.
There are a number of further differences outlined such as:
- the time taken,
- breadth of scope,
- level of business involvement, etc.
But is this correct?
Think about it this way...
I, as a business executive, commission a “project” – a straightforward, single themed, focused project – because I want a set of business outcomes and benefits delivered.
I do NOT want the Projects specialists to come back to me and say, “But this was only a project, you don’t get benefits from projects, only from programs". (I’d likely fire them for incompetence.)
I want to receive business outcomes and benefits from each and every investment regardless of whether what I have commissioned is deemed a ‘project’ or a ‘program’.
From a business executive's point of view, it makes no sense to differentiate between projects and programs on the basis of whether or not they deliver benefits — because I (the business) always want benefits.
All projects AND programs deliver outcomes and benefits.
All programs and projects should be focused on, planned and then managed to deliver business outcomes and benefits.
Even within a program, the sub-projects need to be focused on delivering the desired business outcomes and benefits, even if the sub-projects themselves only deliver interim solutions eg an installed technical infrastructure. If the new infrastructure is installed with little thought as to its end business use and value, future business benefits can be frustrated by being inadvertently designed out of the realm of possibility by the sub-project. This is costly and unnecessary.
The outputs and the measures of success (delivery of the desired business outcomes and benefits) need to be the same for both programs and projects.
What is different between a project and a program?
It is the scale, the complexity and the inputs not the outputs.
A project manager usually has little need to focus on the ‘project culture’, the career paths and training of the team or manage within a changing business environment. The project timeframe is too short.
However, a program manager does need to create a program culture, define career paths for their team, and track and respond to the changing business environment. But these are all inputs to the delivery process, not outputs.
Program managers have a different input challenge. They are creating a (temporary) new world in which to develop and deliver ‘a group of related projects’ with their associated business outcomes and benefits. They have, therefore, a whole range of tasks required that project managers do not need to contend with (unless they are managing a very large, long term project). Program managers are creating a transitory corporate entity with a mission to deliver the program’s outcomes and benefits over time.
It's a fallacy to say that only programs deal with organizational change or deliver strategic objectives and benefits. Many projects will also deal with these issues.
These output dimensions are not the true bases of differentiation.
If they were, then for the business to receive any business outcomes and benefits, it would always have to commission ‘programs of work’ when often only a straightforward ‘project’ is needed.
For example, a project to replace a telephone system should be specified and managed to deliver one o more desired business outcomes which describe:
"the future business enviroment when it is working "well enough/ well/ just right". [2]
These agreed, specific, clear, measurable business outcomes and benefits would likely includecustomer service, responsiveness, 24-hour availability – not just ‘a new telephone system’.
This output-based differentiation also does not make sense in that projects generate business cases to be approved. These business cases include benefits that, presumably, someone expects to be delivered.
Therefore, benefits delivery needs to be part of the outputs of project delivery not just program delivery.
Strategic Programs v Delivery Programs
However, there is a wrinkle in this discussion. Some years ago we got into a discussion in a government department about the word ‘program’. We were using the word as above, meaning a group of related projects. Those in the government department were using ‘program’ to mean "a strategic initiative to be delivered over time through various activities – through business as usual, projects and/or programs".
This latter definition explains why some definitions of ‘programs’ include the statement that programs sometimes have no end point (unlike projects that have a defined end point). These ‘strategic initiative programs’ – eg “The early childhood literacy program” – may not have an end point but are not the same type of ‘program’ as a group of related projects – eg “The education department restructure program.” The former is a strategic initiative and the latter is a structured delivery program.
The Importance of the Choice Between the Inputs V Outputs
The importance of this choice between input and output definitions of project/program differences is in the business results expected and delivered.
If projects are neither expected nor required to deliver business outcomes, change, benefits or value, then they will not be managed to deliver these results. They will instead be managed to deliver some ‘outputs’ that may or may not enable the delivery of business value.
Yet, as many of you will know, how you design and install ‘outputs’ will determine the business benefits and results you can realize.
By isolating ‘projects’ from business change, strategy, outcomes and benefits we are defrauding the business of the potential value available from projects, and we are training our project managers to not see themselves as accountable for the delivery of business benefits and value. No one can afford to make this mistake.
So, TOP proposes an alternative definition for projects and program.
- “A Project is a temporary structure created to deliver a set of agreed desired business outcomes, benefits and value.”
- “A Program is a transitory corporate structure set up and managed in a coordinated way to deliver a series of sets of business outcomes, benefits and value and which will likely incorporate multiple projects.
