6. Continue the cycle into the future.

CORE is a process for selling change that addresses the root causes by building trust in the change initiative over time. The ProChain experience indicates that the combination of CORE and best-in-class solution components results in successful and long-lasting implementations.

The CORE feedback cycle can be applied to simple and complex situations. Some associated traps can be avoided by transferring ownership of the implementation, creating realistic expectations, and acknowledging the fact that some implementation tasks will never be completely "done."

Ability to change quickly-"agility"-can be a tremendous competitive advantage. For an organization to be truly agile, it must be able to respond rapidly to changes in markets and technologies. In order to make appropriate changes that stick, its people must have the patience, discipline, and flexibility to build trust in those changes. CORE is an important tool to build that trust.

References

Cialdini, R. B. 1993. Influence: The Psychology of Persuasion. New York: William Morrow and Company.

Covey, S. R. 1989. The Seven Habits of Highly Effective People. New York: Simon and Schuster.

Deming, W. E. 1982. Out of the Crisis. Cambridge: MIT CAES.

Eades, K. M. 2004. The New Solution Selling. New York: McGraw Hill.

Dettmer, H. W. 2007. The Logical Thinking Process: A Systems Approach to Complex Problem Solving. Milwaukee, WI: ASQ Quality Press.

Duck, J. D. 2001. The Change Monster. New York: Three Rivers Press.

Goldratt, E. M. 1990. What Is This Thing Called Theory Of Constraints, and How Should It Be Implemented? Great Barrington, MA: North River Press.

Goldratt, E. M., Goldratt, R., and Abramov, E. 2002. Strategy and tactics. http://www.vancouver.wsu.edu/fac/holt/em534/Goldratt/Strategic-Tactic.html.

Gupta, S. 2005. Critical Chain: Successes, failures, and lessons learned. Presentation at the 3rd Annual TOCICO Conference, November 2005, Barcelona, Spain.

Hobbs, B. and Aubry, M. 2006. Identifying the structure that underlies the extreme variability found among PMOs. Newtown Square, PA: Project Management Institute Research Conference.

Koenigsaecker, G. 2009. Leading the Lean Enterprise Transformation. New York: Productivity Press.

Kotter, J. P. 1996. Leading Change. Boston: Harvard Business School Press.

Kotter, J. P. 2008. A Sense of Urgency. Boston: Harvard Business School Press.

Lean Enterprise Institute. 2008. Backsliding is back as the biggest obstacle to lean transformations. http://www.lean.org/WhoWeAre/NewsArticleDocuments/Obstacles_adden_dum_release08.pdf.

Lewin, K. 1997. Resolving Social Conflicts and Field Theory in Social Science. Washington, DC: American Psychological Association.

Newbold, R. C. 1998. Project Management in the Fast Lane: Applying the Theory of Constraints. Boca Raton, FL: St. Lucie Press.

Newbold, R. C. 2008. The Billion Dollar Solution: Secrets of ProChain Project Management. Lake Ridge, VA: ProChain Press.

Project Management Institute. 2008. A Guide to the Project Management Body of Knowledge. 4th ed. Newtown Square, PA: Project Management Institute.

Retief, F. 2009. Critical Chain vs. Pooled risk scheduling. See http://www.mpsys.com.au/downloads for download information.

Richards, C. 2004. Certain to Win: The Strategy of John Boyd, Applied to Business. Philadelphia: XLibris Corporation.

Scheinkopf, L. 2000. Thinking for a Change. Boca Raton, FL: St. Lucie Press.

Sullivan, T. T., Reid, R. A., and Cartier, B. 2007. TOCICO Dictionary. http://www.tocico.org/? page=dictionary.

About the Author.

Robert C. Newbold, CEO and founder of ProChain Solutions, is one of the world's leading experts on project scheduling and management using the Critical Chain approach. Rob is a frequent writer and speaker on the subject of project management. Over the past 25 years he has developed process improvements in the fields of health care, manufacturing, and project management. He is the author of The Billion Dollar Solution (2008) from ProChain Press and Project Management in the Fast Lane (1998) from St. Lucie Press, and holds degrees from Stanford University, State University of New York (SUNY), Stony Brook, and Yale University.

CHAPTER 6.

Project Management in a Lean World-Translating Lean Six Sigma (LSS) into the Project Environment

AGI-Goldratt Institute

Introduction: It's a Lean World

For most large organizations in the Western Hemisphere, the call to pursue a discipline of improvement began with the 1980s NBC broadcast of "If Japan can . . . Why can't we?" Many embarked on the quality movement of putting human and financial resources toward that commitment. Investing in training from Dr. Edward W. Deming, Dr. Taiichi Ohno, and Shingeo Shingo as well as juggling the onslaught of new training and consulting organizations that emerged, the mid to late 1980s saw the introduction of a myriad of techniques-most seeming to have a three-letter acronym. Whether it was SPC (Statistical Process Control), TPS (Toyota Production System), SMED (Single Method Exchange of Die), JIT (Just-in-Time), or TPM (Total Productive Maintenance), external and internal experts with different techniques descended upon the business units to form numerous Process Improvement Teams, all competing for the same resources that were already fully needed just to run the business.

Motorola is credited with the invention of the Six Sigma methodology. Those inside Motorola saw the power of the various techniques from TQM, Deming, Juran, and others and evolved them to a management system that was focused on improvement and the bottom line. First aimed at processes within manufacturing, Motorola then developed the elements to embed it within their operating culture.

Thanks to James Womack and Daniel Jones through their book, Lean Thinking (1996), the tools of the quality movement now had a framework to work more collectively-the Lean Principles. The principles of specifying value and the value stream, creating smooth flow, and enabling the customer to pull value and the pursuit of perfection ensured the process of improvement would be ongoing. (For a good synopsis of Lean and Six Sigma methodologies, please refer to Chapter 36, "Combining Lean, Six Sigma, and the Theory of Constraints to Achieve Breakthrough Performance by AGI-Goldratt Institute").

Both Lean and Six Sigma continue to be heavily embraced by the private and public sectors and have become more and more integrated as Lean Six Sigma (LSS). Both are well developed. Both enjoy the support of many top executives, line managers, and vast numbers of employees who have been trained to one degree or another in these disciplines. Let's face it, for most of us it is a Lean world!

What implication does this have on the project environment? The attention on Lean Six Sigma continues to grow. There are whole offices and departments set up for LSS. Funding availability seems plentiful in relationship to other needs. There are growing numbers of experts in LSS from white belts to green belts to black belts. These many experts and efforts all result in a broadening of the application of LSS from the shop floor to the whole organization-including the project environment!

What Is the Project Environment's Point of View to Being Leaned?

As the LSS efforts broadened into the project environment, there was less than an enthusiastic greeting. Most project managers and resource managers felt that they were already working in a pretty lean world-lean on resources, lean on time, and lean on funding. Many project managers felt that they were already asked to do the near impossible-sit on top of an elephant balancing on a ball on a high wire 20 feet in the air without a net (Fig. 6-1).

FIGURE 6-1 PM's point of view. (19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.) In trying to "lean" the project environment, there have been a few seemingly insurmountable obstacles. To begin with, like supply chain environments, project environments are made up of a system of systems. This increases the difficulty of deciding not only where to focus but also how to determine the most opportune areas of waste and value. Additionally, when applying definitions and techniques for improving the areas of productivity, focus, value, waste, and variation to a project-based system, there appear to be disconnects as LSS's techniques and definitions were developed for the manufacturing environment and appeared to not readily apply to the project environment without significant translation. Couple that with the fact that traditional project management techniques contained in the project management body of knowledge (PMBOK) have not necessarily integrated Lean. No wonder there has been a lukewarm if not cool reception. Let us look at these issues more thoroughly one at a time.

Project Environment System of Systems

There are four systems within a multi-project environment. They are the task management system, the individual project system, the portfolio of projects system, and the resource management system.

The task management system (Fig. 6-2) consists of the list of tasks or group of interrelated tasks where a person is responsible for ensuring that all the elements for that task are completed by the scheduled date (and often within the cost estimated).

The detail under the "task" does not generally show up in the project schedule, only the overall task. If one were building a house, this task might be called "complete electrical wiring." The crew chief would have one electrical crew to oversee pulling 110-volt wiring to lights and outlets; another perhaps running 220-volt wiring for some appliances; and another setting up the electrical panel.

FIGURE 6-2 Task management system. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

FIGURE 6-3 Project environment. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

The individual project system consists of the sequence of tasks, handoffs, and deliverables that when accomplished deliver the desired outcome. The individual project system must manage the delivery of content within a committed time and budget. Very often, scheduling begins with the various resource functions listing their tasks and time (or level of effort) as stand-alone elements (Fig. 6-3).

The individual project content commitments are made independently of other projects' task work for shared resources. Even when shared resourcing is considered, little notice is given to the impact of variability on the releasing of a resource from one task to another. In addition, where project-to-project dependency exists, often project commitments are made without consideration of the impact of variability of one project on another. An example might be when the organization is developing a project where the output would be used by another or several other projects, such as the development of a new microprocessor that will be utilized in each successive product platform.

At the portfolio of projects level system, all the projects are grouped by product type, business type, or organization type and must be managed to ensure that each customer is satisfied. Unfortunately, the need dates of the customers are independent and are not necessarily able to be coordinated across a portfolio (Fig. 6-4).

At this level, conflicts between projects for limited shared resources become more visible. Unfortunately, there are often compromises made-which projects will be given higher priority for resources versus others, and many projects struggle as they have to manage without the benefit of being the "hot" project.

Finally, at the resource management level, the organization needs not only to plan what capacities they must have to support current and future project work, but also handle how to deploy the current resources to the queue of the tasks for each project-each with a project and/or portfolio priority. The managers of this system constantly juggle the capacity available and task execution priorities (Fig. 6-5).

The resource manager is often put into the position of switching resources back and forth to the new squeakiest wheel (task), trying to spread the capacity where it might do the most good against a seemingly never-ending queue.

FIGURE 6-4 Multi-project environment. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

What Do We Improve?

With all these different systems and owners, it appears that approaching system improvement in project environments is like the "The Blind Men and the Elephant," the Indian fable immortalized in the poem by John Godfrey Saxe (1873, 7778) Project management system improvement has some interesting challenges. There are many owners of these different "systems," each with their own view of what needs to improve. As long as these systems are not aligned to work in concert, there will be little opportunity for real improvement. This means that the relationships between these systems need to be understood. Ultimately, the capacity of the organization (either based on its limited capacity resources or the amount of a type of work that be can be taken on in a window of time) should dictate how much work is accepted in the portfolio or pipeline. Only then can individual project commitments be made. Task priorities then should be based on this release of work and the actual availability of "ready to work" tasks. Adjustments should only be made to task list priorities when there is objective data that the project require for the task to be expedited. The key to improvement is this alignment of these systems of systems and, with this understanding, translating Lean Six Sigma to drive value, minimizes waste.

Translating Lean into the Project System of Systems for Improvement

Lean manufacturing could be summarized by what has been attributed to Eiji Toyoda in describing a pillar of the Toyota Production System: "providing exactly what the customer wants; when the customer needs it; in the correct quantity and in the expected sequence, without defects; at the lowest possible cost." We must consider the importance of this concept, but apply it to each of the system of systems in a project environment in a way that aligns the system.

FIGURE 6-5 Multi-project resource management. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

In a multi-project environment, we start by aligning the system of systems with the capacity of the organization and the portfolio of work. Lean would mean taking on the right quantity of projects, based on the organization's capacity to do work (within a window of time), with the correct content, as quickly as possible to meet each project's needed commitment date. For those projects that are agreed to be taken on by the portfolio, Lean would mean accomplishing the right tasks, in the right sequence, with the correct quality, as quickly as possible to deliver exactly what the customer wants, when the customer needs it. From there, Lean as applied to the task priorities would translate as having the right tasks assigned, in the right sequence, utilizing the correct resources. Next, Lean Task Management would mean ensuring that the right tasks are executed, at the right time, delivering the correct content with the correct quality, as quickly as possible (Fig. 6-6).

FIGURE 6-6 Aligning the systems in a project environment. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

Addressing the Disconnects in Lean Techniques for Project Environments