Summary
The project management software industry is drifting into the use of the inappropriate consolidation model, for the scheduling of a programme of projects. This model derives normally from the tools that are available, not from the requirement. This model has some significant problems which are outlined below along with an alternative model.
Introduction
Project management software tools were originally conceived for use on large single projects. Over the last few years it has become apparent that the vast majority of users of project management tools are actually involved in a number of small, inter-related projects. This is known to some as programme management although I shall use the term programme planning.
The software industry, restrained by an ‘anchor in the ground’, has been forced to provide additional products and functions aimed at bending the single project tool to make it more appropriate to the multi-project environment. One such tool is the multi-project consolidation tool but this brings with it considerable problems.
The programme planning process by consolidation.
There are seven stages in the planning of a portfolio of projects using the consolidation model.
Planning: The process of planning each project in terms of time and resource requirements. This is similar to the planning of a single project.
Transmission: The transmission of the individual project plans to a central point.
Consolidation: The process of combining the many individual project plans into a programme plan.
Evaluation: Exposure of inter-project conflicts and identification of problems especially multi-project resource over-demands.
Experimentation & Decision Making: The process of experimenting with alternative strategies to find optimal schedules for the future work load.
Dissemination: The dissemination of decisions taken back to the individual project teams and the modification of individual project plans.
Achievement Measurement: Feedback via timesheet systems either to measure effort or to monitor progress or both.
Problems with the Consolidation Model
There are real problems that have been observed within a number of companies attempting to implement the consolidation model. These include:
Complexity: The process of multi-project planning by this method is complex as it reflects a complex process.
Timing: The synchronisation of the different update cycles (project, multi-project and timesheet) causes very significant problems due to a lack of synchronisation. The single project plans are in the normal cycle of updating, issue and progress monitor. The consolidated plan is in a cycle involving the integration of the many plans, the analysis of alternative strategies and the issue of requests to change individual plans in light of those strategies. Thirdly there is the cycle of issuing work instructions to team members, performing work and the feedback of actual achievement. A number of organisations have found it hard to make these cycles operate successfully.
Consistency: Data from the many single plans must be consistent if consolidation is to be successfully performed. This includes the naming and numbering of tasks and projects so that an individual work package can be uniquely identified and to avoid duplication of a task identity in more than one plan. Resources identities need to be consistent to allow multi-project resource predictions. One resource, known to the many project managers as F.Smith, Fred Smith, Mr.F.Smith and Frederick Smith would be treated as distinct resource by most systems so that no overload would appear. Some vendors allow a look-up table to reduce this problem.
Organisation Fit: The consolidation model does not relate in anyway to the organisational structure and does not reinforce or record the distribution of work amongst the members of the organisation. It requires a programme support group to undertake this consolidation process but that group still needs senior management decision making to resolve cross project conflicts in light of corporate objectives.
Interaction with Resources: On the large single project, typically, the achievement of classes of resources (bricklayers and welders) can be measured by simply counting the bricks. In the typical multi-project environment the achievement of individual team members (Jo, Fred and Sally) on non-physical work can only be measured by the resources themselves.
In the programme management environment each resource needs to understand what work they are expected to perform and also need to report back actual achievement. In the last few years timesheet systems have become very popular and this reflects the changing face of project management. Some systems allow a short term plan to be produced on paper for each team member and achievement monitoring can be addressed through a third party timesheet software tool.
Non-project work: On large single projects most resources work full time on the project. In the world of programme planning most team members have a background non-project work load and this need to be handled in some useful way. A common method is to reduce the time that the resource is available to work treating non-project work in the same way as holidays.
Part Time and Intermittent Assignments: Many software package make it very inconvenient or impossible to show that an individual intends to either a: work on many tasks at the same time or b: break off from one task to work on another before returning to the first.
Strategies for implementing the existing process
There are three different strategies for using commercially available software tools within the process outlined above. These approaches have been observed in a variety of organisations running programmes of work within the UK. They are all attempts to make this process work efficiently.
Stand-alone
Planners work with their own copy of a popular PC based project planning systems (e.g., Superproject, Microsoft Project, PMW) to plan their individual projects. Such systems are cheap and easy to use and admirably suit the planning of single projects.
These plans are transmitted regularly (weekly or fortnightly) over a Local Area Network (LAN) to a project office where they are consolidated into a programme plan using the same software. The project office may need special expertise in the use of the software and a powerful, fast PC to manage the large amounts of data.
The project office staff can inspect histograms, summary barcharts and barcharts of like work, e.g., all the design office work.
Whilst achievement measurement is normally carried out by a manual time recording system there has been an increase in the use of time recording software tools. These are normally used to update single project plans prior to consolidation.
This approach has the advantage of allowing each project team to plan their own work so that they feel ownership of their plans. These popular tools are easy to use. The project or programme office often takes a supporting role advising the management team of conflicts which are generally in terms of resource over-demands.
A high degree of consistency amongst the many project plans is essential if the many plans are to be consolidated within a reasonable time frame. There are difficulties in measuring achievement where a resource has been involved in more than one project.
The individual planners must alter their plans to bring them in line with the programme’s requirements. This inevitably leads to errors.
Integrated
In this environment the organisation normally purchases a site licence of a heavyweight programme planning system. Planners have access to the tool through a local terminal which might be a PC or a terminal on a UNIX or VMS system.
Each project is planned locally and the system makes transmission and consolidation completely automatic. Once again a small team in a project office examine the cross project demands and report problems.
Decision taken in light of the cross project work load can be entered into the system within the project office as well as being communicated verbally and on paper. These systems are expensive and more complex to use. The tendency is for a small number of enthusiasts to enter data on behalf of themselves and other, less computer literate, users.
Capable planners can add in a new project to the organisation-wide programme. This can be done by accessing a library of typical projects or by creating one from scratch. Plans are simple but loaded with resources. Consolidation is immediate and automatic via the network and multi-user software. Each terminal can display a project, summaries of groups of projects and demand for each resource.
Achievement measurement is normally dealt with by a manual system with administrative staff employed to enter details to the system.
Such systems involve a ‘big bang’ approach and implementation is a significant project in itself. Access to such a system must be controlled so that authority to alter the parts of the model rests with appropriate people.
Combination
In an attempt to get the best of both worlds some organisation have created a combination system. Each project team uses a simple stand-alone PC planning system and the project office use a much more powerful system to integrate the many individual project plans. The individual plans are created and kept up to date using the popular single-project based tools and the files are transferred to a consolidation system. It is likely that the consolidation tool would be manipulated by a project office or programme management team. Consolidation can be achieved by a tool specifically designed for the purpose or by the use of a heavyweight, database driven, project planning tool. The project office team manipulate the data within the consolidation system and can report on conflicts across the many projects.
The Delegation Model - The New Approach
Most organisations run their project work load by delegation where senior staff identify projects and delegate them to project managers. These project managers take responsibility for the projects and plan their own work load in appropriate detail. The project managers normally require the efforts of resources within the organisation and these may be obtained through the subcontract matrix, the secondment matrix or the resource pool approach. The senior managers expect to be informed of progress on each project by the appropriate project manager and in appropriate detail.
We therefore have used the delegation model in our programme planning software: Hydra. Hydra is installed over a LAN and each user is given a ‘work plan’ within which all of their work is planned and monitored. Connections between work plans are created by the act of ‘delegating’ work or by the ‘loaning’ of resources. Upwards reporting follows the connections created by the delegation process. This permits each user to plan all their work at a level that is appropriate to their needs.
For example in one user site, a Director acting as programme manager plans using a single task per project specifying timescale and budget. He then delegates, through the software tool, each project to a chosen project manager. The project managers then break the single tasks down into greater detail within their own work plans generally delegating work to the departmental managers.
Some work is delegated to resource or departmental managers who balance the work load from the many project and sub-project managers against their resource availability. Every act of delegation establishes a link between the two ‘work plans’ which carries updated information automatically.
Some resources are loaned by the resource or departmental managers to the many project and sub-project managers on a full time or part time basis.
Individual team members receive their own ‘personal work plan’ showing work instructions through the system. Achievement measurement is transmitted when each team member submits a timesheet and accepting the timesheet automatically updates the work plan. Updated plans are transmitted up the delegation links to update higher level plans.
Each user on the system therefore sees a view of the total workload appropriate to their specific needs and are able to investigate in greater detail by inspection of lower level plans.
Conclusion
There are three main strategies aimed at following the consolidation programme management model employed by programme management organisations and these tend to follow the availability of software tools. The methods employed by these organisations to plan and monitor their work load do not represent a model of the organisations management. The software tools are predominantly based on a single project philosophy. Such models are therefore structurally flawed and often inappropriate.
The delegation model, which follows the organisation structure is likely to be more appropriate and more applicable within an organisation.