- 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?
Are there different types of programme?
The answer to this depends a little on what is meant by ‘types’. 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, marketing and 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 mechanism is likely to be largely very similar in each case.
It is also likely that programmes will be created for different reasons:
- Some come about because someone realises there must be a better way of managing a number of major projects, a way that reduces the overheads and enhances cooperative effort
- Others come about because regulations change and a number of different areas of the business – perhaps IT, HR, sales and finance – are all affected by the changes
- There are perhaps even programmes that are created because the person running a major project feels that it would sound better and would gain greater significance if it was called a programme.
Once again, all these are likely to use basically similar techniques to deliver the outcome for the business organisation.
It is commonly accepted that there are three main reasons for programmes to be instigated, leading to different organisational outcomes. These can best be illustrated by a simple diagram.
In the first example, 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. It could be that the work is being undertaken over a number of years, in a number of different geographical locations and in different business areas within the parent organisation (as illustrated above), or for some similar reason. In this case, the argument for a programme is to help to manage the dependencies and the delivery of benefits as a result of the work being completed. It is likely that one project must deliver in order to facilitate the work of the next. Further, the benefits from Project 1 are not likely to be realised until the final project has delivered and all the new systems are part of the normal operations of the organisation.
In the second example, 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 projects themselves may not be directly related to one other in terms of the work they are doing, but there will be some perhaps limited dependencies, such as that one can’t complete until another has delivered. The main reason for considering a programme structure in this case might be shared resources, or limited finance, or simply to keep overall control of the work being done, perhaps over a number of years.
In the third example, it is simply due to expediency that a programme structure might be considered. This 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. It may be that one is for regulatory reasons (to meet a change in legislation, for example), while another might be intended to exploit specific new technologies or to expand into new business areas. There is no single goal for the programme of work or any real dependencies, but the organisation can only manage so many projects at a time and needs to keep a check on the number of change initiatives going on at the same time. People (and hence organisations) can get ‘change drunk’ – never allowed to let one change embed before the next one starts; using a programme to manage the overall pace of change can prove very effective.
This third example is also often set-up to ‘collect’ a number of projects already in existence. If one senior manager is responsible for a number of projects, and then more are suggested or even started, it might be sensible for that manager to set up a programme to manage the work in a more cohesive and effective manner.