Abstract
Information technology organizations are getting more and more cost sensitive, and project managers are now being asked to step up and manage more than one project at a time, particularly when such projects are of small to medium size and share the same pool of resources. As a project manager today you are expected to be a master juggler, responsible for keeping several balls in the air even as new balls are randomly tossed in from all sides. Despite this often complex and unpredictable reality of today's workplace, most project management training still addresses only the topic of managing individual projects and solving specific problems in a linear manner. The challenges facing a project manager overseeing multiple projects can range from late deliveries because of resources working on too many projects are not available to accomplish the scheduled work; assigned resources being underutilized because of bottlenecks created by overcommitted resources; or team members’ burnout and reduced quality due to over-commitment. This paper aims to engage project managers in thinking about the impact of managing concurrent projects on the traditional role and responsibilities of a project manager (PM). It highlights some of the main risks and delivery challenges of managing multiple projects simultaneously, and illustrates effective multi-project planning strategies, as well as many practical tips on controlling multiple projects’ budgets, and leveraging less-known scheduling capabilities within project management software to support managing resources across several projects.
Introduction
Thinking of the mechanics of managing multiple concurrent projects often brings to mind the old circus act of Plate Spinning! We do not usually see this act performed as often anymore since other daring and sophisticated tricks are now common place, but we can all probably relate to the scene of a frantic chef on the stage, spinning multiple china plates on different rods while desperately trying to avoid having any of them shattering to the ground. As soon as a plate starts slowing down, the juggler leaps to spin it some more before it completely stops and falls to pieces. This scene is very similar to the scene of a project manager in charge of multiple (spinning) projects, running around between different projects, as he/she tries to give a little bit of attention to each project to prevent any from spinning out of control. However, if you have seen enough of these acts, you would know that more often than not, at least one (or more) of these plates inevitably falls to ground (accompanied by loud jeers from the crowd!) when the juggler does not make the rounds fast enough as the number of spinning plates increases.
This chaotic scene makes for an entertaining act, but it is hardly the competent picture of a PM in control of his or her projects. Managing multiple concurrent projects either connected within a large program/project, interdependent or independent is more common of an undertaking than one might think. Nevertheless, relatively little attention is given to the skills required to manage concurrent projects as part of the standard project management training. Most techniques and methodologies attempt to ameliorate the management issues of one monolithic project with the assumption of a dedicated PM (and mostly dedicated resources) for the project. This paper attempts to address this gap by exploring the challenges and opportunities of managing concurrent projects with shared resources; and highlighting the skills and techniques needed for the PM to remain in control and avoid being a frantic juggler of multiple spinning projects.
Managing Multiple Projects vs. a Program - Two Sides of One Coin?
Managing multiple projects and managing a program are two terms often used interchangeably, but as we will see, there are tangible differences between the two practices. Project Management Institute (PMI) defines a program to be “a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. The program management itself therefore is defined to be is the centralized coordinated management of a program to achieve the program's strategic objectives and benefits” (PMI, 2013). The American Management Association (AMA) further defines a program into two distinct types: interdependent program and program of independent projects. “An interdependent program is a project so large that its major components are projects in their own right. On the other hand, a program of independent projects is different: the program is not itself a project. New projects are added as old projects are completed. The consolidated program management is there to provide operational support for project activities” (Dobson & Singer, 2011).
Now from the perspective of multiple project management, it is not always the case that multiple projects managed by the same PM should be considered a program. In many cases, the allocation of projects to one manager happens for other reasons such as the manager's availability, domain knowledge, or overlapping teams. In this case, there should be no expectation of an added program management layer and the PM is expected to assume all management tasks for multiple projects. In other words, every program by definition will potentially have multiple projects, but not every case of managing multiple projects together can be considered a program. To be clear, this paper is mainly concerned with managing multiple projects under a single layer of project management, with no presumption of an added layer of program management.
Organizational Drivers for Managing Multiple Concurrent Projects
Small to Medium Budget Enhancements and Maintenance Projects
Mega projects for deploying a new ERP application or replacing an aging strategic legacy system are usually the ones that garner most attention within an organization and attract seasoned PMs. However, after the dust settles on the deployment of these applications, there comes about many years of small to medium enhancement, maintenance, and integration projects. These follow-up initiatives can be launched independently or organized within a structured program. The mega projects are usually few and far in between, but the small enhancement and maintenance projects, on the other hand, are more commonplace with a steady flow year after year. Consequently, those PMs capable of concurrently managing a number of these smaller budgets, concise scope types of projects become increasingly in high demand.
Number of Projects as a Success Criterion
Some organizations measure the success of the different business units by the number of projects they can complete within their allocated annual budget. This drive to achieve a higher number of projects delivered may have an unintended consequence of scope fragmentation between multiple projects. It becomes therefore incumbent on the PM to understand this motivation and apply some effective techniques to lower the management overhead of managing these related yet separate projects, while maintaining their independent reporting and budgetary structure.
Effective Alternative to the “Working” PM Model
One of the ways some organizations try to maximize the value of a PM on small-medium budget projects is to hire a PM who can do more than just project management! As the thinking goes, a business analyst (BA) with some seniority may “lead” the project while doing “actual” project work of completing project analysis deliverables. The interview process for these positions usually focuses on the variety of services a prospective PM can provide to the project (hence, the chance of lowering the overall project headcount) instead of focusing on the core skills of PM like project planning and risk management. This approach introduces multiple risks to a project of any size and jeopardizes the projects’ chance of being completed on time and on budget, since the focus of the project lead would centre around completing his/her deliverables rather than ensuring the overall success of the project (remember the old adage: if you're doing, you ain't managing!).
A better alternative therefore is for organizations to hire professional and competent PMs who can handle multiple concurrent projects and focus on applying best practices across all projects thereby ensuring that delivery risks are adequately managed on each and every project, regardless of size and budget.
PM Role in a Multiple Project Environment
Directing the Traffic Rather Than Driving the Car
As PMs we are inclined to be in the driver seat of our projects, injecting ourselves in all issues and decisions big or small. It is therefore maybe counterintuitive for some PMs in charge of multiple projects to step back and be selective in choosing the type of issues that warrants his/her involvement. Monitoring the project budget, preventing scope creep, managing stakeholder communication, and managing dependencies and flow of resources across multiple projects (managing the traffic!) should rightfully occupy the majority of the PM‘s time and attention in a multi-project environment. Conversely, the PM should avoid the temptation to be involved in every minutia of each project, which can lead the PM to lose sight of the “big picture” and therefore increase the risk of failure of one or more projects.
Leveraging the Business Analyst on the Team
The previous section made the argument for the PM to be selective of the way he/she is involved in day-to-day running of each project. The PM in charge of multiple projects would therefore be wise to leverage the business analyst's role and delegate some of the leadership authority in dealing with project's daily issues (for example, scope clarifications requests from any of the stakeholders, walkthroughs and follow-up with developers ... etc.). The business analyst, who gathered and documented the business requirements arguably has the best understanding of the scope of the project's deliverables and can step up to coordinate some issues resolution independently from the PM. Granted, there is certainly a fine balance that the PM will need to achieve in order to still maintain adequate control of the project, given that the BA may also be assigned to multiple projects concurrently. However, when appropriately engaged, the BA can enable the PM of maintaining focus and avoid getting mired in the daily grind of each project within his/her purview.
Setting Priorities and Resolving Conflicts Across Multiple Projects
For resources assigned to multiple projects, the last thing they should be concerned with is which project takes precedence when scheduling conflicts arise. This problem is exasperated when different projects are managed by more than one PM, in which case the shared resources can find themselves frequently pulled in many different directions across multiple projects. This issue is further highlighted in the book Managing Multiple Projects, where it states that “Classical project management involves optimizing a single project. Multiple projects must be prioritized within a limited resource environment…. Classical project management assumes all key team members are available exclusively for project needs. In the more common shared resource environment, people may be supporting multiple projects simultaneously” (Dobson & Singer, 2011).
This situation can often lead to tension and may severely impact the ability to meet the delivery schedule of the projects involved. Obviously, the issue is more complicated when a resource reports to more than one PM in a multiple projects delivery environment, nevertheless it is incumbent on the PM(s) involved to engage the stakeholders groups to negotiate and define a clear set of task priorities for shared resources, and not leave it up to the individual team members to decide which project should take precedence when competing for limited resources.
Risks and Delivery Challenges of Managing Concurrent Projects
The Double-Edged Sword of Multi-Tasking
Technical professionals often pride themselves on their ability to multitask. Being involved in multiple deliverables and switching between tasks on different projects seems to appeal to many IT professionals. It is even considered a sign of competency and a source of bragging rights come performance review time. However, the cost of multitasking on productivity, project timeline, and deliverable quality is not always factored in when allocating resources to multiple projects.
To illustrate the tangible and intangible (hidden) costs of multi-tasking, the AMA Handbook for Project Management (Second Edition) references two comprehensive research studies on multi-tasking. One of the studies referenced on multi-tasking, published in 2001 in the Journal of Experimental Psychology, discovered that when switching from one task to another, there are “time costs” in terms of productivity, efficiency, concentration, etc. and that these costs increase with task complexity. Another 2001 study of 1,003 workers conducted by the Families and Work Institute revealed that 45% of those surveyed felt that they had too many tasks to work on simultaneously and experienced frequent work interruptions, resulting in difficulty focusing on the work to be done. Logic, experience, and common sense show that the more projects that have to be juggled, the less efficient people are at performing any single task; and the longer it takes to return to the interrupted task, the harder it is to reengage in the previous activity (Dinsmore & Cabanis-Brewin, 2006).
The results of these studies illustrate the dichotomy that exists in multitasking and should give all PMs in multi-project environments a pause when allocating (or over allocating) their resources over several projects or tasks. Multi-tasking maybe a defining characteristic of our modern work environment, however it should not be used as a panacea for ameliorating unrealistic scheduling scenarios that do not cater for the overhead incurred when resources repeatedly switch between multiple tasks.
Scheduling Risks and Staffing Challenges When Using a Shared Resource Pool
Staff Overutilization
This is a direct result of the overuse of multi-tasking discussed in the previous section as well as the bandwidth limitations that can be faced when scheduling tasks for a team with diverse skillset. Consider the scenario of having 10 people on a team; there can only be no more than 10 simultaneous activities going on at any particular time, assuming those activities take full-time commitment. However, that does not take into account differences in skill sets: there maybe 10 people available in a resource pool, but if only one of them has the necessary skills to perform a given task, then there can only be one task using those skills going on at any particular moment. Now, if there another task in a concurrent project that requires that same skillset at the same time, the schedule of one project or both maybe impacted and late deliveries may occur because of resources working on another project are not available to accomplish the scheduled work.
Staff Underutilization
The bandwidth limitations discussed above also tends to produce bottlenecks in project execution. If there is only one available person to perform a given task, and all projects need that task to be accomplished, then the speed with which that one person can accomplish the task turns into the speed limit for your entire operation. This could lead to situation where other assigned resources being underutilized because of bottlenecks created by overcommitted resource(s) with specialized skills.
Staff Burnout
The act of spreading the available resources too thin between multiple projects can sometimes lead to elevated levels of stress and burnout among the team members. Costs, both tangible and intangible, resulting from team member burnout, and reduced quality due to over-commitment should be considered when team members are involved in multiple projects. This could also lead to higher turnover rates for the IT organization as whole when overcommitted team members feel they are always stretched to the limit between competing projects’ demands.
Planning Strategies for Multiple Small-to-Medium Size Projects
Achieving a Balanced Life Cycle for Multiple Concurrent Projects
When managing multiple projects, it is crucial that the PM in charge identifies the overall lifecycle for the projects involved based on whether the projects within the group are independent or interdependent.
Exhibit 1 – A group of Multiple Independent Projects from Dobson and Singer (2011)
Exhibit 2 – A group of Multiple Interdependent Projects from Dobson and Singer (2011)
Exhibit 1 shows a group of independent projects that may use a common pool of resources, yet the outcome of one project is not necessarily dependent on the outcome of another. The initiation of any project within such a group will be driven by resource constraints and time requirements dictated by the end users. On the other hand, Exhibit 2 illustrates a more connected lifecycle for a group of interdependent projects linked by a common outcome as well as by resources. In this case, the initiation of projects follows a more prescribed order defined by the outcomes of preceding projects.
Understanding the pertinent lifecycle of a group of projects will help the PM balance his or her workload and involvement within each project. This is due to the fact that the demands on a PM‘s time and attention during a project's initiation and planning phases are substantially higher than that during the remaining phases of the project. For a PM, kicking off more than one project at a time can add considerable risks of mismanaging the initiation and planning processes for each project, which can consequently lower the project's chances for success. Exhibit 3 shows a snapshot of the allocation of multiple projects in various lifecycle stages to a single PM. It is fine to have multiple projects under the purview of a single PM, so long as attention is paid to limiting the number of projects within the initiation and planning stages.
Exhibit 3 – Multiple Projects Managed by a Single PM in Different Lifecycle Stages
Budget Allocation and the Importance of Setting User Expectations
There is a common misconception among PMs that relates to managing the budget of small to medium projects. Given their smaller budget size, these projects are often thought to be fairly straightforward and certainly less risky than the large million-dollar-plus projects. While acknowledging the fact that budget overruns in a large project will have more of a financial impact on the organization, it is important to realize that on a smaller project, the margin for overrun is razor thin (e.g., on a $50K budget, a mere $7,500 of extra spending makes the project 15% over budget!). To illustrate this further, think of the task of landing a fighter jet on an airplane carrier compared to landing a Boing 747 on an LAX runway. Both tasks are challenging to say the least, but one is much less forgiving with much smaller room for error than the other. Now, think back of a PM managing multiple of these small-budget projects concurrently within a thin margin of error and you will begin to better appreciate the complexity of the task.
When tasked with managing multiple small to medium budget projects, it is imperative that the PM understands what can realistically be delivered within each budget and effectively sets the user's expectation accordingly. Take for example an enhancement project with an allocated budget of a $100K. For the majority of end users, their perception of the number and complexity of the features that can be delivered are directly related to the total budget (i.e., the full $100K) with no allowance for typical project overheads. Educating the users on the many activities that will need to be covered within the project scope in addition to actual development is a crucial success factor when managing a small budget project. A sample breakdown of a $100K budget can be presented to the user as follows:
| Project management: | $15,000 (should cover all PM activities throughout the project from planning to closing) |
| Analysis and design: | $25,000 (should cover initial analysis/design and support during the project) |
| Actual development: | $40,000 (this directly drives the scope of features in the enhancement release) |
| Testing and deployment: | $10,000 (this should cover test planning, execution and bug fixing) |
| Contingency: | $10,000 (managed by the PM) |
By highlighting that only 40% of the original budget can be allocated to actual development, the user's expectation should be aligned to the reality of project delivery, which makes the second part of the conversation a little easier; focusing on what can actually be delivered within the development budget. Note that further detailed allocation of the budget to the deliverable level in a Work Breakdown Structure (WBS) will be required during the planning process to enable the PM of effectively controlling the budget during the execution phase, but this fairly high-level presentation is usually sufficient for the purpose of end-user communication.
The user usually starts with a long list of features, expecting that a certain percentage of the features (almost always 100%!) would be included within the current release. One technique the author found helpful in facilitating the scope discussion with the users is to rank each feature based on complexity with input from a development lead, to be either: high, medium, or low. Each level of complexity should have an agreed upon development level of effort. The development budget (not the total project budget) should be the ultimate constraint for determining the number as well as the composition of features included, and the user should be then empowered to select and make the necessary trade-offs within the development budget constraints. For example: based on the level of effort and the available development budget, one acceptable combination of features for the project could be: 5 highs, 3 mediums and 6 lows; or 3 highs, 6 mediums, and 10 lows. This approach has been found to be less confrontation, since it enables the user to be in the driver seat without compromising the integrity of the budgeting process, and it facilitates budget allocation and tracking especially when dealing with a number of concurrent small-budget projects.
Consolidating Projects and Understanding Critical Path Across Multiple Interdependent Projects
Even when they are considered totally separate projects, there is value in consolidating interdependent projects from a PM perspective. Prime candidates for consolidation are projects that:
- Share common resources, either partly or completely
- Share a common stakeholder group with interdependent delivery dates (common sponsor and end-user community)
- Share internal or external dependencies (external vendor or 3rd party dependency)
Consolidating interdependent projects can provide the PM with the following benefits:
- Manage common resources’ allocation across different projects. This is a very useful tool to help avoid over committing shared resources across multiple projects
- Identify the critical path for all consolidated projects
- Lower the overhead of PM tasks by consolidating the planning and reporting functions
The remainder of this section explores the fundamentals of project consolidation using Microsoft Project 2010 Standard Edition (Marmel, 2010) as the project management tool.
Project Consolidation: From Multiple Plans Down to One
Realizing the benefits highlighted above, some PMs may opt to merge separate, yet related projects plans into one consolidated master plan. Consolidation is achieved by inserting multiple project plans into the master plan, at which point they appear as “subtasks” of the original project plan as shown in Exhibit 4.
Exhibit 4 – Consolidation of Multiple Projects from Project 2010 Bible (Marmel, 2010)
The consolidated projects can still be linked to their source project plans so that any changes in the source version can be automatically reflected in the consolidated version and vice versa, changes made to the consolidated version will be reflected in the individual source plans.
Creating Dependencies Across Multiple Projects
It is common in a consolidated project to have tasks in one subproject that are dependent on other tasks in another subproject. This dependency can be defined in the consolidated project like one would normally create a dependency between two tasks in a project plan, but this dependency will also be automatically reflected in the source plans for both subprojects, which will show as a dependency on external tasks in the source projects.
Identifying the Overall Critical Path
One of the main advantages of consolidating separate projects into one master plan is the ability to view a single critical path across all consolidated projects, which accounts for any task dependency that may exist between any two or more interdependent projects. When multiple projects are consolidated, by default Project calculates inserted projects in the same way it calculates summary tasks effectively showing the overall critical path across all the projects by using the late finish date of the master project to make calculations. As shown in Exhibit 4, only Subtask 7 is on the critical path of the two consolidated projects.
Resource Sharing: Leveraging a Shared Resource Pool Across Multiple Projects
It is not uncommon for multiple projects (whether they have a single or multiple PMs) to share resources, both human and inanimate (meeting rooms, technical tools, office automation…etc.). Setting up a resource pool in Project can facilitate resource management, especially if several projects share the same resources. This is accomplished by setting up a project file that contains only resource information and referencing that file in one or more project plans using the Share Resources feature in Project. Once a resource pool is created and shared between multiple projects, any resource assignment made within one project will be reflected on the resource pool and therefore visible to all other projects that are sharing the pool. For more detailed information on setting up and using a resource pool, please refer to the Project Bible 2010, Chapter 19.
Practical Tips for Controlling the Execution of Concurrent Projects
Regardless of the automation level and sophistication of timesheet collection and tracking methods available to the PM managing multiple projects, it is important to be able to track the time spent by each resource on each project's phase/deliverable. This becomes challenging in a shared resource pool environment, where a resource may play different roles within a single project as well as across multiple projects. However, the PM in charge would need to track the burn rate for each resource by phase and deliverable on each project to identify any overage as early in the project's execution phase as possible. Given the thin margin of error allowed on a small budget project, this level of tracking can mean the difference between an on-budget and over-budget project delivery.
It is very easy when engaged on multiple projects to lose track of the budget burn rate on one or more projects just enough for these projects to spin out of control. The PM should therefore devise a way to monitor the budget by phase and detecting slippage early across multiple projects. This can be achieved by aggregating and compiling the utilization data of all resources on all projects into a common dashboard that he or she can easily refer to on a regular basis to confirm the financial health of all projects under his or her care. Depending on the maturity of the PMO in the organization, such a budget monitoring dashboard may already be made available to the PM. However, if this is not the case, the PM should take the time to develop a simple dashboard similar to the one shown in Exhibit 5 to help him or her of monitoring progress on multiple projects from a budgetary perspective and act early enough with corrective actions that can put the project back on track.
Exhibit 5 – Sample Multi-Project Dashboard for Budget Tracking
The color-coded status in the dashboard is driven by budget consumption against allocation. For example, the status for a phase (or overall project) would be green when remaining budget is > 30%, yellow when budget remaining > 10%, and red when there is only < 10% remaining budget. These are suggested thresholds and different PMs may choose to fine-tune them based on his or her particular risk tolerance. It is worth mentioning that the budgetary status, which is based solely on tracking the resources burn rate against allocated budget, should also be complemented with the progress status on completing project deliverables to paint an accurate picture of the project's overall status. For example, a budget status of red in the analysis phase should not be a cause for alarm if almost all analysis deliverables have been completed. Conversely, a yellow status for the design phase should be worrisome if only 50% of design deliverables are done. Therefore, the PM should use the budget dashboard as a guide for the areas that he or she would need to drill and investigate status further across all projects under his/her care, not as a stand-alone communication tool with the projects’ stakeholders.
Conclusions
This paper argues that in the face of growing demands for PMs to add more value to IT organizations, managing multiple concurrent small-to-medium size projects is a far superior alternative to the “working PM” model, where a PM becomes more of a project lead with deliverable responsibilities. The paper encourages PMs to embrace the added responsibilities of managing multiple concurrent projects, and aims to equip them with the necessary planning and execution techniques to anticipate risks, remain in control and avoid becoming a frantic juggler of multiple spinning projects.
