Programme Management

Here is a brief summary of the sections in this topic. If you want to see the full topic, you can get a free trial here.

1. What is a programme?

In this topic, a programme refers to a set of projects and other activities that together achieve one or more strategic purpose(s) for the organisation running it. If you have a number of projects running at the same time within an organisation, problems begin to appear:

  • The available resource, in terms of skilled people or sufficient funds, required to carry out the project work may be limited
  • There may be competing demands from different projects.

A programme is designed to reduce that conflict and to ensure that the organisation continues to do the best it can with the limited resources available to it.

2. How does a programme differ from a project?

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.

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.

  • Individual projects may deliver on time and to standard, but if other essential projects fail or are behind time, the overall result could still be a disaster for the business.
  • The benefits of a project normally accrue after the project has closed, so a project manager will often not be responsible for delivering those benefits.
  • A programme is very much responsible for ensuring the benefits are actually delivered and it will remain in operation until the final project has delivered and the realisation of benefits is well and truly evident.
  • Someone with responsibility for a programme should be much more a leader than a manager, with a clear vision of the future.

3. For which projects do I need a programme?

There is no sensible answer to this because there are no constraints with which to be concerned. Any projects can be run under a programme, but there are perhaps some groupings that are more useful than others.

  • The obvious reason for grouping projects is when they have shared resources, shared impact, shared funding or shared goal types.
  • In smaller organisations, it might be acceptable to use some of the guiding principles of a programme management methodology, but to ask the most senior project manager to undertake the work.
  • If there is a major piece of work to be undertaken, regardless of whether we call it a project or a programme, there will be a certain amount of overhead if effective management practice is to be put in place. With a small project, the overhead will be small, but as complexity, risk, inter-dependencies and scale increase the overhead also rises. There will come a point when the overhead needs to rise to a significant level. It is then that a decision must be taken whether the controls of a project are sufficient or if it is necessary to look at the wider management that a programme brings with it.
  • Several programmes may be within one portfolio of work. This portfolio would be a permanent fixture on the agenda of the board of directors or equivalent and it is as much about giving them the necessary information and control mechanisms to enable them to know how their business is developing, as controlling the work being undertaken.

4. Pros and cons of programmes

Probably the most important advantage is the realisation of benefits. The justification for adding the extra layer of management is the ability to ensure that the correct projects are:

  • Being undertaken
  • Being prioritised correctly
  • Being resourced correctly
  • Are progressing appropriately.

A programme also

  • Saves senior managers from having to go into the detail of projects, because the team will bring concerns to them
  • Creates consistency across the organisation as to how projects are run
  • Provides external companies with a set of standards
  • Provides a safety net for less experienced project managers
  • Reduces risk.

The disadvantages of programmes include

  • The cost
  • They may be seen as making projects more distant from the executives who provide the funding and therefore perhaps less accountable to those executives
  • An extra layer of bureaucracy can be less than helpful with communications
  • A programme may impose inappropriate standards on the projects, causing them additional work
  • Reporting for the sake of reporting, notably to senior staff or programmes, is a commonly-heard complaint.

5. Are there different types of programme?

If by types we mean programmes that are operating in different areas of the business, the answer is naturally yes. There may be construction and information system programmes, HR programmes and so on. However, it is likely that the same or at least very similar programme management methods and processes will operate in all these areas and so, while the target may be different, the mechanisms is likely to be largely very similar in each case. It is commonly accepted that there are three main reasons for programmes to be instigated, leading to different organisational outcomes.

  • In the first case, there is a single aim, outcome or goal for the programme, but it is convenient, for any number of reasons, to divide the work required to achieve that goal into a number of packages or projects.
  • In the second, there are a number of different projects in particular areas of the business, but all are going to deliver a single vision of change for the future.
  • The third case is probably the most likely scenario in smaller organisations in which a number of different projects are running in order to meet a number of different aims for the organisation.

6. How do I justify a programme?

A business case for a programme is not difficult to write, provided some sensible and straightforward rules are followed. There are a number of headings that should appear or at least be considered in any business case.

  • Background – what led to the vision and idea of a programme?
  • Scope – what is to be included in the work of the programme and, perhaps more importantly, what is not to be included?
  • Options – the main options available to solve the problem identified or to achieve the intended vision
  • Make a choice of the preferred option and give some reasons.
  • Major risks – what could go wrong?
  • Timescale – there needs to be some estimate of the timescale for the programme.

7. The vision and the blueprint

The most important first step is for senior managers to decide where they want the organisation to be in, say, five or perhaps ten years’ time. There must be a clear vision of the future into which staff, suppliers and other stakeholders can buy. Without this, the primary means of determining direction is lost.

  • In general, a vision must inspire and encourage the stakeholders to want to change. It must be drafted in terms all those affected can understand (so not in complex or technical terms) and must be simple.
  • A blueprint can be constructed in a number of ways, but the overall purpose is to describe the future in enough detail to enable the work to achieve the vision to be determined and divided into suitable blocks (projects). It is likely that some analysis will be required and you will need to involve the technical experts for each of the major areas.

8. Do I need a programme office?

The simple answer is ‘No’ but the more comprehensive answer says that it is a lot easier to run programmes and projects if there is some form of support available. It is the help they provide that is critical. Essentially, they can perform one or more of three functions:

  • To support decision making – providing accurate and timely information so that key decision-makers are able to decide what to do at whatever level, based on the best and most comprehensive information available
  • To support delivery – simply helping projects and programmes to deliver more effectively and efficiently
  • To support standards and best practice – what is normally known as a Centre of Excellence.

9. How do I start running a programme?

Initially, the clear staring point is deciding where you want to go. Here, it is the vision, discussed earlier, supported by the blueprint, that shows us what we will see when we have achieved the end result of a changed organisation. Having decided where we are going, we then must decide how to get there. The route chosen will depend on a number of things.

  • What is already going on in the organisation that will help us to get to the chosen destination?
  • What is already going on that will not add to the effort of achieving our aim?
  • What else do we need to do to achieve our purpose?
  • What technologies do we want to use or avoid?
  • Defined owners for the benefits are essential and they must have the appropriate authority, agreed at the start of the programme.

10 Who needs to be involved?

The work of the programme can be split into two broad areas – that of programme management and that of change management. The two are closely interlinked, but quite distinct in the areas in which they operate.

  • The Programme Director, sometimes called the Senior Responsible Owner or some similar title, is the person who, at the end of the day, carries the can for the programme. They are likely to be a senior manager, perhaps a director or equivalent, particularly in the case of bigger and strategic programmes. This is critical if the right level of sponsorship is to be achieved.
  • The Programme Manager is almost always going to be full-time. Their role is to manage the programme (not the projects) on a day-to-day basis on behalf of the Director.
  • The Business Change Manager is very often a specialist with a good understanding the psychology of the human mind, who knows how to encourage, facilitate and pursue the change agenda without alienating all those affected.
  • In many programmes, there will be more than one Business Change Manager because there are several areas of the business affected by the changes.
  • The desired skills and aptitudes of a programme manager, essentially seeing the bigger picture rather than a concern for detail, are not necessarily those found in a project manager.

11. The key role of benefits

In the context of programme management, a benefit to an organisation is something which measures the achievement of a strategic goal or a desired outcome from a number of pieces of work (projects) that takes the organisation to a new place. It is the result of a significant change of some sort.

  • Benefits must be measurable.
  • Benefits must defined in a way that everybody understands and agrees is acceptable.
  • Benefits must be owned by someone who is clearly accountable for their achievement.
  • Benefits are not only about finance.
  • Targets and benefits are not the same thing and often can be seen to be acting in opposition or at least not assisting in improving the organisation.
  • Almost all benefits will also have a negative impact on some of the stakeholders in the organisation.

12. How do I manage benefits realisation?

The management of benefits is a task for the manager who has been given the responsibility for controlling the changes being made to the operational side of the organisation – the business change manager or change agent.

The aims and goals of the vision must be translated into measurable benefits.

The links between strategic goals and actual benefits must be mapped.

Benefits must be clearly defined, with no room for misunderstanding, and regularly reassessed to check that they have retained their value to the organisation.

Staff must be prepared and trained to implement the new system.

13. How do I manage scarce resources?

The management of resources, notably those shared across two or more projects, is one of the key reasons for considering the programme management structure.

  • It is critical to ensure there is a clear prioritisation for the projects, allowing the more important or critical projects to get preferential treatment over the less important.
  • To prioritise the work, a number of different values need to be assessed, the first and probably most significant being the contribution towards the benefits of the programme.
  • Other factors to be considered in the prioritisation will include (but not be limited to) risk, financial commitment and spend profile, complexity, timescale, key resource usage and dependencies on other pieces of work.

14. Running programmes

The overriding aim for those involved with the programme governance structure is to assist and be supportive of the work of their projects and other activities. It is very clearly not about sitting on top of the projects, preventing them from working efficiently.

  • It is likely that a time line, with the dates of key deliverables noted, together with their key dependencies and enablers, might be more useful than a giant Gantt chart.
  • Senior people should deal with the strategic issues, leaving the day-to-day running of the projects to those directly involved.
  • Progress measurement can be achieved at a high level by checking against key milestones, such as the delivery of specific products, the achievement of particular benefits or the expenditure of significant sums of money.
  • The quality of the benefits, their definitions, measurements and monitoring are crucial to the overall success of the programme.
  • The programme should be the sole source of information about all the work going on within it to avoid one project giving out information which is contrary to that given out by another project.

15. Ending programmes

An orderly close to a programme, with documentation signed off, records archived and lessons learned for the next time are all essential parts of the process.

  • The programme should be closed when enough of the benefits have been realised to justify the programme’s existence and when the major changes the programme has implemented are regarded as business as usual rather than ‘new’.
  • It will certainly be after the last piece of project work within the programme has finished and delivered its products but could be immediately after this time, a few months after this or after a longer period.