Project Management in a Lean World – Translating Lean Six ... · sources, lean on time, and lean...

Version 1.0

Project Management in a Lean World

– Translating Lean Six Sigma (LSS) into the Project Environment

A VELOCITY White Paper

Project Management in a Lean World – Translating Lean Six Sigma (LSS)

into the Project Environment Introduction: It's a Lean World For most large organizations in the Western Hemisphere, the call to pursue a discipline of im‐provement began with the 1980's NBC broadcast of If Japan can... Why can't we? Many em‐barked on the quality movement putting human and financial resources towards that commit‐ment. Investing in training from Dr. Edwards 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 80's 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 Sys‐tem), SMED (Single Method Exchange of Die); JIT (Just in Time); or TPM (Total Productive Main‐tenance); 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 ‐ focused on improvement and the bottom line. First aimed at processes within manufacturing, Motorola then developed the elements to imbed it within their operating culture.

Thanks to James Womack and Daniel Jones through their book Lean Manufacturing and later, Lean Thinking, the tools of the quality movement now had a framework to work more collec‐tively ‐ 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 method‐ologies please refer to the white paper, “Combining Lean, Six Sigma, and the Theory of Con‐straints to Achieve Breakthrough Performance,” by AGI‐Goldratt Institute).

Both Lean and Six Sigma continue to be heavily embraced by the private and public sector and have become more and more integrated as Lean Six Sigma (LSS). Both are well developed, and both enjoy the support of many top executives, line managers, and a vast numbers of employ‐ees as well, 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 Lean Six Sigma 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 Lean Six Sigma efforts broadened into the project environment there was less than an enthusiastic greeting. Most project managers and resource managers felt that they were al‐ready working in a pretty lean world ‐ lean on re‐sources, 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 twenty feet in the air without a net (Figure 1).

In trying to "lean" the project environment there have been a few seemingly insurmountable obsta‐cles. 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. Addition‐ally, 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's 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 sys‐tem, the individual project system, the portfolio of projects system, and the resource manage‐ment system.

Figure 1. PM’s Point of View

It feels pretty lean when one feels they are already working without a net!

The task management system (Figure 2) consists of the list of tasks or group of interrelated tasks where a person is responsible for ensuring that all the ele‐ments 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 a task called “complete electrical wiring.” The crew chief would have one electrical crew to oversee pulling 110 volt wiring to lights and out‐lets; another perhaps running 220 volt wiring for some appliances; and another setting up the electrical panel.

The individual project system (Figure 3) consists of the sequence of tasks, handoffs and deliver‐ables 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 func‐tions listing their tasks and time (or level of effort) as standalone elements.

The individual project content commit‐ments are made independently of other projects’ task work for shared resources. Even when shared resourc‐ing is considered, little notice is given to the impact of variability on the releas‐ing of a resource from one task to an‐other. Also, where project to project

dependency exists, often projects commitments are made without consideration of the impact of variability of one project on another. An example might be when the organization is develop‐ing 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 (Figure 4), all the projects are either grouped by product type, business type or organization type that must be managed to ensure each customer is sat‐isfied. Unfortunately, the need dates of the customers are not necessarily able to be coordi‐nated across a portfolio.

At this level, conflicts between projects for limited shared resources become more visible. Un‐

Figure 3. Project Environment

System of Systems At the project level, we have the project system – the

sequence of tasks, handoffs and deliverables that when accomplished deliver the desired out-

Figure 2. Task Management System

System of Systems Project Environment In many project environments, there is

schedule and/or cost management at task or group of tasks level.

Task listed within the project:

fortunately, there are often compromises made – which projects will be given higher priority for resources versus others, and many projects struggle as they have to man‐age without the benefit of being the “hot” project.

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

The resource manager is often put into the posi‐tion 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.

What do we improve? With all these different systems and owners, it appears that approaching system improvement in project environments is like the “six blind men and the elephant”, the Indian fable immortalized in John Godfrey Saxe’s poem. Project manage‐ment system improvement has some interesting challenges. There are many owners of these dif‐ferent “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

Figure 4. Multi-Project Environment

System of Systems At the multi-project level, we have all the

projects we must accomplish within a specific window.

Figure 5. Multi-Project Resource Management

System of Systems At the resource management level, we are

not only planning what capacities we must have to support current and future project work, but how to deploy them currently at the task, project and portfolio level.

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 ac‐cepted 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 requires the task to be expedited. The key to improvement is this align‐ment 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 describ‐ing 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”.

In a multi‐project environment, we start by aligning the system of sys‐tems (Figure 6) 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 com‐mitment date. For those projects that are agreed to be taken on by the port‐folio; 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 cor‐ Figure 6. Aligning the Systems in a Project Environment

rect resources. Next, Lean Task Management would mean ensuring that the right tasks are exe‐cuted, at the right time, delivering the correct content with the correct quality, as quickly as possible

Addressing the Disconnects in Lean Techniques for Project Environments

As stated earlier, there are obstacles in applying Lean Six Sigma to the project environment. We have already addressed the issue of the system of systems nature of the project environment. It is now time to turn our focus to those disconnects with applying definitions and techniques derived from a manufacturing environment and applying them directly to a project environ‐ment. In particular, we will look at what is needed to improve productivity, focus, and value, and to eliminate waste and variation.

What is productivity in a project environment? One might be tempted to look at the percent load on the various resources versus their availability in deciding if the project environment is more or less productive – after all, this is where the project organization’s costs and invest‐ments are. However, this would be taking the traditional efficiency concept from the manufac‐turing floor and directly applying it to the project resources. The organization would only be measuring how active their resources were rather than how productive they were. Consider this; working out on a treadmill generates a lot of sweat and does provide a cardio vascular workout. Yet, if your goal is to go from point A to point B, nothing has been accomplished – there is activity, but one is not productive in getting to Point B. If our goal is to go from Point A to Point B as quickly as possible, then running faster from Point A to Point B is more productive than running slower or stopping periodically to go shopping, eat, or do email! A project’s throughput is only achieved when it is complete. How quickly an organization can sequence in that project to achieve throughput is based on the organization’s capacity in a window of time and is driven by how much work the resources can accomplish. It would follow that speed of execution of the right tasks accomplished with the correct content and quality drives speed of execution of each project and our capacity for the pipeline of work. Productivity must be viewed from the task perspective – the speed to accomplish the task.

Are we driving the productivity of tasks? Are the metrics within the project environment driving in productivity or do they actually drive in waste? In some organizations, some key metrics are items such as hours charged out per person, resource utilization, and earned hours? These met‐rics have little or no relationship to whether the hours worked were on the right tasks! In look‐ing at an example from Earned Value, we have two environments.

The top one shows the case when we earn hours on the longest pathway. The second shows that the same number of hours has been earned – but the tasks that drive project schedule

have not been touched. The metric of earned hours and subsequent indica‐tors of cost and schedule perform‐ance (Figure 7) may not alert the or‐ganization that they are not being productive on the tasks that drive project completion and the achieve‐ment of throughput!

How does the project environment use the five areas identified by James Womack and Daniel Jones as the key principles of Lean to ensure improve‐ment would be ongoing. The five are:

1. Specify value from the standpoint of the end customer;

2. Identify all the steps in the value stream;

3. Make the value‐creating steps flow toward the customer;

4. Let customers pull value from the next upstream activity;

5. Pursue perfection.

The Five Principles of Lean Applied to the Project Environment Specifying Value

How do we specify value in projects? Lean principles start with an attempt to define value in terms of specific products with specific capabilities offered at specific prices through a dialogue with customers. Taking the time to define the Project Value will alleviate some common prob‐lems found in the project environment, such as project definition too vague, lack of stakeholder support / participation, scheduling without really knowing the true scope, and scope creep. A simple technique for specifying value revolves around answering some key questions. Who is the customer of this project? Is there more than one? Is our own organization also requiring value from this project? Is the objective and scope sufficient to solve each of the project’s cus‐tomers’ problems – so we will not have to expand or redo the project? This means we must first established the problem statement(s) for each of the customers and only then specify what we must deliver to solve that problem and create value.

Activity vs. Productivity

Figure 7. Activity vs. Productivity

Identify Steps in the Value Stream

Once we have defined the value from the standpoint of the end customer we must identify all the steps in the value stream ‐ the project structure of arrows, tasks and resources that create that value. To ensure each task, relationship and resource is not wasted, we can use some guid‐ing questions. Is each task and path dependency necessary to achieve the customer objective ‐ is it creating value? If a task is not creating value, is it necessary for satisfying a boundary condi‐tion of the project (i.e. may not use outside contractors on constructing competition‐sensitive operating equipment)? Does this task meet the correct exit criteria to provide the correct input for its successor task?

Make Value Creating Steps Flow Toward Customer

As we plan the project, we need to ensure that the value creating steps flow towards the cus‐tomer‐ the deliverables that solve the customers’ problems. We should ask whether this task dependency is necessary to ensure we do it right the first time (or to minimize iteration variabil‐ity) and is it worth the time investment of waiting for the predecessor task to complete? Is the investment of this type resource (high level skill) in this task appropriate for the investment of the loss of the critical resource being tied up? As the value stream is mapped, what we call the project network, hopefully most of the steps will be found to create value. Additional steps may be listed and not add value to the product or service. Those steps that create no value and that should be eliminated are called Muda or Waste.

How do we decide if we have the correct tasks and the correct dependencies between tasks? The answer can be summarized as the correct tasks and arrow dependencies are those that are necessary to deliver the project scope and support their successor tasks to enable speed and quality. Do we have all the tasks that create value? It is important in projects to not only ensure that we only have tasks and arrows that are needed to create value, but also that we have no omissions of tasks that are needed to deliver full value.

Let Customers Pull Value from the Next Upstream Activity

In executing projects we must execute in a way that lets each task’s customer (successor task, deliverable) pull value from the previous upstream activity. As a project schedule is followed, it must be followed to ensure task execution, arrow dependencies and resources assignments oc‐cur as planned to minimize waste and create value for the customer.

Efforts to improve the project system of systems must address the waste that slows task ac‐complishment, wastes our limited resources’ time and increases the costs in projects. Waste comes from two main areas: The first is the plan – wrong tasks, incorrect arrow dependencies, incorrect planning of resources assigned, missing tasks; and incorrect or incomplete customer

requirements.. The second area of waste occurs during the execution of the project – the mis‐alignment of priorities; misuse of limited resource; and misaligned behaviors. We address waste issues within the project plan during project planning and scheduling. We address waste in project execution with the alignment of the system of systems.

What is waste in a project environment and will I know it when I see it? Dr. Taiichi Ohno identi‐fied seven categories of waste (to which an eighth category has recently been added). Many of the definitions for these categories are manufacturing based and not project based – yet the categories are very powerful to drive out waste, create speed and increase capacity. These categories are translated as follows.

Categories of Waste in a Project Environment

The first category of waste is Overproduction. In the project environment, this can translate into starting a path or task before it is available to start or assigning resources to any task be‐cause you have the resources and not because there is a task needing that resource or that quantity of resources. Additionally, overproduction might be seen as do‐ing a task as part of the project, when in fact it is not part of delivering the value of the project.

Figure 8 depicts an example of what was planned versus how it was exe‐cuted. The organization ends up spending additional time on a task, more than was needed and tying up resources longer for no additional value or speed.

The second category of waste is Waiting. Since productivity should be defined as how fast we complete a task and hand it off, then when a task is interrupted and waits for a resource that is pulled away to work on other tasks at the same time – the task experiences waste in the time it waits or is idle while the resource works another task. This is often the case when a re‐source is multi‐tasked (Figure 9).

Figure 8. Overproduction

Figure 9. Waiting during Multi-tasking

Another example of waiting occurs when a predecessor task completes its work, but does not pass on that work to the successor task. The successor task experiences waste by waiting for its hand‐off.

The third category of waste is based on the category of Transportation. Transportation waste in projects occur when a incorrect predecessor‐ successor task dependency is identified, resulting in an unnecessary delay waiting for a predecessor task to be completed for an input that is not necessary for the successor task to start. Another example is when a review that generates a

“looping” back or re‐work loop is later in the process than it should be – lengthen‐ing the project overall time by the time it takes to redo the ear‐lier tasks.

The example shows a medical review of in‐ternal requirements needed to meet cus‐

tomer requirements for a specific drug trial occurring after the time‐intensive costing process (Figure 10). This review could be done early in the process prior to the more time intensive tasks, shortening the quantity and time investment of tasks that might need to be reworked.

The fourth category of waste is Excess Inventory. In a project environment, excess inventory is represented by elements of too much task work in progress, or resource/resource groups ac‐complishing more tasks than the or‐ganization can process. Addition‐ally, some projects require too many supplies, unneeded files, unnecessary copies of docu‐ments or proto‐types. Excess inven‐tory also occurs

Figure 10. Transportation: Reviews in the Wrong Place

Figure 11. Excess Inventory

when we require more of a skilled or limited resource than the task requires. In some project environments, the project dedicates resources to the project for its entire length.

The example (Figure 11) demonstrates the amount of resources time dedicated to the project versus the actual need for the resource, creating an inventory of available hours that will be used by the project but not necessarily drive value.

The fifth category of waste is Excess Motion. Excess motion occurs in projects when time is taken on a task that is not inher‐ently needed to accomplish the task to create value. Holding onto a task that is complete and con‐tinuing to polish the output or searching for a handoff from a predecessor task are all excess mo‐tion. Additionally, when a task is multi‐tasked, time is required for setting the task down and/or to picking it back up (Figure 12).

This time is all non‐productive from the task’s view point and therefore waste.

The sixth category of waste is Non‐Value Added Processing. This category can include inserting excessive or redundant reviews and sign offs. It also includes the situation where resources are required to accomplish additional tasks within the project that are not part of the project, but

that are included because the resource may be in a similar area of work (Figure 13).

This happens frequently in software development pro‐jects where, in making a change in a part of the oper‐ating program for the pro‐ject, the resources are asked

to update the programming in the same part of the code for an additional need that is not asso‐ciated with creating value for the project at hand.

Figure 12. Excess Motion: Unnecessary set up and set down of a Task

Figure 13. Non-Value Added Processing

The seventh category of waste is Defects. De‐fects can take many forms from wrong, miss‐ing, or incomplete infor‐mation to handing off a task that does not meet its exit criteria. The de‐fects category also cap‐tures the situation when variability isn’t ad‐dressed in the project when it first occurs (Figure 14). The later the variability is discov‐ered, the more time and task areas will have to be reworked – creating waste of time.

The eighth category of waste is Underutilized Re‐sources. In many project environments, within the same skill set, there are “go‐to” people. Everyone wants them on their tasks and in their reviews.

In the example (Figure 15), the load for the blue skilled resource is 100 percent, but when we look at the load by individual practice, one is loaded 170 per‐cent, while the other is loaded only 30% and is under‐utilized.

Pursuing Perfection

The fifth principle of Lean that Womack and Jones cite is the pursuit of perfection. Lean practi‐tioners are asked to visualize the “perfect” process. No matter how much you improve a proc‐ess to make it leaner, there are always ways to continue to remove waste by eliminating ef‐fort, time, space and errors. There are six key ways to pursue perfection in projects. They are

1. address variability at the earliest point in the project;

2. plan how you desire to do the project (not the way you think will fit or have always done it);

3. don’t commit to a work‐around until you see if one is needed (or can check for any negative consequences of the work‐around);

Figure 14. Defects: Not resolving Variability

Figure 15. Underutilized People

Page 12

4. template best project practices into a PERT or Network diagram and use for all like projects;

5. apply project based risk management to the project prior to commencing the pro‐ject; and

6. monitor ‘actual to plan’ for what causes project cycle time to expand or contract and reduce all sources of variation (in the right order).

How does one reduce variation in an environment where each project and task appears to be unique? Again, one has to understand that variability takes different forms in projects. There are four types of variation that can be addressed in the project environment: project scope variation; task variation; iteration variation; and resource to resource variation.

One major cause of project scope variation (scope creep) is not gaining full consensus on the project scope upfront. This occurs either through not having all of the key stakeholders in the room ahead of time and/or by not pursuing the correct questions with them. By having the correct participants specify upfront the problem(s) to be addressed by the project, the group can agree on what really needs to be delivered to solve the problems‐ the resulting project deliverables. Additionally, with the right participation and the problem better understood, the correct scope needed is better able to be identified upfront reducing scope creep.

Since tasks in projects are most often unique to the type of work of the specific project and therefore will not necessarily repeat from project to project, we often need to focus on understanding which tasks have the greatest potential for possible variability– the largest spread (longest tails) (Figure 16).

Task variability refers to the difference in time between the task going pretty well (aggressive but possible) and the potential for things to go wrong (highly probable).

The larger potential variations can be ad‐dressed up front to minimize their occur‐rence by inserting predecessor tasks, util‐

izing different methods or preventing variability from flowing to the task from an upstream predecessor task.

Iteration variability can affect the ability of a project not only to go faster, but also to be relia‐bly accomplished. In product development it may be referred to as a loop. “A project may go through the loop multiple iterations – testing, re‐testing … analysis, re‐analysis … query, re‐

Figure 16. Task Variability in a Project

Page 13

query and so on. It cycles through until we have the results the client contracted us to achieve and – or – until we know everything we need to know." (Jacob, Bergland, and Cox 2009, 89). Iteration variability should be identified during planning and checked to see if it is a result of waste due to defects or transportation. If so, try to reduce the iteration. Quantify the impact of the repeatable variation within and across projects for a possible LSS event.

Many in project environments believe that there are significant differences in time taken be‐tween skilled resources within a group – resource‐to‐resource variability. This variability is of‐ten reduced when each resource is allowed to focus on a task without multi‐tasking. If re‐source to resource variability remains, capture and address appropriate resource to resource variation with mentoring provided during project execution.

At the end of each project completion, the team should perform an analysis of the variability identified before execution versus for the variability actually incurred. Categorizing the tasks by which task met or beat their more optimistic (aggressive, but possible) times allows the or‐ganization to better establish the times for planning and for protecting against variability in the next project. By categorizing the tasks met or exceeding the highly probable estimate of variability, analysis should be done on the impact of these more variable tasks impact that re‐quire project recovery actions. Which type of variation is hurting the project the most? From which tasks or resource types? Analyze those items which provide opportunity for system wide lead time reduction by addressing the variation through LSS events.

Leaning Traditional Project Management Traditional Project Management will need some refinements to become Lean – allowing more projects to reduce their cycle time. There are improvements already developed through the TOC Project Management (TOC PM) methodologies. Through TOC PM, the align‐ment of the system of systems is already established. A port‐folio’s work is pipelined (synchronized) in accordance with capacity of the organiza‐tion. More realistic, but shorter schedules are created by first planning the work as a Figure 17. Task flow towards the customer

Page 14

more of the perfect process called Network Building. Inherent in this process is the identifica‐tion of variability. The assignment and execution of tasks based on the synchronized project’s Critical Chain schedules –allows the work of the project to flow value towards the customer (Figure 17). Capturing actual to plan and focusing improvement allows more effective utiliza‐tion of resources to the tasks that drive project cycle time. Through over twenty years of ap‐plying the techniques of TOC PM to different project environments, we see the value of driv‐ing out waste – faster and faster projects, less compromises and more capacity freed up.

Page 15

References Jacob, Dee, Suzan Bergland, and Jeff Cox. 2009. VELOCITY: Combining lean, six sigma and the theory of constraints to achieve breakthrough performance. New York, NY: Free Press, a divi‐sion of Simon and Schuster, Inc.

Ohno, Taiichi. 1988. Toyota production system: Beyond large‐scale production. New York, NY: Productivity Press.

Saxe, John Godfrey. Blind Men and the Elephant

Womack, James P. and Daniel T. Jones. 1996. Lean thinking. New York, NY: Free Press, a divi‐sion of Simon and Schuster, Inc.

Page 16

Who We Are Since 1986, AGI‐Goldratt Institute has enabled organizations to better align the way they operate with what they are trying to achieve – strategic bottom line results.

AGI is the birthplace of constraint‐based techniques and solutions for business success. The Theory of Constraints (TOC) provides the system architecture and the integration of TOC‐Lean‐Six Sigma (TOCLSS) provides the focused improvement process.

Many organizations and consultants trace their roots back to AGI not only for TOC, but also for how TOC integrates with other improvement methods.

What We Do AGI provides its clients with rapid, bottom line results with what it calls VELOCITY – a powerful busi‐ness approach combining speed with direction. VELOCITY consists of three pillars: TOC, the system architecture; TOCLSS, the focused improvement process; and SDAIS, the deployment framework.

SDAIS (Strategy‐Design‐Activate‐Improve‐Sustain) begins with creating and then executing the strate‐gic roadmap to ensure business processes are designed and aligned to achieve the strategy. Once designed, the business processes are activated to allow the organization to operate in a stable, pre‐dictable manner with less investment and organizational churn.

Once stable, focused system improvements are applied to increase sustainable bottom line results. Execution Management tools and transfer of knowledge enable each aspect of SDAIS and serve as the foundation for self‐sufficiency and sustainment.

Why AGI AGI has expertise in TOC, TOCLSS, and SDAIS, with years of experience adapting each of these elements to meet the unique needs of its clients, regardless of size or industry.

AGI excels at leading organizations through successful business transformations by providing business assessment, implementation support, execution management tools, training, and mentoring.

We are motivated by making the complex manageable and enabling our clients’ self‐sustaining success.

442 Orange Street Penthouse Level, Suntec Tower Three New Haven, CT 06511 USA 8 Temask Blvd, SINGAPORE 038988 Tel: +1‐203‐624‐9026 Tel: +65‐97468450

www.goldratt.com

http://www.goldratt.com/�

Project Management in a Lean World – Translating Lean Six ... · sources, lean on time, and lean...

Documents

Transcript of Project Management in a Lean World – Translating Lean Six ... · sources, lean on time, and lean...