Up to this point, this book has primarily addressed the management of single projects. This chapter delves deeper into the questions that arise when an organisation conducts multiple projects at the same time. These questions arise primarily in the area of relationships between the (higher) management team and the project leaders, and they are otherwise independent of the choice for a waterfall or a cyclical management approach.

Coordination of projects

As described in earlier chapters, the control factors are the parameters along which projects are reported on and directed. These factors also play an important role in the coordination of multiple projects:

Money: determining whether projects are financially feasible
Organisation: arriving at mutual agreements concerning the hierarchy among projects and between the projects and other departments
Quality: determining whether the goals of a project are consistent with the strategy of the organisation
Information: establishing who will report what about the project and when to the management team?
Time: estimating how many personnel will be needed within a given period to arrive at a good distribution of workers across the project teams.

Before the start of a project and after each project phase, a project leader should provide an estimate of the control factors for the rest of the project. The project leader also evaluates these factors as they have been implemented thus far after each phase. This information is transferred to a programme manager or the management team for decision-making purposes, usually in collaboration with the project leader and external parties (e.g. customers, financers). Several of the most important decision criteria are described below, particularly those that relate to the coordination of projects.

Money
The evaluation of financial matters by a programme manager involves the following issues:

• Is the project as a whole, and the following phase in particular, adequately financed?
• What are the possible financial risks of the project? Should a go/no-go moment be arranged?
• What is the liquidity prognosis for the project? Would a problem arise if the income from a project were to arrive later than the expenditures (e.g. if the subsidy is paid only after the completion of a lengthy project)?

By adding all of the budgets together, a programme manager can compile a yearly schedule for the projects. In this way, the programme manager ensures that there will be sufficient turnover from the projects to fund the project workers. Insufficient turnover necessitates the solicitation of new projects. If there is too much turnover, extra personnel should be hired and/or projects must be postponed or even cancelled.

This process provides an idea of whether the projects as a whole are sufficiently profitable financially. For example, consider an organisation that is conducting ten projects of two thousand hours each. The organisation has twenty FTE of project employees in service. We will see later that almost all of the hours of the workers are divided. Assume that the annual salary costs for these twenty FTE amount to one million euros. Should the projects generate less than one million euros (in subsidies, internal financing, commercial proceeds), problem could arise. Fee adjustments or the cancellation of unprofitable projects may be necessary. In projects, the actual amounts that are needed can vary greatly from those that are estimated in the budget, particularly if the project is subsidised (see Project reporting). To compensate for this type of uncertainty, a programme manager should reserve an amount to accommodate unexpected disappointments in one or more projects.

Budgets are also sometimes too broad. In such cases, it is important for project leaders to be prepared to give up some part of their budgets. Otherwise, any projects that did not remain strictly within their own budgets would be too expensive. If projects that are estimated too high assign part of their budgets to projects that were initially estimated too low, the organisation should finish (reasonably) even.

What should an organisation do if it has received a subsidy of 100,000 for a project that turns out to need only 80,000? The money will surely be spent; there are many other uses for that amount of money. For example, another project received 150,000 but actually needed 200,000. Fortunately, it is not possible to determine exactly what the programmers did in the hours that they charged to the projects. With a little re-arranging, everything will line up neatly again.

It is logical for organisations act in this way with their subsidised projects; they could hardly do otherwise. This is a direct result of the fact that organisations must compile a total budget for each application, from which they will no longer be allowed to deviate. One consequence of this situation is that the (financial) project statements from subsidised projects must be taken with a grain of salt. From the perspective of project management, it is unfortunate, as it makes it difficult to determine the exact costs of particular projects. It also contributes nothing in the area of accountability for the use of subsidy money.

Time
Adding all of the time estimates for all of the projects that an organisation will conduct in the coming period provides an indication of the workload for that period. For a given year, the number of FTEs should exceed the total number of hours from the project plans.

Consider the following example: Ten projects together use 20,000 hours. There are twenty FTEs within the organisation, each involving 1700 hours of work. Seventy per cent of these hours are available for projects, and thirty per cent are assigned for general work (e.g. meetings, e-mail, travel time, other tasks, educational leave). This leaves a net of 23,800 (20 x 1700 x .70) hours each year that are available for projects. In this example, therefore, there is sufficient capacity (in global terms) to carry out the projects in the coming year. It would not be possible to add many more without hiring additional employees (and this would require a margin as well).

The calculations above are based on a global, annual perspective. Additional detailed information is needed concerning the necessary capacity, specified according to the tasks or roles of the project workers. The twenty FTEs must be further subdivided into various roles within a project (e.g. programmers, project leaders, designers, system administrators). Although there are probably enough employees, in general, to carry out the projects for the coming year, there may be too many project leaders and too few programmers.

Finally, the workload (expected number of hours) of the projects must correspond to the number of available employee hours for shorter periods as well as for the entire year. If all of the projects in the example that is described above were planned for the first three months of the year, that would cause a problem, even though there would be enough workers for the entire year. The operational distribution of workers on a monthly or weekly basis is accomplished according to the scheduling of the phases of the projects, or time boxes for cyclical projects. In addition, weekly or monthly consultation between the programme manager and all of the project leaders is necessary in order to create operational schedules for the employees.

The following are frequent complaints within project organisations with regard to time:

• There is no clear picture of the work pressure in this organisation. Sales and management keep adding new projects even though we are already having trouble carrying out the projects that we already have.
• If one project goes off schedule, it has many consequences for other projects. Because we must share resources, a delay in the first project causes delays in all the other projects.

The first complaint is common in organisations that are growing quickly and that are oriented toward generating as much turnover as possible By implementing the control mechanisms that are described above, an organisation can gain insight into its capacity on an annual basis, as well as its operational capacity from month to month or even from week to week.

The second complaint has a number of causes. First, in organisations in which this complaint is common, people are often not capable of closing out old projects. Each time that a project is to be completed, the customer makes a new demand, a new bug is detected or the project is expanded. To prevent this situation, it is important that agreements concerning when the project will be completed are made as clearly as possible in the beginning of the project. Further information about addressing this problem is provided in the other chapters of this handbook. (Excessive) work pressure is also a possible cause of the second complaint. Because the organisation is so busy, it may allow no margins between projects. This can cause a slight delay in one project to have a direct impact on subsequent projects. Finally, the second problem is probably less common in organisations that use cyclical project management, as they work with fixed time boxes.

In an effort to increase productivity, personnel are often assigned to too many projects. An attempt to fill the lost hours with other projects, however, can cause serious delays, as illustrated in the following example (borrowed and adapted from Goldratt, 2002):

A programme manager must carry out Project A, which consists of three tasks (a), in addition to Project B, which consists of three tasks (b). Each task requires five time units. If the projects are carried out in the order aaa, bbb, project A will be completed in fifteen (5+5+5) time units. Project B will also be completed in fifteen time units, measured from the moment at which Project B begins.

Another image emerges, however, if the tasks are not performed in direct succession (i.e. they are performed in an alternating sequence). If a task (a) is performed in alternating succession with a task (b), the order of work is ababab. Projects A and B will now require twenty-five time units (5+5+5+5+5) each for completion. The fact that switching between projects also takes time has not been considered.

According to Goldratt (2002), the fact that organisations often assign personnel to many projects simultaneously is one of the most important reasons that projects take (much) too long. Projects that are slated for completion within three months often actually last more than two years. If the projects had been accomplished one after the other, each would have been accomplished in about three months.

This example, along with waiting-list theory, shows that it is not sensible to place such a heavy load on the personnel. Because of short-term cost considerations, management teams are primarily focused on having people work as much as possible. This causes projects to lose considerable speed. It is safe to assume that increasing the utilisation factor by ten per cent can increase the average turn-around time of projects by forty per cent. The costs of these delays, however, are much less visible, particularly in non-profit organisations.

Time registration
At the beginning of a new project, the programme manager must perform the controls that are described above with regard to finances and time capacity. This must be done again between the various phases of a project, with appropriate budget adjustments. Foresight is not the only reason that this is important, however; it is also necessary to evaluate the budgets (of time and money) that are actually used. Were the projects indeed profitable? Were the costs covered as originally estimated? Did that one project actually need 450 hours, or did it turn out otherwise? These questions must be asked and answered in order to improve the quality of project work in the future.
The ability to perform this evaluation requires the availability of a time-registration system. This system is also desirable for projects that are managed by project leaders. Within organisations, there is often resistance to time-registration systems. People feel as if they are being controlled, and they despise administrative chores. Another source of resistance is probably the fact that time-registration systems make it immediately obvious that (often) very little progress has been achieved. The implementation of a time-registration system is a project in itself.
One important argument for the introduction of a time-registration system is the transparency that it can provide. Employees (often) complain of excessive work pressure. The use of a time-registration system that includes both time registration and time reporting makes the work pressure visible. As soon as management or the sales department cause a project to go over budget, the project team can show in black and white that it is already fully booked for the coming period, and that the new project will have to wait.

What requirements must a time-registration system meet?

• A time-registration system must be used throughout the entire organisation, even by the bookkeeping department.
• A time-registration system must be accessible everywhere (e.g. web-based).
• Project leaders must be able to see time reports quickly (i.e. there should not be more than one week between time registration and the internal report).
• (Time) schedules must be integrated into the time-registration system.
• Time-registration systems must allow hours to be charged to work packages in the various phases of projects It is not sufficient to charge hours to general project names.

Project leaders’ heaven
For many project leaders, it is difficult to keep the team members within the budget. Operational personnel apparently pay little attention to the clock; even if it has been agreed that a particular chore should not last longer than a few hours, there is always a reason why it nonetheless took more time.

One architectural firm addressed this problem by reversing the responsibilities. The firms technical artists were required to act as internal freelancers, soliciting work from the various project leaders. This created internal competition. An artist who claims to be able to complete a job in less time than another artist has estimated will probably get the job. Furthermore, eight hours is eight hours. Artists must therefore use their own time to complete jobs that are not finished in the agreed-upon period. It would be wonderful to be a project leader in this organisation; it would probably be less attractive to project employees.

Organisation of multiple parallel projects
Wijnen (2004, p. 187 ff) distinguishes among three structures of project management with regard to the mother company:

• consultation or coordinating structure;
• matrix structure;
• pure project structure.

In the consultation or coordination structure, the project team usually consists of only the project leader. This project leader has little authority over other employees and is involved in a light project that often consists of research work and giving advice to management. When such project leaders need the efforts of other employees in the organisation, they can either ask for help informally or arrange it through their supervisors.

Figure 13: A project using the consultation structure. The position of the project leader (who is often a staff member) is completely outside the departments..

In the matrix structure, the organisation structure is arranged such that team members work (part-time) in project teams and in their positions in the line organisation (also part-time). It is also possible for matrix organisations to include people who are assigned to multiple projects simultaneously.

One major advantage over the consultation structure is that the matrix structure involves project teams that are comprised of multiple employees. This allows a project team to achieve more than it would in the consultation structure, in which the project leader must often go it alone. Project leaders have more authority within a matrix structure, as they actually supervise their own teams. This is likely to cause confusion among team members, who must then report to two supervisors: the project leader and the head of the department in which they work. Employees who are involved in more than one project simultaneously may have even more than two supervisors.

Department heads and project leader(s) should arrive at clear mutual agreements concerning the allocation of personnel. Experience has shown that this does not always occur. Employees are pulled from all sides, and they give first priority to the work of the supervisor who is screaming the loudest. This obviously does not always reflect the highest priority of the organisation as a whole.

Figure 14: Projects organised according to the matrix model. Members of a project team have two supervisors: the project leader and the department head.

In the pure project structure, employees are taken out of the organisation to work solely on the project throughout its entire duration. This form is the most appropriate for large, heavy projects. The project team is largely autonomous and has only the project leader as a supervisor. One important disadvantage of this structure is that it is expensive and radical for the organisation, as employees are taken away from their original work for long periods.

Figure 15: Diagram of pure project structure. The project team is in a relatively autonomous position outside the rest of the organisation.

Which structure is best depends primarily on the projects that are to be performed. The consultation structure is well suited for small projects, and the pure project structure is most appropriate for large, lengthy and heavy projects. In practice, many projects are arranged according to a matrix structure, because most projects fall somewhere between these two extremes. The coordination of projects is the most difficult in the matrix structure.