Due to three, seemingly beneficial policies, some widely accepted project management practices, and the prevailing organizational structure, most businesses that continually share resources across projects experience enough multitasking to cut their productivity in half. This paper will explain the root causes of project portfolio underperformance and provide leaders with a roadmap to increase the speed of benefit recognition through improved productivity of portfolio components.
Why do Project Portfolios Underperform?
Project portfolios rely on successful project execution, including initiation, planning, executing, monitoring and controlling, and closing. Successful project execution in organizations is the responsibility of the project management office (PMO). In 2010, a study indicated that 84% of companies have PMOs (PM Solutions, Inc., 2010).
The same study showed that 50% of PMOs failed or closed from 2006 to 2010. The biggest challenge sited by survey participants was resource management, specifically resource conflicts. For the mature PMO, resource management stands out as the most significant problem area. Only 37% of mature PMOs, 24% of all PMOs, have a resource management process for optimally estimating and allocating resources. Resource contention issues and conflicting authority are, by far, the greatest resource management challenges for mature PMOs (PM Solutions, Inc., 2010).
What is Multitasking?
To understand multitasking, its effects on productivity, its causes, and its cure, we must define first a few terms. These are the terms, tasks, single-project systems, multi project or shared-resource system, and multitasking. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines an activity a distinct, scheduled portion of work performed during the course of project (PMI, 2012). Tasks are activities that must be executed to complete project deliverables that facilitate the accomplishment of project objectives. A task is any contiguous sequence of activities that a worker must perform, to create an output that is required by a fellow worker or by a waiting recipient external to the worker's business. The start of a task and the end of the task are punctuated by interactions, exchanges, or transfers, between the worker performing the task and those who, either, provide the necessary inputs or await the task's output.
To root out crippling multitasking from project portfolios, we also must understand the type of project system a project team works within. There are two types of systems, a collection of single projects system, where every project has its own resources and secondly a shared resource system that has multiple projects and programs in a portfolio sharing the same resources. Most delivery organizations are in a Shared Resource System. A Shared Resource System is exactly that, a system of resources (human resources and physical resources) and projects. A portfolio is a component collection of programs, projects or operations managed as a group to achieve strategic objectives (PMI, 2012). Most portfolios operate in a shared resource system. When not managed as a system, a Shared Resource System is highly prone to multitasking — a resource stopping work on a task from Project A, before it is completed, to work on a task from Project B.
Multitasking happens whenever a knowledge-worker's limited capacity becomes a highly valued prize, for which two tasks or more compete from different projects. At the core of multitasking is a resource conflict. When left unresolved, these become the causes of multitasking. A project resource is presented with multiple tasks across different projects. As an example, consider three projects; Project A, Project B, and Project C. A project worker, let's call him or her Developer 1 is working on a Project B task, the next day a task for Project A shows up in his or her inbox, and a resource prioritization conflict suddenly exists.
In most organizations that share resources across projects, resource conflicts are inevitable. These resource conflicts are a symptom of PMO failures, but not the reason. The root cause is not resource conflicts. It is that resource conflicts are handled improperly. The reason PMOs fail is poor productivity, or lack of speed, not enough projects getting done to deliver portfolio benefits and to facilitate the organization's strategic objectives.
PMO managers have all experienced these problems. They include many more projects active than the available resources can handle, executives demanding that their projects must have the highest priority, and an overwhelmed matrix resource staff struggling to meet aggressive deadlines. It's not just one or two projects that slip. The completion dates for entire portfolios of critical projects march to the right relentlessly, by months, causing undesirable behavior of managers.
Project teams and their management (typically cost centers whose existence depends on their ability to serve their executive sponsors by delivering products and solutions) often become targeted as the reasons why business lines don't achieve their objectives. Consequently, these people do the only logical thing: They protect themselves from being reorganized or from being fired and having their work outsourced.
Logic tells project teams and their management to prioritize all the projects and to restore their credibility by committing only to what they can accomplish. However, two things keep this logical solution far beyond their reach: First, project teams and their management don't have the authority to prioritize projects. Second, portfolios are defined by senior executives. Projects are identified and added to portfolios, because the projects are aligned with the strategies that the senior executives want to deploy. Removing or even pushing the pause button on projects that are aligned with the strategies of executives can become job-ending events, for project teams and their management.
Understandably, project teams and their management must protect themselves as best they can, in any way they can, and they do. Here's how: First, they echo their agreement, with each executive, that the executive's projects are strategically invaluable, important, indispensable, as are the projects of every other executive. Second, they do their best to buy more time, from each executive already disappointed. Third, they point to the ever growing piles of PIPs (projects in progress) and use these to justify bigger budgets and still more heads to count.
Unfortunately, these self-protection tactics are not solutions but enablers of the worst kind; they enable each executive to kick the multitasking into an increasingly performance-grinding higher gear.
These conflicts for attention go unresolved, because project teams and their management bear no authority with which to prioritize projects. Every time they're faced with the choice, either A or B or C or all of the above, the members of the project teams and their managers opt for multitasking. Would you find it reassuring if you had to tell two executives that their projects made no progress since your last report, because you decided on your own to lavish your attention on one task alone, the one from the project of some third executive? With the multitasking safe-default in effect, no competing task can get a worker's full capacity. Instead, every task in competition gets but a slice, a share. In Exhibit 1, considerable capacity could have been used to finish P1 and to earn the corresponding revenues early; instead, that capacity was used to add P2 strategically early to the work in process.
Multitasking cripples productivity, delays critical handoffs of related portfolio deliverables, reduces quality, and burns out top performers.
Multitasking can be measured using the formula shown in Exhibit 2.
A task becomes active when the work of the task actually starts, a task is in queue (ready to start), when the inputs needed for the task's successful completion become available. The optimal measure, for the multitasking ratio, is less than 1; however, it is not uncommon for portfolios using a shared resource system to have ratios above 2 or 3.
When Multitasking is Removed
Exhibit 3 illustrates what happens when a company gets rid of all multitasking. The horizontal axis of the scatter plot indicates project duration, in business days. Holidays and weekends are eliminated from the data. The vertical axis indicates project size, measured by the number of staff-days needed to complete each project successfully. Data that point at the same height indicate projects of identical size. As Exhibit 3 shows, there was no significant change in the size of the company's projects, but there was a very significant reduction in the duration of the company's projects.
Project Systems and Productivity
Successful project management execution requires specialization and interdependence. No one creates a new product, service, or result alone. Many subject matter experts exchange the outputs of their work with each other, in sequences that are specific to each project. Initially, the sequences of necessary exchanges are unknown; they must be discovered for every new project. All the required sequences of exchanges must be completed successfully, before a new product, service, or result can yield any measurable degree of benefit.
One approach that has been successfully used involves forming a new team dedicated to the new project, thereby creating a new single-project system. While the project lasted, the corresponding resources were shielded from the external items of work. When the project ended, the team was dissolved; the corresponding system ceased to exist. The problem with this approach was that long lead times to start new projects were required, because critical resources were tied to their existing “single project systems,” delaying the scheduled starts of new projects until an existing project was completed.
Today, we don't create a new system with the start of each new project. We don't dissolve our one system when we finish any project. New projects come in, and finished projects leave, continually; more importantly, the projects create continuous flows of tasks for the resources that they share heavily.
For project portfolio management, productivity is defined as the mean rate of completion. This is calculated as the number of productive days of business in the year, divided by the mean spacing interval, the average number of days of business (DOB) from the finish of one project to the finish of the next. Exhibit 4 depicts how to calculate productivity for your project portfolio.
When multitasking prevailed, in Confluence, the mean spacing interval and the corresponding rate of completion were 39 days of business per project and 7 projects per year, respectively. With multitasking removed, these values changed to 19 days of business per project and 13 projects per year (see Exhibit 5). The increase in productivity exceeded 80%, simultaneously; duration at completion declined by more than 50% (see Exhibit 3.)
Project management practices also amplify multitasking.
Self-preservation behaviors are not the only causes of multitasking. Traditional project management short comings and policies also enable multitasking in many organizations. Expensive resources in shared resource systems find themselves with idle time, due to project delays causing downstream ripple effects on other projects or to the inability to accurately estimate when these key resources are needed on critical project tasks, cause resource managers to hoard the expensive resources, to ensure their availability. Often such idle time leads management to conclude that everyone should be assigned to multiple projects. The more projects someone is assigned to, the busier they will be.
The project management practices that amplify multitasking include the following: Project managers opt not to build project plans, or they submit plans that omit significant scope. They fail to create a detailed sequence of activities. Project management offices allow project managers to submit project plans that omit task level resource assignments. Project managers also fail to account for the “fog of variation,” and treat duration as a deterministic quantity. They also underestimate duration to completion, for tasks and for projects alike. Perhaps the most damaging practice of all is when they fail to consider the cross-project conflicts for resources.
Without the necessary project planning detail, tools, and methodology to analyze the Shared Resource System, delays ripple throughout entire portfolio of projects, setting the stage for more disappointment, broken promises, artificial urgency, and more crippling multitasking. This leads to optimistic commitments and the inability to manage shared resources across projects effectively.
Lastly, traditional PMO structure, the matrix organizational structure, enables multitasking. Everyone is assigned to multiple projects, making projects highly interdependent. Resource managers are responsible for only a small subset of the resources and each project manager is responsible for a few projects. Despite the heavily shared resources and the many interdependent projects, no one is managing the full system. We have enterprise-wide systems, which include heavily shared resources and highly interdependent projects; yet the PMO continues to rely on organizations, policies, practices, and tools designed originally for managing projects with dedicated teams.
Improving Shared Resource Systems – What You Can Do
The degree to which one can remove multitasking, from the project portfolios and programs of an organization, depends on one's spans of authority and influence. It is possible even to banish the multitasking monster entirely and permanently, given a manageable degree of support and of change throughout an organization.
Whereas individual workers can improve only their respective productivities, senior leaders responsible for a collection of projects or portfolio can remove multitasking widely and permanently, replacing it instead with the highest level of sustainable performance afforded by its project portfolio investments.
The magnitude of the risk that such change-efforts can create, due to the poor or incorrect implementation approach, also is commensurate with one's span of authority. While some ill-advised actions by an individual worker can put at risk only the worker's next performance review, poor decisions and actions by a responsible executive can put the entire portfolio at risk. Senior leaders and executives must learn the proper methodology and execution plans to remove multitasking in a measurable and systematic manner, thereby delivering benefits sooner through increased levels of productivity with limited risk.
There are things that project workers can do as well, to help slow down the rate of multitasking. This includes learning to say no and how to say no. An important action is to accept assignments exclusively from their supervisor. If other project managers ask workers directly, to take on additional work, workers should politely ask them to contact their supervisor. If they insist the worker take on additional work, they should inform him or her that his or her first responsibility is to his or her supervisor, and not to betray his or her supervisor's trust. If workers are asked by their supervisors, to take on additional tasks, they should ask a simple question — which task do you want me to finish first? Though not a cure by any means, this will politely and respectfully push back to reduce the rate of multitasking.
Project managers can help to reduce multitasking as well, first by recognizing and properly using their authority as a project manager to take complete charge of planning all aspects of their projects. Project managers should begin creating project plans with the proper level of detail, including task level resource assignments and a valid sequence network. A second way to reduce the multitasking is to make only feasible commitments about project deadlines. Lastly, project managers can collaborate with their peers to resolve all conflicts across projects, at least for the heavily shared resources.
The real cure to the productivity problem lies within the senior management team. The senior management team must recognize they have a system to run, not a set of single project systems. The senior management team must create a stable source of operational decisions. This means retaining all the strategic decisions but delegating all the operation decisions. To do this, organizational structure is likely to change. There are additional roles that need to be created; one is the chief matrix officer (CMO). The CMO uses participative management, to bring about those timely, operational decisions that serve the business best. For the system to perform at level best sustainably, the CMO needs the unwavering support and the delegation of authority from the entire senior team for all operational decisions. The CMO brings together, once each week and as members of one team, all the resource-managers and all the project managers, to review the operational measurements with the team, project by project, for all the projects listed in the week's report. When the operational measurements for a particular project indicate the need, the CMO poses just three questions:
- “What's going on with this project?”
- “What are we doing to fix this?”
- “What are we doing to avoid a repeat of this at some future date?”
With the delegation of authority from the senior team, the CMO empowers all the managers to respond immediately, to every team decision.
The next new role that must be created is that of enterprise analyst (EA). The enterprise analyst integrates all the project-specific models that the project managers maintain, thereby creating a valid and practical model of the enterprise. Working closely with all the project managers, the enterprise analyst updates the model of the enterprise and determines two sets of vital measurements:
1. The operational measurements that the members of the matrix-management team need for their weekly meetings.
2. The task-specific measurements of urgency that each resource needs to identify the best task to finish next.
With these two roles in place, it becomes possible to manage all the projects and all the resources as one system.
However, these changes are not trivial. The entire organization must be educated on the challenges of a Shared Resource System, and on the methods, and tools that need to be in place to capture the right information about each project to effectively manage such a system. Finally, a level of organizational change is needed to manage expectations of executives on topics such as when project resources execute work and how project resource performance is measured within the system to improve the overall portfolio performance.
The implementation of a shared resource system that is optimized for maximum performance requires a combination of technical skills, of tools, and of carefully crafted change management efforts. The process can be broken into a few major steps.
As a first step, one must capture benchmark data of the organization's project delivery environment. These data will allow the sponsor and his or her team to measure performance improvements.
A second step is to build a coalition of executives that will not merely support but require the change. This coalition is built typically through one or more workshops with key executives, during which the logical and science behind Theory of Constraints is tested in a practical yet valid simulation that compares current project management and the improved PMO practices. The support that the experience creates, among senior executives, significantly increases the likelihood of success.
The third step is to begin to organize the delivery team that will be accountable for making decisions regarding prioritizing project tasks across projects that compete for the same resources. The key input for this delivery team is a current active project list that identifies each project in a numeric prioritized order. The first project on the list should be the most urgent, for the organization. No two projects can share the same priority. It is with this list that the delivery team begins to apply the simple rules that eliminate multitasking. But, first, the sponsor must be willing to communicate to all executives this prioritized list and the notion that it will be used to make task level decisions about project worker task priorities. An example may be that there are three projects in this order of priority: Project A, Project B, and Project C. A project worker, Developer 1, is working on a Project B task; the next day a task for Project A shows up in his or her inbox. Through the coalition building and communications that create a binding agreement between executives and the sponsor of this new multi-project system, Developer 1 is now empowered to work on the Project A task through its completion without interruption! Then, the Developer can go back to the Project B task. When this logic and decision making is applied across the prioritized list of active projects this will greatly reduce multi-tasking and provide a significant performance boost to the entire portfolio. The biggest challenge is achieving the proper buy-in and committing to always resolve the resource conflicts.
Step four is to select a transition project in order to provide a picture for a sustainable operational model for the future operation. The selection of the right project is critical. This transition project, which is used as a just-in-time training vehicle, should provide a short-term win and provide momentum to achieve full implementation. It is with this transition project the team will develop the necessary detailed planning information to sustain an optimized multi-project system.
The team learns the techniques to properly develop deliverables and task network diagrams, conduct resource assignments, estimate durations, and refine and validate the project planning information that is necessary to support the decisions that enable a sustainably high level of system performance. This information is then entered into a project management information system that generates the necessary information so that the project can then be scheduled against the project priority list. Commitment dates for project completion are now able to be provided, if the organization is committed to removing multitasking, and it will meet or exceed its expectations.
The final step is to consolidate early wins and pursue the full implementation. Overall, the transition can take a full year. The gain in performance comes early. The cultural change that sustains it comes last.