Sharing projects – interdependencies
‘Adventure is the result of poor planning.’
COL. BLASHFORD SNELL
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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
3.17.164.34