Implementing TOC multiproject management in a research organization
Jeffery A. Fenbert, Boeing Commercial Airplane Company
Nancy K. Fleener, Boeing Commercial Airplane Company
Planning and scheduling of research projects has often been characterized as difficult due to the nature of research. Estimates of task lengths based on past experience are not necessarily accurate if tasks are performed in a new way during the innovation process. These difficulties have lead many research organizations to the conclusion that project management tools that make comparisons with plans and schedules can be largely irrelevant to the process of managing innovation (Mills 2000). The Manufacturing Research and Development organization in the Boeing Commercial Airplane company had long received feedback from customers that although they were happy with the quality of the products, they often took too long to deliver and were often late.
Multiple attempts to improve the internal project management process had been implemented over the years, but none had established themselves as a clear winner for the organization and gained widespread use. Using Theory of Constraints (TOC) sufficiency-based logic (Detmer 1997) a current reality tree of the organization was constructed, which pointed toward two potential root causes for the lack of predictability and speed: the lack of consistent project management processes and poor visibility of project status and resource loading using traditional organizational project management methods. The senior manager of the organization had studied the success of Critical Chain Project Management (CCPM) in product development organizations (Sabin 2000) and initiated a pilot of CCPM in May 2000. The stated goal of the implementation was to increase the speed and end-date predictability of projects while maintaining the quality of work.
Critical Chain Project Management is a systems approach to project management based on the TOC that changes the way dependent events, uncertainty, and risks are managed in project organizations. The use of CCPM and other TOC concepts in a multiproject environment is called TOC Multiproject Management (TOC/MPM). Goldratt first introduced the concepts of CCPM in his book Critical Chain in 1997. This paper summarizes the approach taken and results achieved with the application of TOC/MPM in the chemical research organization of manufacturing research and development (MR&D) in the Boeing Commercial Airplane Company. Since the details of CCPM have been well established in the literature (Patrick 1999; Cook 1998; Newbold 1998; Leach 1999) the details will not be covered in this paper. We will highlight three key aspects of the methodology that were utilized for application in the organization: project end date predictability, modified scheduling algorithm, and balancing resources across multiple projects.
Project End Date Predictability
All projects are subject to variation in task durations and this variation often results in projects taking longer to complete than scheduled. Since this has long been realized the smart project manager is encouraged to ensure there is some slack in the schedule if they hope to deliver the project on time (Meredith 1995). For the purpose of this paper, this slack time will be defined as the project buffer and represent the amount of time from the last scheduled event in the project to the project commitment date. If a buffer is to be used on a project, two considerations need to be understood: how large should the buffer be and how should it be represented in the project schedule.
In many environments the amount of buffer is based on an organization standard or established based on the experience of the project manager. Most commonly the buffer is labeled as management reserve and is to provide protection from “unknown unknowns.” Generally this reserve is managed by the project manager and not given to the team (Meredith 1995; Fleming 1996). It can also be added as a last task in the project network (Wysocki 2000).
Another method that has gained in popularity is the use of Monte Carlo simulations. In this method, variation is assigned to each task in the project network and then the project is simulated a large number of times to establish a range of project finishes and probability (Huelett 1996, 2000; Graves 2001). This results in a probability distribution of potential end dates. This information can be used to negotiate with the customer on the contractual end date as well as identify areas of the project that may require special attention during execution of the project. Many Monte Carlo simulation packages do not consider resource constraints, which can lead to a more optimistic prediction than methods that account for resources.
Exhibit1. Sample Critical Chain Project File
Critical Chain Project Management uses a statistical methodology based on analysis of technical as well as resource dependency in combination with an average and safe estimate for each task to establish the project buffer (Newbold 1998). Typically, the end of the project buffer represents the 95 percent chance of finishing on time and the start of the buffer represents the 50 percent chance of finishing on time depending on the complexity of the network. The critical chain is defined as the longest path in the project considering both resource and technical dependency simultaneously.
For purposes of illustration, Exhibit 1 shows a typical critical chain schedule generated using Microsoft® Project® supplemented by Prochain® software. Feeding buffers are omitted for clarity.
Once the size of the buffer has been established, a determination must be made on how to incorporate it into the project plan. The best option for use of the project buffer is as a management tool to help manage the project. If this is to be accomplished, an organization must overcome the accepted paradigm that if time is available it will not be used to protect the project, but be absorbed due to Parkinson's Law. The CCPM methodology uses the idea of buffer management. As the project progresses, a comparison of buffer used to work accomplished can be used to gauge the health of a project. A typical display used in many applications is shown below in Exhibit 2. Comparing buffer usage across multiple projects helps in program or portfolio management to quickly gauge the health of a series of project relative to each other, which allows the management team to focus their help in the most critical areas.
Use of the buffer as a management tool is not restricted to the CCPM methodology but also can be used in conjunction with traditional Critical Path scheduling (Winslow 2001). The key aspect to making a buffer system work, regardless of methodology chosen, is the switch from milestone driven behavior to event driven behavior.
For the application in MR&D, Prochain software with Microsoft Project was used. The size of the buffers was calculated using the both the root mean square and percent of chain methods (Prochain 1999). Each week, a report comparing the buffer status of all projects was complied and reviewed by the management team.
Modified Scheduling Algorithm
In the Critical Path Method, technical dependency always takes precedence when generating a schedule. Resource leveling is accomplished by utilizing available slack on tasks so as not to impact the project end date. Since the heuristics used by applications are not optimized in all applications (Herroelen 2000), resource leveling often is done manually on a task-by-task basis. This necessitates the use of highly skilled schedulers and a significant time investment that many organizations cannot afford to make. This also continues the pursuit of the optimum schedule which when variation is taken into account is not a feasible schedule. Often the goal of resource leveling is to smooth out the resource use across the project. The practical result of this approach is to greatly increase the merge bias due to increasing the number of near critical chains of events. This will lead to increased schedule delays in the project that will lead to an increased need to reschedule the project.
According to A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Section 126.96.36.199, Critical Chain “is a technique that modifies the project schedule to account for limited resources.” By balancing the resources, it makes schedules that are achievable. In addition using critical chain is a method that is simple and can be taught to project staff in a relatively short time. This leads to the ability to be used widely in an organization (Styrn 2001).
Research environments are highly dynamic; a tool that could easily incorporate changes to the networks and regenerate impacts to the buffer was vital for effective use in the MR&D organization. As with many organizations, project management is part of the duties of the lead technical resources and therefore time to develop highly skilled abilities to perform manual balancing of resources is not practical. Prior to implementation, many projects established the outline of a plan, but it was not updated regularly as is typical in many research organizations (Mills 2000). Implementation of TOC/MPM allowed weekly updates and quick analysis of which task was most impacting the buffer at any point in time.
Resource Leveling across Multiple Projects
The difficulties in establishing credible schedules due to variation and resource constraints are compounded in multiple project environments. Traditional techniques that attempt to optimize use of all resources in a system will result in less credibility in the project schedules. This will also lead to continuous rescheduling. TOC proposes that every system is constrained from reaching its goal by one or very few constraints. As applied to project management that means we can pace the input of projects by identifying one or few key resources and loading the system at the level they can accomplish work. This approach is known as the drum solution (Newbold 1998).
In a research environment it is expected that many more projects will be started than will be completed. Ideas that show promise will generate projects that may end up being stopped much earlier than planned or generate new paths that were not anticipated. This can result in large changes in the load on resources across the system on an ongoing basis. A unique aspect of the system under study is that there was not one clear drum for the entire system, but an intertwined set of projects. The simplified application of CCPM allowed an analysis to be completed any time a new project was started to understand if the resources under consideration were heavily or lightly loaded at the time. Another benefit was that the start date of many projects were delayed and added to the project portfolio to start at a later date. In the past these projects would have been started as soon as the request came in and drained resources from the higher priority work.
Exhibit 2. Sample Project Status Chart
To take advantage of these identified improvements; two additional changes need to be made in the system. Implementation of a deliverables based planning process and defining of approaches to interative work.
Deliverables-Based Planning Process
A deliverables-based planning process based on materials and training from the Product Development Institute (Rizzo 1999) was used in the planning of the projects. The concept behind this process is to plan backwards from the end point and capture both inputs and outputs as you move through the project network. Implementation of this method identified the need for a well-defined goal and deliverables and a clear vision of the path to the deliverables at the beginning of the process to produce a realistic schedule in the end. The deliverables-based planning process helped to:
1. Keep a focus on only elements that are required to produce the next deliverable in the chain.
2. Prevent planning and executing of work that does not support the goals of the project.
3. Capture tasks that might otherwise be missed if using a less thorough method.
4. Produce schedules that were of sufficient detail to effectively track status and evaluate causes for slides.
Establishing high quality networks is a requirement for use of the critical chain software. By instituting this process it helped us take advantage of the improved scheduling methodology while simultaneously improving the project management practices.
Exhibit 3. Project Statistics
Approaches to Iterative Work
Long Range Projects
Many of the development projects conducted in the MR&D organization have a life cycle of 2–5 years to implementation. Traditionally, there would be one schedule developed at a high level to capture this amount of work. However, as stated above, in order to effectively use the deliverables-based planning process one must have clear deliverables and a relatively clear vision of how to get to those deliverables. Typically this relatively clear vision breaks down to 6–9 month phases. Using the improved planning process, as each phase was completed, a detailed plan was developed for the next phase. The shortcoming of this system, as it is now implemented, is it lacks visibility of the resource-need for the whole development life cycle as well as the path to the ultimate deliverable.
Unknown Arrival Rate for Test Products
Some project phases consisted of analyzing products submitted by vendors. The difficulty lies in the fact that the rate at which materials will be submitted to MR&D by the vendors is unknown; however, the work to be performed when the material arrived was well defined and easy to schedule. If a project of this type was deemed as the highest priority, time was set-aside in the resource loading for the resources that would be required. When a material arrived, a short-term (1–2 month) project was loaded into the multiproject system. Adjustments could be made to the schedules for the lower priority projects as required. If fewer materials arrived than anticipated, the lower priority project could be finished sooner than promised. The success of this method depended partly on the scheduling of project tasks defining upfront coordination effort and an interim or final reporting effort, out 6–12 months to set aside resources and to provide ongoing visibility to the effort even when a testing phase is not in process.
Unknown Number of Iterations
Testing of a new material (or process) may first consist of running a series of tests to identify a repeatable procedure. This is followed by a series of tests to performance requirements, using the newly defined procedure, of the new material. In these cases, the number of iterations required for both of the test series was unknown. This type of project was planned by defining a task set for each iteration and then putting in a best guess estimate of the number of iterations. Based on the judged risk to the project, the buffers could be made larger to cover increases in the numbers of iterations.
Unknown Technology to Be Evaluated
The last special case deals with not knowing which technologies might be tested to solve a particular manufacturing problem. Often, in the project definition phase of an effort, customer input provides clear direction to evaluate known technologies that represent low-hanging fruit (easily tested and implemented, currently approved or available) but there is also direction from the customer to perform a literature review for newer/better technologies, and viable options tested along with the clearly defined options. For these projects, one of the early tasks would be to determine what new technologies might work best. Since, when the project is planned and scheduled, the new viable options have not yet been identified, the alternative used was to schedule the known entities and place holder tasks in the project. The holder tasks were similar to evaluation of the clearly defined options, with longer durations, due to the risk associated with the uncertainty. After the initial analysis was conducted, task details were added to the project schedule and adjustments in execution were made as required.
Results and Lessons Learned
By employing the techniques described based on the TOC/MPM method, the organization has been able to demonstrate an improved ability to predict project outcomes. Exhibit 3 shows a summary of the project completion times versus the estimated times to complete. Prior to the system being implemented, consistent records were not kept for on-time completion of projects. Based on a survey of people in the organization, the on time rate was estimated from 20–50 percent. That number has been raised to above 70 percent based on the first sixteen projects completed.
In addition to the improved on time performance, the organization has experienced many of the qualitative benefits that can be expected from an implementation of critical chain project management. Improved communication between supervisors and engineers and a better understanding of where to focus efforts on projects to maintain progress were sited as two key improvements. In addition many engineers have realized the positive benefits of having a plan that can help guide the daily decision making process.
Improvements in the system cannot be traced exclusively to the implementation of a new planning and scheduling methodology. This paper primary discussed technical changes that were made to processes in the system. Of equal importance were the changes in behavior required to support the new system. Without increased discipline in building plans and working to the priorities the improved results could not have been realized. For the application of CCPM (or any project management system) to be effective it must be implemented as a system incorporating the key aspects of the technical solution along with key changes in behavior.
Cook, Stephen. (1998). Applying Critical Chain to Improve the Management of Uncertainty in Projects. Boston, MA: Massachusetts Institute of Technology.
Dettmer, H. William. (1997). Goldratt's Theory of Constraints—A Systems Approach to Continuous Improvement. Milwaukee, WI: ASQ Quality Press.
Fleming, and Koppelman. (1996). Earned Value Project Management. Newton Square, PA: Project Management Institute.
Goldratt, Eliyahum. (1997). Critical Chain. Great Barrington, MA: The North River Press.
Graves, Roger. (2001, December). Open and closed: The Monte Carlo model. PM Network 15: 50–52.
Herroelen, and Lues. (2000). On the merits and pitfalls of Critical Chain schedules. Proceedings of PMI Research Conference 2000: 283–296.
Hulett, David. (1996, July). Schedule risk simplified. PM Network 10: 23–30.
______. (2000, February). Project schedule risk analysis: Monte Carlo Simulation or PERT? PM Network 14: 43–48.
Leach, Lawrence. (2000). Critical Chain Project Management. Artech House, Inc.
Meredith, and Mantel. (1995). Project Management—A Managerial Approach. John Wiley and Sons, Inc.
Mills, Langdon, Kirk, and Swan. (2000). Managing technological Innovation projects: The quest for a universal language. Proceedings of PMI Research Conference 2000: 375–384.
Newbold, Robert. (1998). Project Management in the Fast Lane—Applying the Theory of Constraints. St. Lucie Press.
Patrick, Frank. (1999, April). Getting out from between Parkinson's rock and Murphy's hard place. PM Network 13: 57–62.
Prochain Inc. (1999). Prochain Users Guide. Prochain Solutions, Inc.
Project Management Institute. (2000). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – 2000 Edition. Newtown Square, PA: Project Management Institute.
Rizzo, Anthony. (1999). Building Useful Project Plans. Whippany, NJ: The Product Development Institute.
Steyn, Herman. (2001, August). An investigation into the fundamentals of Critical Chain project scheduling. International Journal of Project Management 19: 363–369.
Winslow, Stephen. (2001, June). Giving critical path the attention it deserves. PM Network 15: 54–57.
Wysociki, Beck, and Crane. (2000). Effective Project Management. John Wiley and Sons, Inc.