A Few Related Projects: Simple Programmes
Sharing projects – interdependencies
‘Adventure is the result of poor planning.’
COL. BLASHFORD SNELL
Simple programmes
We have seen that the staged project framework can be applied to any type of project for any purpose. It is a tool that you can adopt and adapt to suit your needs. Nevertheless, a simple string of activities, passing through five defined stages, may not give you the full flexibility you require. We saw in Figure 12.7 how we can manage the subparts of a project using the work break-down structure. This is how the project manager delegates work to the managers within the core team.
Programmes
Some projects, however, are simply too large to manage as a single entity. It is often more convenient and effective to define the work in a series of closely related and linked projects, each of which is managed by a project manager, reporting to a programme manager (Figure 13.1). The role of the programme manager in this respect is similar to that of a project manager (as described in Chapter 4) except that detailed management of parts of the project is delegated, as is the associated administration. He/she will have a core team of project managers, rather than team managers.
Figure 13.1 A simple programme
A programme where each constituent project is used to manage a substantial work scope.
Phased programmes
Other projects are so extended in time it is beneficial to phase the development and delivery of the solutions. This ensures that the organisation starts benefiting as early as possible and also increases the likelihood of success (Figure 13.2). It also gives the organisation a ‘get-out’ if the need the programme was set up to fill either evaporates or if the chosen solution is not meeting it. The start-point for each new phase (or tranche) acts as just such a review point.
Figure 13.2 A phased programme
A programme comprising a number (in this case three) of phased deliverables, each managed as a project, with its own life cycle.
The permutations beyond this are endless. For example, you may have a phased programme where each phase is itself a programme such as that described in Figure 13.1. There are no rules, you just have to make it very clear what you are doing. The staged framework is very useful in this respect as it can give an overview of the programme in terms of known stages such that any person in the organisation can understand it. You should treat any programme which is not described in this way as very suspicious.
Programme organisations
Organisation structures for simple programmes are many and varied. In principle, however, they are very similar to those described in Chapter 4. The key difference is that instead of the structure comprising a project manager supported by team managers and members, it comprises a programme manager supported by project managers, all of whom have their own teams. This is shown in Figure 13.3. The accountabilities of a programme manager in other respects are the same as that for a project manager. However, the scale of most programmes is such that the experience and skill set required to carry out the accountabilities are quite different. Note, in this structure, the programme manager would take on the ‘project sponsor’ role for each project within the programme. It is, however, perfectly acceptable for the sponsorship role to be undertaken directly by the programme sponsor or another person appointed by him/her.
Figure 13.3 A typical simple programme structure
A programme structure comprises a programme manager supported by project managers. In addition, there is often a programme support group to undertake the essential coordination and administration, and to implement common standards. The project sponsor role for each project may be undertaken by the programme manager or assigned by the programme sponsor to others.
Sharing projects – interdependencies
A project comprises all the work required to ensure you put the changes in place to enable the benefits to be realised. On occasions, however, the deliverable you require may be produced by another project, often within the same programme, but not necessarily so. In this case your project is said to be dependent on the other project. Such interdependencies are noted in the business case in the ‘scope, impacts and interdependencies’ section (see also pp. 299, 353). Sharing of work between projects:
- adds to the efficient use of resources on your projects;
- ensures consistency between developments;
- reduces costs of projects for your business.
In all, it sounds like a ‘good thing’. With most companies relying heavily on information systems to enable them to run the business, software development, whether in-house or out-sourced, is frequently required as part of business change and is ‘shared’ between projects. From the point of view of the systems developer, it is preferable to batch requirements from new projects and deliver them as a new software release. It makes life easier for the development team, for configuration management, for implementation and for training. In many cases, this is in fact sound practice but it does need to be considered more widely than that. If you take this approach, a number of projects, serving different needs and under different programmes, may be bundled together. If this one software delivery is delayed by just a single problematic part of the development, relating to one project only, the whole bundle slips. In other words, the full set of interdependent projects is tied to the one with the greatest risk. In fact, the slippage may be caused by the features required by the lowest priority project in the bundle. It is hardly surprising that software delivery is invariably ‘blamed’ for making projects late. (While I have made an example of software, the same principle applies to any deliverable which is shared between projects.)
From a risk-management viewpoint it is often preferable to separate out the discrete high-priority developments and carry them out in separate releases. Don’t build in risk from the start by bundling things that need not be bundled. The loss of efficiency may be paid for many times over by the benefits flowing from having projects deliver on time.
PROGRAMMES
As discussed in Chapter 3, words such as ‘programme’ can be used in many different ways. Although some standards organisations and methodology writers are trying to create global definitions, in my experience, it will take a long time for these to become fully accepted, if at all. Three different uses of the term ‘programme’ are given below, which show the range of possible interpretations:
- Portfolio: a set of related projects aimed at meeting the business plan needs (or part of). These are dealt with in Part Three of this book as ‘business programmes’.
- Goal directed: a set of closely related projects aimed at creating a new capability (as described in this chapter). This is typically outside the usual routine of the organisation. They are a way of effecting one-off, major change. in this book, I simply call them ‘programmes’ or ‘big projects’.
- Heartbeat: a set of activities managed around service delivery, e.g. regular releases for a large IT system. This is a very ‘functional’ view and not really much to do with business-led project management, although its work content may represent work packages.
These are shown below:
| Portfolio | Goal directed | Heartbeat | |
| Programme’s control of projects | Coordinate to extract synergy benefits | Definition and direction of all projects within the programme | Integration of identified changes into a cohes programme |
| Planning organisation | Programme overlays project roles: project and project manager retain strong relationship | Programme acts as sponsor client for all projects | Programme arbitrates between multiple client needs |
| Planning horizon | Indeterminate: as long as it adds value | Until the goal is achieved | Until the ‘system’ is withdrawn |
| Programme relationship the line | Draws on line resources and complements line management with business leadership | Draws resources from line management | Takes on traditional line management role of functions (e.g. operational performance) |
Source: Pellegrinelli, S. (1997) ‘Programme management: organising project-based change’, International Journal of Project Management, vol. 15, no. 3 (June 1997), pp. 141–149.
13.1 QUESTIONING YOUR PROGRAMMES
- Choose any programme in your organisation and identify the component projects.
- Split each project into the five project stages, one stage per Post-It Note, using a different colour for each project.
- Prepare a large sheet of paper or a white board, indicating a timescale on the horizontal axis sufficient to include the entire programme timescale. Draw a vertical ‘time now’ line.
- Place each project onto the board, with each stage aligned to the appropriate date. Can you actually do this? If not, question how you really know what is going on and how you can direct the programme with any degree of confidence or knowledge.
- Identify any interdependencies and mark them with a down arrow from the delivering project to the receiving project. Check for multiple two-way dependencies – this could indicate poor project definition. Remember, interdependencies are potential weak points which can be forgotten or where accountability is abdicated. Good programme definition minimises dependencies!
- Look for any very long stages – can you shorten these? Be very wary of any prolonged investigative stages.
- Look for when benefits start to flow – can you redesign the programme to achieve any benefits earlier than this?
- Look at where your key review and decision points are (they should map onto your gates) – have you sufficient of these to ensure control? Be very wary if it has all been authorised in one lump.