MSP

In MSP methodology this is covered by (chapters given in brackets):

• Planning and Control (9)
• OGC MSP website

Planning forms one of the cornerstones of the Project Management infoKit and at the start of any major programme it may be worth reviewing that core material. Our Programme Management infoKit references the Managing Successful Programmes (MSP) methodology. The Programme Manager needs to do that little bit more.

As ever however the Programme Manager needs to do that little bit more. Not only are you scheduling a more complex set of resources you also need to be scheduling capacity. You should be looking across the range of projects identifying skills that are being gained and problems that have been solved in order to share that enhanced capacity across the whole programme. This may involve moving staff between projects to make best use of newly acquired or scarce skills or simply ensuring that communication and sharing of experience is happening on an ongoing basis.

One of the things that probably worries you most as a new Programme Manager is the extent to which you can rely on estimates you are given by your projects. It is a truth we cannot repeat too often that people on the whole tend to be wildly optimistic about project planning and base plans on best case scenarios. We cover this in the 'Planning in the Real World' section of the Risk Management infoKit.

One way of getting people to think in a little more depth about their 'best guesses' is to encourage them to try using three-point estimates for a while. For each uncertain task estimate:

• The most optimistic timescale = MO

• The most likely timescale = ML and

• The most pessimistic timescale = MP

Project management software often uses this approach and can calculate the standard deviation of each of the estimates to show the relative uncertainty in the overall plan. This allows you to come up with statistical confidence limits e.g. you can be 50% certain that the project can finish within 100 days and 85% confident that the project can finish within 130 days etc.

This is not something you are likely to do manually but the concept of three-point estimates can be helpful in identifying bias in project team estimates. If you ask a range of people how long various tasks will take they may all give different answers. If you then go back and ask for three-point estimates you may be able to tell who consistently goes for the most optimistic figure and who always 'pads' their estimates.

Our illustration in the highlight box shows how inaccurate estimates in one area can have knock-on effects down the line - this of course occurs big time when running a programme. What you do of course have to remember is that whilst small predictions can be highly inaccurate some of this fluctuation will even out over a longer period. An estimate of 2 hours to do a single job could be wildly wrong but similarly solving one big problem may give you a shortcut route through the rest of the project. The important thing is to focus on the critical path and project milestones. Consistently bad estimating is a problem but minor fluctuations don't matter so long as you hit the milestones - trying to get it right all the time will simply drive you nuts!

Why are estimates always wrong?

Say we have tasks A, B and C that are all predecessors to task D. The chances of A, B or C meeting their most likely time estimate is 50% (1 in 2) in each case.

However when we look at the chances of all 3 of them all being on time to feed into D the figure goes down to 12.5% (1 in 8).

Does One Size Fit All?

It would seem logical when running one or more programmes or projects to adopt a standard project management methodology across the organisation. This has many benefits not least:

• Consistent reporting to enable comparison and resource scheduling across projects

• People can move between projects without having to learn a new approach

• Project archives will be a valuable resource for future project teams

For a programme of similar types of project a highly standardised approach will undoubtedly be beneficial. However in our environment we may have a very diverse programme of projects contributing to a single strategic aim. In this case success is more likely if the management procedures are tailored to the size and nature of the project. On the question of how much project management you need the answer is always 'just enough'. Don't ask for anything unless you are sure you will use it.

The infoKit on Portfolio Management has a section on Balancing your Portfolio which looks at e-learning activities on a spectrum from projects to automate current activities, thus saving resource, to innovations that may ultimately transform the organisation.

Anyone involved in Programme Management would also do well to consider not only the size of individual projects but also the type of project and the people and cultures involved. You may find within a single programme there is a wide spectrum and you would do better to work with the prevailing culture than against it. By all means have a single organisational methodology but make sure it is a flexible one that can be scaled up or down depending on individual project needs.