Project Management Institute

Help! I have a multiple project traffic jam!!


Many companies share the same problems in multiple project environments: Projects that are late, projects that do not deliver the needed functions, projects that overrun costs, projects where the resources are pulled back and forth between projects, etc. These problems are common to many companies because the root causes of the problems are usually the same regardless of the industry/company. However, most companies try to solve their multiple project problems by attacking the symptoms rather than the root causes. This paper will help you understand the problems and their root causes, understand why the standard approaches for solutions don't work, and learn what solutions do work and how to apply them in your organization. By using the principles taught in this paper, you can turn your organization around from very poor project results to excellent project results.

Multiple Project Problems

I have traveled to many foreign countries and to numerous US cities teaching project management. When I ask the attendees (who are often from various industries) what their problems are in multiple project environments, the responses are almost always the same:

  • The projects are usually late
  • The projects seem to never end
  • The projects often do not deliver the needed features
  • The resources are always scrambling between projects
  • No one seems to know the true status of the projects
  • Managers fight for the project resources
  • The projects run way over cost
  • The end users cannot use the project as delivered
  • Management support for the projects comes and goes – but mostly goes
  • After roll-out, many months are needed to stabilize the project
  • Everyone is working their rear off but nothing gets completed
  • No one is happy – not the project sponsors, not the end users, not the project teams and especially not the project managers

Since the same problems are evident in many different industries, we can assume these are not industry specific issues. Actually, we will find that they are a result of the basic project management culture and methodology in most companies – a culture that has as its foundation the goal of individual project success rather than organizational wide project success.

Typical Project Management Problem Solutions

“Make the project resources work harder/longer”

I hear this often from managers and executives. They believe if the projects are late then the project team members are just not working hard enough. They must be slacking off and not getting the job done. If you step back away from the issue you quickly see that this is attacking the symptom (late projects) and not the root cause (unless you believe the root cause is poor workers). This solution is advanced in companies because it lets the person making the suggestion feel superior. “I'm working hard here and if we could just get these programmers and testers off their duff we'd be OK” is their implication.

The truth is that in most companies the personnel work hard. Slackers cannot survive long in the competitive environment of modern industry. Also, while you can get some temporary success by forcing project resources to work extended hours and weekends, this is not a good long range plan. Not only does this solution usually not work, but it can have the opposite effect of poorer project results as the morale of the work force goes down when the “slave driver” mentality is fostered.

“Project Managers need to do a better job of estimating project duration and of managing the projects”

This solution comes from the belief that the PMs are the basic cause of the project problems – they just don't know what they are doing. While this may be true, it typically is not the case and even if it is, solving this element of the project management equation will not result in instant project success. I teach project managers and firmly believe there is value in them knowing how to plan and manage a project well. But excellent PMs in an ineffective multiple project system will make only a marginal positive impact. They are usually not the root cause of project problems and therefore cannot offer significant improvements in an ineffective system.

“We need to cut out all this documentation and just get the work done – it's slowing us down”

This solution is advanced with somewhat good intentions. They're saying let's not do things that might not be value added – just do the work and worry about documentation later. The problem here is that most of the documentation in project management is for good reasons and vital to project success. Managers want to rush into getting started and often do not allow enough time to do proper planning or documentation. If you do not develop a detailed scope statement then the scope will not only creep but it will leap and you'll suddenly be building an application with 300 features rather than 200. And the “We'll do the documentation later” approach never works – there's always another new project starting and time is never available to go back and do the proper documentation.

“Just get the project started already – what are we waiting on”

This solution is cousin to the former one. Managers who do not understand the value of formal project management believe that the sooner you get going on a project the sooner you'll finish. This may be true in a few rare cases (single projects that are very simple and which have little need for up front planning), but is definitely not true when dealing with multiple projects. Not only do you need to plan each individual project properly (before beginning any significant project work), but the resources need to be coordinated across the projects. Rushing into starting the project pulls resources from other projects, causing negative impacts to them. Then when another new project gets started by a different manager, your project will be the one having its resources raided.

“We need an Enterprise-Wide (or some variation on the theme) project management tool”

In today's world, managers and executives are constantly being assaulted by claims of acquiring instant success by employing the latest software solution. Many take the bait and spend enough money to feed a medium size third world country for a year, only to find the project results are just as bad (or even worse) than they were before they got the software.

Yes, I do believe in PM tools. I teach MS Project and strongly recommend that companies use a true project management scheduling tool to manage and track projects. But I make this recommendation within the context of an overall project management system and philosophy. MS Project experts will not find themselves significantly better at bringing in successful projects while operating within a poor project management system.

“Tie everyone's pay into whether or not the projects are successful”

The logic, of course, it that everyone will take a personal interest in the success of the projects. This certainly is the case when a persons pay is tied to the project results. And this solution can get outstanding (temporary) results.

But, alas, the results will be only temporary. What happens is, initially everyone focuses on the work and puts in extra hours over several weeks. Good progress is made for awhile. But then other projects are falling behind so the resources are moved to them (pay is tied to those projects too you know). This causes the first project to now fall behind. The resources work even more hours frantically trying to keep all the projects on schedule. However, the “bad-multitasking effect” takes over. The bad-multitasking effect is when resources are pulled back and forth between projects without using sound business logic or without an organizational wide priority. This always causes the projects to loose time.

Exhibits 1&2 show the damaging effect of bad-multitasking on just 2 concurrent projects.

Two concurrent Projects

Exhibit 1: Two concurrent Projects

For simplicity, both projects are 50 days in length (10 days for each task) and each resource is slated to work 10 days on each task. However, one Manager has their pay tied to project ABC while a different Manager has their pay tied to Project XYZ, so naturally they will both try to get use of the resources for the projects. We will assume bad-multitasking and have each resource switch back and forth between the two projects each week (every 5 working days). Exhibit 2 shows the results.

Results of Bad Multitasking

Exhibit 2: Results of Bad Multitasking

As you can see, if we had run only Project ABC by itself and then run Project XYZ by itself we could have finished ABC much faster (day 50) and XYZ just as fast (day 100). But in most PM systems, the managers are forcing the start of new projects immediately, not waiting until sufficient resources are available to work them. And this is the results of just 2 concurrent projects. If we had added a third project to the mix and forced bad-multitasking between the 3, the first project would have finished on day 140, the second project on day 145 and the third project on day 150. Once again, if we worked project 1 only, then 2 then 3, the projects could have finished on day 50, day 100 and day 150, much better results. Note: the last project always seems as if it finishes just as fast in either system, while the actuality is that another new project is always being added to the system (for example, a forth) that causes additional bad-multitasking impacts, causing the third project to be much later.

I have a project simulator (active Excel file) that runs 4 projects concurrently and moves resources back and forth between the projects (simulates bad-multitasking) based on an algorithm. The projects are planned for 30 days each. Random simulations of 100 trials show that the first project started typically finishes in 55 days, the second project started finishes in 65 days, the third in 85 days and the 4th in 105 days. The simulator can also be set to force a resource to complete their work on one project before starting on another task on a different project (no bad-multitasking). When this simulation is run, the results are as follows: 1st project finishes in 30 days; 2nd project in 45 days; 3rd project in 58 days and 4th project in 71 days – about a 50% improvement across the board. These results parallel what I typically observe in organizations where bad-multitasking exists. As the simulator (and experience confirms), bad-multitasking causes practically every project to finish 50% later than it could have finished if bad-multitasking was eliminated and the projects were properly managed.

Getting back to our solution to tie everyone's pay to project success, when bad-multitasking happens (and it will because everyone is determined their project will be successful so that they get their pay) every project falls behind (the exception is the VPs pet project will probably complete successfully). After a couple of months it is evident to all that no (or only one) project is going to be successful, so everyone quits putting any effort in (they have found they can't be successful even with extraordinary effort) and the overall results are worse than before.

The Root Cause of Problems in Multiple Project Environments

The solutions attempted above were unsuccessful because they attacked the symptoms and not the root cause. The root cause is that the project management system was set up with its goal being to achieve individual project success. The thinking for many years has been that if you strive for individual project success, the individual successes will roll up to overall project system success. This philosophy can be valid in organizations where there is absolutely no sharing of resources across projects. However, this is rarely the case in today's environment, so we need to look at this issue differently. We need to take an organizational wide view of project success. This is termed project through-put.

Project Through-Put is the average number of projects completed successfully over a time period (typically one year) within an organization. When through-put is teamed up with good Portfolio Management, project results often show significant improvements.

Through-put is easily visualized in manufacturing environments. Exhibit 3 shows 4 processes that a PWB assembly goes through.

Manufacturing Through-Put

Exhibit 3: Manufacturing Through-Put

You can increase the efficiency and output of the other processes, but you will not get more than 90 PWB assemblies per hour through the system until you increase the Burn-In output. Burn-In would be called the “Bottleneck” using terminology from the 1980s. Through-put is harder to visualize in project environments like IT projects, but Exhibit 4 helps you see that it still applies.

IT Project Through-Put

Exhibit 4: IT Project Through-Put

We only have enough Coding resources to do 4 (average size) projects per month. In most organizations, since they do not know what their optimum number of projects should be, they force more projects into the system than what the resources can implement. For example, if the management team forces 6 projects into the above system, the projects will jam up around the Coding resources and fall into the bad-multitasking mode. Then, rather than competing 4 projects/month (optimum through-put), only 1 or 2 (maybe 3 if you are lucky) get completed each month.

Organization wide through-put is the answer

So how do we build our project management system around through-put rather than individual project success? It requires a complete change in your project management culture, and it begins with the Executives.

The Executives must be educated to: 1) realize that there is an optimal number of projects that can be implemented; 2) realize that they (the Executives) must ensure that the number of approved projects does not exceed the optimal number and 3) implement portfolio management. This will ensure that the most valuable projects to the organization are the ones being approved and implemented (and that through prioritization of projects bad-multitasking is not taking place). Let's look at each of these individually.

Educating the Executives

The Executives must be educated to understand that most problems in the project management system are not caused by the usual accepted sources (those described earlier in this paper). In fact, they need to understand that they themselves can unknowingly contribute to the problems by forcing too many projects into the system and by not allowing sufficient time to plan the projects and to space the projects out over time to eliminate bad-multitasking.

This education can take many forms. One way (best practice) is to set up a PMO and have educational sessions for the Executives led by the PMO. Barring having a PMO, the senior project manager in the organization can team up with a key Executive (one that supports the premises of this paper) as the introductory step to Executive education. Setting up a web site with the information presented in this paper is another method. Yet another is to have a highly credentialed consultant make a formal presentation.

Regardless of the methods, this education must take place. If the Executives do not come to the realization that the number of projects must be limited, then more projects than the resources can optimally implement will in evidently be introduced and system through-put will be reduced.

Doing the Right Projects

Not only do the Executives need to know about and support the need to limit the number of projects in the system, they also need a repeatable method for ensuring that only projects that bring verifiable benefits to the organization are implemented and that the ones bringing the most benefit are receiving the resources necessary to move them forward toward success. These objectives can best be achieved through a PMO and Portfolio Management.

By its mere presence in an organization, a PMO is typically viewed as the knowledge base for project management in the organization. If presentations by the PMO are telling the Executives to establish Portfolio Management, to prioritize the projects and to ensure the higher pay back projects are being staffed, then the organization will usually follow their recommendations.

A PMO can help implement Portfolio Management with the executive team. Through Portfolio Management, the executives approve only projects that bring verifiable benefits to the organization (rather than allowing “pet” projects from various executives). Part of Portfolio Management is prioritization of projects which forces the executives to recognize that certain projects are more critical to the success of the organization than others. The most critical projects are the ones that should get the project resources, not the lower priority ones.

Finding the Constraining Resources

In order to optimize the project through-put, the constraining resources in the organization must be identified. This can usually be accomplished by meeting with managers and PMs and determining where in the project process there seems to be the biggest backlog – where does the work stake up – what resource type (or process, such as scope definition) seems to cause the biggest delays? This is your constraining resource.

An important point to make here is that you don't have to worry too much about finding the true “most constraining” resource. If you designate a resource as the constraining resource and it is not the true constraining resource, you will still achieve a high percentage of the benefit of spacing your projects around the chosen resource, even if they are not the true constraining resource. Also, it is typically not too difficult to switch your project spacing to a different resource (the true constraint) later. The main point is you must space your projects out around the available resources rather than letting them “start immediately” and right away begin fighting for the available resources.

Results of establishing Through-Put as the organizational goal

In my work at Lucent Technologies (Power Systems Division), we moved from having individual project success as our goal to overall organizational project through-put as our goal. The results were as follows:

  • 1997 and 1998 (using individual project success as our goal)
    • Average project duration      15 months
    • % of Successful Projects      35%
    • Average Through-put            40 Projects
  • 2000 (after setting up through-put as our goal – a 2 year process)
    • Average project duration      9 months
    • % of Successful Projects      87%
    • Average Through-put            90 Projects

As you can see, the improvements were quite profound. I documented similar (but not quite as dramatic) improvements in the PMO results at Bombardier and NY State Tax. Also, a sister Division at Lucent had almost identical improvements in their results as the Power Systems Division.

Will all organizations see similar improvements? Probably not. Each organization is different and will experience different levels of improvement. But any organization will likely see much better improvements than typical approaches when they focus on organization wide project through-put.

Where you fit in

What is your role in all this? Surely you can be at least the catalyst to move your organization toward establishing a PMO, establishing Portfolio Management and switching from a project system built around individual project success to one based on organizational wide project through-put. Look around your organization. Is there a particular Executive who you can talk to about these issues who is likely to be sympathetic to beginning portfolio management or to establishing a PMO?

Perhaps you do not wield much clout in your organization and cannot approach executives from your level. Begin by having these discussions with your next level manager. If you cannot convince your own manager of the need for project management improvement, don't go around them to get support from executives – you can find yourself in very deep water if you do this. Just continue to have on-going discussions with your manager – look for articles through PMI and other wed sites that support the need for organization wide project planning.

Create a project management discussion forum: Talk with other PMs in your organization and see if you can form a discussion group that meets regularly to talk about project problems and their solutions. Once this group is formed, invite managers (and later, executives) to attend to get their input and viewpoint.


Most organizations that run multiple projects share common problems. They share the same problems because the root cause of the problems is usually the same – that the project management system is built around individual project success. Typical solutions attempted in most organizations do not bring significant improvements because they are aimed at the symptoms and not at the root cause.

In order to achieve significant improvements in multiple project results, the root cause of the problems must be corrected – that is, the project management system must be built around organizational project through-put rather than individual project success. Organizational through-put can best be improved by establishing a PMO and Portfolio Management in the organization. When this solution is not available, individual PMs can have success by forming project management discussion groups, by approaching managers with solutions to the project problems and by enlisting executives to champion setting up a PMO and establishing Portfolio Management in the organization.

When the overall projects are limited to the optimum number that the resources can support, when the executives and managers allow sufficient time to plan the projects and allocate the resources without overloading them, and when resources are not pulled back and forth between the projects, overall project results can be improved dramatically.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2006, Roy Pool
Originally published as a part of 2006 PMI Global Congress Proceedings – Santiago, Chile



Related Content