We assume that we are an organization dealing with multiple projects and have to start a new one. There are four basic organizational models to choose from.
The project line or functional organization is suitable for projects where we mainly need resources with skills that are already available within one line of our organizational structure. We hand over our new project to that line where we find the expertise which is necessary. The project responsibility will be with the line manager of that line, and he staffs the project team with members of his line. Typical examples are projects for product development where every new product version is set up in an individual project, and all of them are managed in "multi project management mode".
The projectized organization is applicable for projects that need resources with skills that are spread across the organization, or have to be hired from outside. We create a new sub-organization in our existing one, just as needed for the new project, and staff it with members from inside or outside our organization, according to the necessary expertise. This type is only suitable for projects of adequate duration so that the organizational change that goes with it is justifiable. Typical examples are large to very large projects like construction of a power plant, subway line, etc., with durations of 24 months or more.
Most projects need resources with expertise that are spread across our organization but the project duration does not justify the organizational change necessary for creating a projectized organization. For that reason, we apply the project matrix organization. We hand over the project responsibility for our new project to a colleague of one line, and staff the project team with members of all the lines where we find the necessary expertise. All staff members, assigned to the new project, enter the leadership of the project manager for the project duration while remaining under the leadership of their "home lines" at the same time. The "matrix" seems to be the most frequently used one for multi project management. Typical examples are projects that need different skill sets, with duration of up to 30 months.
The project functional organization is a special case of the project matrix organization. Main difference is the completely missing project manager's authority over project team members and project budget. In this situation, the project manager can only influence his team members and thus, manage the project with his high level social skills. Maybe, the most spectacular examples are those "under-cover projects" which enjoy very high commitment by the individuals involved but nearly zero (official) authorization of the organization. Some of us vividly remember a TV program in which the "project manager" received a tape with the "project goal", some vague "project requirements", and the special note that in case the "project team" encountered difficulties they could not expect any support: Mission Impossible.
Usually, the term project management office (PMO) refers to a special department in an organization which identifies and supports internal standards of project management processes. The PMO uses generally accepted, international industry standards such as the PMBOK or PRINCE2 as basis for organization specific adaptation. It tries to promote the optimization of those process standards by identifying what works best and feeding this back into the continuous improvement of the internal standards. The ultimate, underlying purpose of the PMO's activities is the sustainable improvement of project results in a multi project management environment.
In that sense, the PMO will serve as the internal source of an organization for guiding, measuring, recording, and documenting project management practices within that organization. This can go so far that the PMO itself involves in managing projects or parts of them. Especially the latter requires systematic coordination between those parts of the organization who carry the project responsibility and the PMO. In case the PMO gets involved into the management of projects we need to define clearly which project activities shall be transferred to the PMO.
The organizational setup looks similar to the project matrix organization.
Usually, the PMO will be the owner of internal, standardized project management processes for a multi project management context. If necessary it will also take ownership of the organization's project selection process, knowledge management process, project management information system, and the metrics for measuring project management maturity. Project management tasks or groups of tasks, ownership of which we typically can transfer from individual projects to the PMO comprise project management responsibility, scheduling, contract management, and risk management. Of course, we only can transfer the parts of those tasks which do not need specific, content based expertise.
Some organizations install a so-called PMO and assign to it only the tasks of managing certain projects (or major activities of them). In this case the PMO is a pool of project managers (or schedulers, or contract managers, or risk managers), and the resulting organization is a project matrix organization.
The following table gives an overview of the main characteristics of the different project organizations for multi project management.
If we organize our projects in a matrix setup we will sooner or later encounter problems with the work load of project team members. It is common practice to have our highly skilled experts working on several projects at the same time. Then we usually observe two problems:
First, these colleagues often have to jump back and forth, from one project to the next; they change their working style from the one-task-at-a-time into a multi-tasking mode.
We can avoid that by clearly prioritizing the projects and encouraging our team members to finish work on one project before switching to the next one. This even improves the schedule situation, at least for one of the projects.
Second, if we take more and more projects into the organization these colleagues tend to try to serve the needs of all projects, and consequently run into work overload. We can avoid this only by carefully coordinating the schedules of the different projects, and then leveling resources between them.
Based on our observations, coordination of project schedules and resources seems to be one of the keys to successful multi project management. In sub-section Project Management Information System, we propose a method that supports schedule and resource coordination.