Organizations have long struggled to reduce the uncertainties of new product development. Numerous knowledge sources have validated management's heightened attention to the truly debilitating costs of product slippages, launch failures and reduced market penetration. For example, a study by PRTM Inc. found that 70 percent of companies it surveyed were dissatisfied with their results in managing new product development (1).
Countless papers have been written on improving project execution, but relatively few provide guidance to executives trying to manage resource conflicts arising in multi-project environments. Enterprise resource planning (ERP) software and development chain management (DCM) tools are expensive, address broader business issues and do not provide much insight into this particular problem. Project management software (e.g., MS-Project) provides some capacity management tools, but is clumsy to use and not helpful in communicating results to operations management. In short, there are few tools or metrics associated with project portfolio management or development department utilization that are useful for real-time decision support.
Eliyahu Goldratt is generally credited with the mathematics and concepts behind the Theory of Constraints (2). His work describes how to optimize the performance of complex systems through management of critical constraints. This paper applies his techniques to a portfolio of engineering projects. It suggests metrics of development capacity and a capacity-modeling procedure that identifies both constraints and under-utilized assets. It discusses an interactive tool that evaluates different portfolio scenarios. Use of similar tools has reduced chronic planning miscalculations and improved the performance and predictability of engineering teams.
A development organization decomposes into collections of assets with differentiated skills and capabilities. (In this context, assets can be people or capital equipment). Some assets are dedicated to a single project while others are shared among multiple projects. But even people dedicated to a single project can have legacy responsibilities that can interrupt their focus and progress. Constraints are not static. Assets constrained during one time period may be different from assets constrained in another.
At the concept level, the Theory of Constraints describes a dynamic shown in Figure 1. For a multi-project development organization, increasing project load forms the X-axis and increasing results forms the Y-axis. At modest loads, the organization is under-utilized and the delivered results can linearly track increases in load. This relationship continues until the first constraint is reached. At this point the organization's ability to deliver results in additional projects begins to flatten. Somewhere near this point, the total delivered result peaks (arrow). If projects continue to be added, inefficiencies due to multitasking and inter-project interference occurs. More assets become saturated. Soon, delivered results decline. The Theory of Constraints demonstrates that the decline begins well before the 100 percent load point (represented by the dotted line).
[FIGURE 1 OMITTED]
A good analogy is a superhighway. The theoretical maximum traffic load on a multilane superhighway is greater than the actual sustainable traffic load. As traffic flow approaches the theoretical maximum, any driver touching his brakes, or slowing down, will result in the cars around him doing the same. This collective behavior creates traffic oscillations, i.e., variations in flow familiar to anyone who has driven in heavy traffic. The net sustainable volume flow stabilizes at a point well below the theoretical limit. If additional drivers attempt to enter the highway, the volume flow is further reduced.
The Theory of Constraints describes how to best attack a multiplicity of constraints. It requires management to focus on and break through the most constraining limitation. Until this is accomplished, effort spent on overcoming secondary constraints will yield no business benefit. These principles can be applied to managing a portfolio of projects in an organization facing constraints on its ability to perform the work.
A study of 205 companies by Cooper, Edgett and Kleinschmidt, found that many organizations "... have too many projects underway, given the level of resources. This explains, in part, why so many projects deliver behind schedule." They observed that metrics on project portfolio management were "... the weakest of six commonly used development measurements...." at these companies (3).
Other studies have noted that an organization's culture often drives development demands beyond the 100 percent point. Development managers frequently succumb to management pressure and over-commit their teams when just the opposite behavior may be called for. While counter-intuitive, organizations operating in the regions to the right of the arrow would achieve better results from 1) stopping work on some projects, or 2) delaying the start of new projects.
Most multi-project companies create development teams that include shared resources, frequently centralized services or areas of particular technical expertise that the project needs for a short period. Even engineers assigned fulltime to a new project are, in practice, part-time as they have residual responsibilities from previous programs. Project planners have long understood the need to "derate" the anticipated productivity of staff assigned to their project based upon other responsibilities. They also strive to compensate in their planning to account for shared resources that may not be available in a timely manner. Unfortunately, their visibility into upcoming conflicts is limited in organizations that do not manage the engineering project portfolio, so nasty surprises can occur despite their best efforts.
Untimely availability of an upstream resource can cause exponential degradation of a project, especially if critical path tasks are forced to spin their wheels. In a study of project postmortems conducted by the author's business unit at Motorola, untimely availability of assets was the third most frequently cited cause of schedule slippage (4). Other studies of project failures show a similar result.
As development organizations face increasing workloads, they begin to multi-task. Multi-tasking causes well-understood losses of effectiveness. Gerald Weinberg found that engineers multi-tasking across two simultaneous programs lose 20 percent of their effectiveness, and engineers multi-tasking across three simultaneous projects lose over 40 percent (5).
Loss of productivity and availability are not the only effects. Chronic overloading can cause team burnout, lack of competitiveness, increased turnover, and lower creativity. If new product development is one of the "engines" of the business, it is critical that it run effectively and creatively.
Current Portfolio Management Practices
There are two common practices used to manage development capacity. The first is closely linked to the corporate budgeting process and the second is done as part of the product development lifecycle. For different reasons, neither works especially well, particularly in fast-moving environments.
Well-managed organizations spend considerable effort during budget-setting time balancing their product portfolio strategy with their capacity for new product development. This effort has a financial focus, but it serves to test the affordability of the product strategy and the development tactics to be employed to achieve the desired results. The success of this effort varies, but in many cases falls short for one of the following reasons:
* Once-a-year evaluations may be too infrequent. Business conditions change, rendering planning assumptions obsolete, sometimes before the ink dries on the current plan.
* The evaluation doesn't fully consider engineering overhead activities. Because the planning has a revenue focus, the bulk of management's attention involves new revenue opportunities. Planning assumptions and set-asides for factory support, cost reduction, quality improvement, etc., are not scrutinized.
* Too many projects are priority ones; more granular development scenarios aren't considered. There may be more subtle scenarios where better results are delivered. If analyzing the scenarios is complex or time consuming, different approaches may not get evaluated properly.
* Constraints are not identified or challenged. Planning activities should identify constraints and workarounds suggested. A small change in constraints may yield dramatic improvements in performance.
The second common practice complements the budgeting process. It strives to manage development capacity in "real time" as part of the enterprise's product development lifecycle, for example, within a gated development process. A gated development process requires business go/no-go reviews at different points (gates) in a development life cycle. The purpose of the business review is to ensure the project continues to meet the corporate goals. In principle, this review ought to include project portfolio management decisions; in practice, there are systemic characteristics of gated development processes that make them relatively ineffective in managing capacity:
* Gated development reviews are performed serially, one project at a time. Evaluating a project's interaction with other projects requires a parallel perspective.
* Gated development reviews are not usually conducted for overhead projects and activities. Because such efforts do not generate revenue, customary business justifications are less useful in deciding their merits. Senior sales and marketing management executives rarely get go/no-go votes into these efforts.
If resource capacity is not rigorously considered in gate reviews, more projects tend to be commissioned than the organization can execute efficiently. The gated development process becomes part of the over-load problem rather than part of the solution.
PRTM has found that gated development reviews often degenerate into a process checklist verification exercise rather than an activity that drives business tradeoffs. Analyzing and making portfolio decisions takes more time and focus than project gate reviewers can afford. Often the individuals most capable of making the portfolio tradeoffs are not the same people as the executives conducting the project gate review.
Project portfolio management requires a blending of sales, marketing and engineering strategies and tactics. It is best accomplished using scenario analysis and visualization models. Good visual models can reduce complex system behaviors to relationships more easily understood by practitioners and executives. Interactive visual models are helpful in evaluating one scenario versus another.
For any portfolio of projects there are many reasonable implementation scenarios. Having an effective visualization model allows scenarios to be more easily evaluated. An easy-to-understand model allows non-development groups to bring different expertise into the analysis. These groups benefit directly by gaining greater insight into constraints in the development chain. As a result, team decisions are better thought out and better understood by the organization.
A well-built portfolio management model makes all key management "levers" available to scenario builders. "What-if" questions can be rapidly analyzed and further refinements tried. The model must support all types of projects (revenue producing and non-revenue producing) as well as overhead activities that reduce the throughput of product development. The model should drive explicit decisions on project priorities as well as changes in staffing; it should clearly identify key constraints.
The model described below uses both color and geometry to represent the results of a given scenario. Color indicates the availability of assets to meet a project's needs, and the geometry represents the degree to which the utilization of asset types is balanced across asset categories. Simple models can be built quickly with standard Excel conditional formatting capabilities, while more sophisticated models require custom macros, Visual Basic for Applications (VBA) coding and more development time. The models presented below illustrate that key insights can be gained from simple capacity views of a portfolio.
Figure 2 presents a traditional (and simplified) schedule view of a project portfolio. This summary view might be developed during a yearly planning effort. It shows two engineering projects underway in the current year, both extending into the upcoming year. One of these projects (project B) will complete in quarter one, and three new projects will start (projects C, D and E). The end dates suggest times when incremental revenue might be obtained.
[FIGURE 2 OMITTED]
The schedule-oriented view, useful for financial planning purposes, is ineffective in representing the operational constraints occurring with engineering. This view may not include all activities underway within development, for example, training, factory support, etc. It does not describe whether each project is fully staffed and running at full speed, or whether non-revenue considerations were important in creating the mix of projects. In contrast, a capacity management view focuses on one particular time period and more deeply examines project and resource dynamics. For the sake of discussion, Figures 3 and 4 (again, simplified) depict the potential development activity being considered in the upcoming first quarter.
[FIGURES 3-4 OMITTED]
Development assets form the spreadsheet columns. The amount of the asset (headcount) on hand, and the units of capacity are shown beneath the heading. The units can be in staff-days, staff-weeks, machine-hours, etc. Each project consumes a spreadsheet row. The project's need for resources during the quarter is numerically characterized in the intersecting column and row cell. The project's hierarchy in the spreadsheet represents the project's business priority to the company. The gray background represents when the available resources run out or when a project is constrained. The geometry formed by the gray color's edge represents the asset utilization balance across the asset types. A flat geometry represents even utilization while a hilly geometry represents an uneven utilization. Scenarios that have flatter geometries represent a better workload-balanced organization.
Applying the model to the project portfolio described in Figure 2 yields the first scenario, Figure 3. This view shows more details of the pressures and constraints faced in the first quarter. For instance, the on-going demands of projects A and B consume much of the quarter's resources. Projects C, D and E do not commence cleanly.
They face constraints in four different resource groups (App, CAD, SQA and Doc). Projects F-J make no progress during the quarter. They may be very desirable projects, but the resources are virtually fully consumed with higher priorities.
Figure 3 may not represent an acceptable implementation of the enterprise's first-quarter plans. As much as senior management may desire, projects C, D and E cannot be fully supported without some change in constraints. Planners might question how the scenario could be improved with a different set of development tactics. The view clearly shows the organization's most critical constraints, and other constraints likely to limit the results of alternative scenarios. The hilly geometry indicates a degree of underutilization of total assets. Planners might investigate the following alternatives:
* Hire additional resources.
* Shift resources from one group into a constrained group.
* Maintain the project hierarchy and resources, and adjust the project plans and schedules to account for delayed ramp-up's of projects C, D and E.
* De-prioritize project C below projects D and E.
The last alternative is depicted in Figure 4. It shows that projects D and E are now able to start up cleanly. Project C is de-prioritized and would receive little attention during quarter one. The resulting geometry is considerably flatter. Based solely on capacity considerations, this scenario might represent a better operating plan for the first quarter. To decide, the full business implications must be evaluated.
The analysis of scenarios and their business-wide implications is an activity that must involve sales, marketing and engineering (and may involve manufacturing, service and finance). While "real life" scenarios are considerably more complex than this example, one can observe how the capacity management model provides a comprehensive view, enabling all functional groups to meet and discuss alternatives.
Beyond identifying constraints and workarounds, a project portfolio management process can reveal other important dynamics. For example, the level of resources being consumed by poor product quality, or customer support and factory support expenditures, is often a shock to executives. Discovering that a high-priority project is not fully staffed or that "urgent activities" (marketing support, factory optimizations, sales support, etc.) are getting in the way of important "strategic developments" can be an ugly surprise. The good news is that once the surprises are brought to light, decisions to change tactics can gain traction and executive support.
Also, project portfolio management results can provide crucial guidance to project managers in improving the predictability of their project plans. Rather than assuming the availability of shared resources, they can create schedules and contingencies that better represent reality. For on-going projects that are not fully funded in a planning period, astute project managers can sometimes recover schedule in later periods, especially if the critical path is not impacted.
Distributed Capacity Management
A portfolio management process is highly cross-functional and typically led by the senior operations manager. It is a comparative, scenario-based process intended to drive resolution of constraints and priority conflicts. It serves to validate that plans and tactics employed are consistent and achievable.
The iterative/scenario-based method can be challenging to manage. Hundreds of different scenarios might exist. Subject matter experts might be better able to analyze alternatives than functional managers. For efficiency, one would prefer to decentralize analysis, with conflicts resolved centrally. Most project tradeoffs are straightforward and can be made in a rapid manner. But some represent boundary conditions or cross-group constraints that require a focused, efficient and rapid resolution method. This is where senior management attention should be most valuable.
Project portfolio management is a "zero-based" activity. For each iteration, projects must re-establish their value and importance relative to every other existing or proposed new project. The model forces a project prioritization to take place. Getting multiple product-line managers or business-unit general managers to agree on a business-wide prioritization is challenging, but, once done, proves highly valuable to the organization.
While the process is being executed, it is intense and consuming. Because the process evaluates the entire portfolio, it can involve many in middle management and most of the company's subject matter experts.
The process should be run at regular intervals--Nannually for some companies, quarterly for others. The need for efficiency is particularly important the more frequently it runs.
Executing the capacity management process in larger organizations frequently requires employment of loosely coupled teams, each expert in their particular market segment or product set. When the process is driven in this distributed, rather than centralized, manner it facilitates execution speed and precision. But these benefits can be jeopardized if the teams base their decisions on inconsistent assumptions. To compensate, the senior operations manager should provide extensive starting guidance to the process participants. This guidance should eliminate impractical scenarios from consideration and establish global common assumptions, for example, hiring allowances, permissible assets movement during the planning period, and non-negotiable activities and projects.
A distributed process requires distributed team leadership. Because both technology and business experts may be involved, it is important to avoid conflicts of interest. The team leader has a full-time job elsewhere. The fulltime accountabilities should not color the portfolio management decisions being made. If these issues cannot be controlled, a different leader would be a better choice.
Another pitfall to avoid is biased effort estimations. Estimation inaccuracy can arise from honest differences among engineers, or from more insidious behavior arising from personal agendas. Such behavior could impact the integrity of the capacity planning process. Having estimates reviewed by subject-matter experts and senior staff reduces the likelihood of bias. Comparing estimates to alternate sources of project data is another mitigation.
Bias in the form of "pet projects" or protected activities can distort the project rankings. To the extent possible, objective business criteria should drive the project priorities. If both the objective criteria and the resulting rankings are reviewed with sales management and senior executives, the impact of bias can be mitigated.
Team leaders must also recognize when a scenario is "close enough." Understanding the point of diminishing returns takes experience. Different team leaders will frequently disagree on when this occurs. Thus, during the first few cycles, the senior manager must monitor this dynamic closely. Enforcing a deadline drives conclusions that are probably "close enough."
Once the planning cycle is concluded, implementation can proceed with confidence in the project's priority and resources. The plan of record should be frozen and new projects and scenarios placed in a queue for consideration during the next planning period. If a new idea requires immediate attention, the interactive model allows for quick evaluation of the proposed idea's impact on the projects already underway.
Deciding to absorb new projects into the existing portfolio of work injects new risks and inefficiencies but is sometimes necessary. If this occurs frequently, management should shorten the planning period and increase the frequency of the process.
Finally, at the start of the next capacity management planning cycle, it is useful to critique the most recent plan against what was actually accomplished. Organizational learning can make subsequent cycles more effective, efficient and timely.
Bottom Line Benefits
1. Accountability.--At the conclusion of the process, the operations team has converged on a plan that has been measured and modeled against other potential scenarios and represents a well-considered set of business tradeoffs. Multiple groups have participated in the plan's generation and the results have been communicated to senior management. If adhered to, project slippages due to unplanned resource constraints should be virtually eliminated.
2. Synchronization of the organization.--The organization has bought into the portfolio of projects and understands the constraints that drove the decisions. All groups understand the relative priority of each project and which projects are not to be addressed.
3. Residual constraints are accepted by the organization.--Executives understand the remaining constraints and will avoid commissioning new projects that overstress these assets.
4. Planning documentation can be reviewed at the beginning of the next cycle.--The team can measure its achievements versus the plan and evaluate ideas for continuous improvement.
1. PRTM Management Journal for Technology Driven Companies; Spring/Summer 2002, p. 25.
2. Goldratt, Eliyahu M. The Importance of System Constraints. The Theory of Constraints Journal Vol. 1, No. 4, Feb-March 1989. Avraham Y. Goldratt Institute, New Haven, CT.
3. Cooper, Robert G., Edgett, Scott J. and Kleinschmidt, Elko J. Best Practices for Managing R&D Portfolios. Research-Technology Management, July-August 1998, pp. 20-33.
4. Seider, Ross. Project Portfolio Management: Presentation to Product Development Management Association (PDMA-Boston); October 2004.
5. Weinberg, Gerald. Quality Systems Management. Dorset House, 1992.
Ross Seider is president of On-Fire Associates, a Needham, Massachusetts, executive management consultancy that focuses on engineering execution. Prior to that he was vice president-product development and network operations for Akamai Technology. Earlier, he was a co-founder and engineering vice president of two networking start-ups, and spent 12 years at Motorola in a variety of executive roles. He received his B.S.E.E. from Rensselaer Polytechnic Institute and M.B.A. from Northeastern University. firstname.lastname@example.org