- 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 do I manage scarce resources?
One of the reasons given earlier for setting up a programme in the first place is to deal with the thorny issue of scarce technical or other resources. If only one person has the requisite knowledge in the organisation, they can become the sole factor for determining the success or otherwise of a programme of work. There is very rarely an organisation that has enough staff to do all the things they want to do in as short a timeframe as they would prefer. There will always be limitations on resources, even if the decision is taken to buy in additional resource to help.
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 may be appropriate to use a resource manager or simply to get agreement between the various parties as to the use and allocation of resources to particular projects. It is critical in this case 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 is that of the contribution towards the benefits of the programme. Those making the biggest contribution should be seen as more important than those with a lesser contribution to make. However, watch for those projects which perhaps contribute very little to the benefits picture, but without which many other projects would not be able to deliver effectively. An example might be an infrastructure project putting in the building to house other systems or workers. The building itself is not contributing to the benefits accrual in any real sense, but without it, the new systems that do deliver the benefits cannot function efficiently. The priority here must be for the building project over any other, despite the apparent lack of benefit contribution.
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. This prioritisation must be done across all projects within a programme and, where necessary, across all programmes in the organisation.
It may also be necessary to compare this prioritisation against the business-as-usual activities that might impinge on the overall successful delivery of the programme. If the resources used for programmes and projects also have a ‘day job’ in business-as-usual, then the prioritisation of their work load needs to be clear. This may well result in some very tough decisions: perhaps to suspend support for a legacy system to allow a new system to be implemented more quickly. The spend profile may well be found to be the driving force – how much the organisation can afford to spend in any one period.
Once this survey of priorities has been achieved, the resources issue becomes much clearer and easier to manage. It is naturally not likely that it is simply a case of saying the resources go to the number one priority first, followed by number two and so on. There are likely to be many more aspects to be considered, but at least there is a starting point for the allocation.