- Programme Management
- In a nutshell
- Common questions
- What is a programme?
- How does a programme differ from a project?
- For which projects do I need a programme?
- Pros and cons of programmes
- Are there different types of programme?
- How do I justify a programme?
- The vision and the blueprint
- Do I need a programme office?
- How do I start running a programme?
- Who needs to be involved?
- The key role of benefits
- How do I manage benefits realisation?
- How do I manage scarce resources?
- Running programmes
- Ending programmes
- Want to know more?
How does a programme differ from a project?
This is a question that has been asked a lot in recent years and it is probably one of the most debated questions in the world of project and programme management. In order to answer the question, we need to consider what constitutes a project and what makes a programme.
A project is a single temporary organisational structure, established to deliver one or more deliverables (outputs or products, as you see fit) within a given period, at an agreed cost and to an acceptable degree of quality. It is mainly concerned with identifying what it is intended to deliver and the risk to that delivery, and then achieving the work necessary to produce it, as agreed.
A programme, on the other hand, is a collection of projects and other activities that deliver strategic benefits for the organisation. It is really about delivering towards the strategic goals of the organisation, however they may be designed.
Supposing, for example, that a shop-based retail organisation wants to expand into e-sales. This might entail several different projects: the back-room-process changes to enable e-orders to be received, acknowledged and fulfilled; the necessary hardware and software systems; the changed and increased marketing of the new service, notably on the internet; the change to delivery mechanisms to allow customers to order from around the country or perhaps even from aboard; a training project for all the staff who will have to manage and maintain the system.
There might even be a project to look at the support for customers who order online, allowing them to order spares and accessories as well, perhaps delivered direct from the factory or wholesaler. Individually, each of these pieces of work could rightly be considered as a project – a clear deliverable, with specified time and quality requirements and with a temporary governance structure to manage the work. (When each product is delivered, there may well be an ongoing maintenance requirement, but this is usually dealt with by bringing the solution into the business-as-usual arena.)
If each project is undertaken in relative isolation, there is a potential disaster awaiting the organisation. For example, the processes may all be delivered, the marketing in place and raising expectations and demand, but the computer side of life could be severely behind schedule. The end result could well be a PR disaster, with the reputation of the physical shop as well as the virtual one coming into question. With a programme established, this is much less likely to happen. Further, the overarching business case for the programme will consider the big question – ‘Why are we bothering to do this work?’ There should be a very clear business case for the programme, say, to increase the sales of the company by 15 per cent in the next twelve months or to boost net profits by 20 per cent in the same period.
Each project will also need to be justified, but only in the light of its contribution to this overriding requirement. If we have no programme, each project would need (in good practice) to have its own business case, but imagine trying to write one for the infrastructure alone. The bigger problem, though, is that while the computer project might well deliver on time and to cost (so the project manager and their team would get their justly deserved bonus), if the other projects don’t also deliver as expected, then the computer system will be useless and a waste of a lot of money and effort. This, again, is where the programme comes in, ensuring the projects all deliver as expected and within acceptable time tolerances, so that the whole system delivers the organisational benefits of increased sales and profitability.
Is programme management just big project management?
In some limited ways it is just project management on a larger scale, but the more important areas are those not normally included as part of project management – notably, benefits management. A project manager will often not be responsible for delivering the benefits that the project is supposed to enable. It is often said that projects facilitate the delivery of benefits that will normally accrue after the project has closed. There is a good reason for this. The cost overhead of a project detracts from the overall benefits of the change, so closing it more or less as soon as the deliverables have been handed over reduces this overhead as much as possible.
A programme, on the other hand, is very much about ensuring the benefits are actually delivered. It will remain in operation until the final project has delivered and the realisation of benefits is well and truly evident – not just expected. While you might suggest that this is still an overhead that needs to be deducted from the value of the benefits, if the programme has a number of projects, maintaining a single programme will be rather less costly than keeping all the projects going until each sees the relevant benefits accrue.
Areas where similarities between the management of projects and programmes exist include the management of risk, communications, controls of the work being done and planning. Even here, though, while the principles and purposes might be the same, the method of achieving them and/or the scale of the work involved may well differ significantly.
Skills and competencies
There are other areas where a programme differs from a project. The skills and competencies required by those running programmes are not the type usually held by project managers. Much has been written about this, including those topics in this resource which discuss the differences between leadership and management. See Leadership versus Management.
The manager asks how and when; the leader asks what and why.
Someone with responsibility for a programme should be much more a leader than a manager. It is a clear vision of the future that is the main requirement for the managers of programmes. They should be much less concerned with the route to the end goal than the end goal itself. Dealing with variations, alternatives, deviations and uncertainty are all part of the daily work of the programme manager.
Project managers prefer to deal with certainties, with well defined products and a clear development path. It is an unusual (and probably rare) person who can combine all these skills and competencies in a single persona. Programmes should provide the ‘buffer zone’ between the uncertainties of the business environment and the certainty required for projects to be successful.
Do I need both projects and programmes?
The straight answer is no, but there will always be some further questions to ask before deciding categorically.
To start with it would be a very strange programme that had no projects. Therefore programmes without projects would be extremely unusual, not to say impractical and pointless. Projects without programmes, though, are far more likely and, in many cases, entirely acceptable. If your organisation is running a small number of projects to achieve changes in the way the organisation runs, and if these projects are essentially independent of one another, then there may well be no good reason to bother with the additional overhead of a programme.
For example, a project to build a new head office on a local business park five miles away, a project to change the way the staff are evaluated to include a 360 degree approach and a project to update all the delivery vehicles in the fleet owned and operated by the company would seem like three very different, although perhaps complex and expensive, projects. Are there any areas of conflict, cross-over or dependency between the projects? If the answer is no, then leave them as three separate projects.
However, if, on closer inspection, we find that the new head office facility will provide new vehicle servicing facilities plus enlarged offices that will now allow teams that work together to sit together, suddenly we find there are inter-project dependencies. In this case, we might consider a programme to be a useful and important investment.
The benefits from a programme should be greater than the sum of the benefits from the individual parts.
The bottom line is always going to be that of adding value to the overall management process. The cost of a programme is not insignificant. Even the cost of a single programme manager with a couple of people helping is likely to run into thousands of pounds, even without including the costs for the facilities they might need, their training and ongoing professional development and the necessary ‘tools of the trade’. If you start to get really serious about projects and programmes and decide you need project and programme offices to support the work in each, then you are heading into considerable financial and personnel commitments. This is only worthwhile if the benefits of running projects within a programme are clearly visible. This will include the benefits of the combined projects being greater than the benefits to accrue from each project individually.