As stated earlier, there are obstacles in applying LSS 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 environment. 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 investments are. However, this would be taking the traditional efficiency concept from the manufacturing 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 cardiovascular 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 metrics have little or no relationship to whether the hours worked were on the right tasks. In looking at an example from Earned Value (EV), we have two environments (Fig. 6-7).

FIGURE 6-7 Activity versus productivity. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

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 the project schedule have not been touched. The metric of earned hours and subsequent indicators of cost and schedule performance (SPI [Schedule Performance Indicator] and CPI [Cost Performance Indicator]) may not alert the organization that they are not being productive on the tasks that drive project completion and the achievement of throughput.

How does the project environment use the five areas identified by Womack and Jones (1996) as the key principles of Lean to ensure improvement 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 problems found in the project environment, such as project definition being 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 customers' problems so that we will not have to expand or redo the project? This means we must first establish the problem statements for each customer and only then specify what we must deliver to solve that problem and create value.

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 guiding 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 condition of the project (e.g., 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 towards the Customer

As we plan the project, we need to ensure that the value-creating steps flow towards the customer and that the project deliverables solve each customer's problems. We should ask whether this task dependency is necessary to ensure we do it right the first time (or to minimize iteration variability) and is it worth the time investment of waiting for the predecessor task to complete? Is the investment of this type of 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 not only to 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 occur 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 accomplishment, wastes our limited resources 'time, and increases the costs in projects. Waste comes from two main areas. The first area of waste can occur during planning; whether through identifying the wrong tasks or arrow dependencies; incorrect assigning of resources to a task; missing tasks, or incorrect or incomplete customer requirements. The second area of waste occurs during the execution of the project from the misalignment of priorities, misuse of limited resources, or 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 (1988) identified 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 in the project environment. 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 because 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 doing a task as part of the project, when in fact it is not part of delivering the value of the project.

Figure 6-8 depicts an example of what was planned versus how it was executed. 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 on another task. This is often the case when a resource is multitasked (Fig. 6-9).

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 handoff.

The third category of waste is transportation. Transportation waste in projects occurs when an incorrect predecessorsuccessor 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 rework loop is later in the process than it should be, lengthening the project's overall time by the time it takes to redo the earlier tasks.

FIGURE 6-8 Overproduction. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

FIGURE 6-9 Waiting during multitasking. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

FIGURE 6-10 Transportation: Reviews in the wrong place. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

Figure 6-10 shows a medical review of internal requirements needed to meet customer requirements for a specific drug trial occurring after the time-intensive costing process. 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 accomplishing more tasks than the organization can process. Additionally, some projects require too many supplies, unneeded files, or unnecessary copies of documents or prototypes. Excess inventory also occurs 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.

Figure 6-11 demonstrates the amount of a particular resource's time budgeted to the project versus the actual need for that 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 inherently needed to accomplish the task to create value. Holding onto a task that is complete and continuing to polish the output or searching for a handoff from a predecessor task are all excess motion. Additionally, when a task is multitasked, time is required for setting the task down and/or picking it back up. This time is all non-productive from the task's viewpoint and is therefore waste (Fig. 6-12).

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 (Fig. 6-13).

This happens frequently in software development projects where, in making a change in a part of the operating program for the project, the resources are asked to update the programming in the same part of the code for an additional need that is not associated with creating value for the project at hand.

FIGURE 6-11 Excess inventory. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

FIGURE 6-12 Excess motion: Unnecessary set up and set down of a task. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

FIGURE 6-13 Non-value-added processing. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

The seventh category of waste is defects. Defects can take many forms, from wrong, missing, or incomplete information to handing off a task that does not meet its exit criteria. The defects category also captures the situation when variability is not addressed in the project when it first occurs. The later the variability is discovered, the more time and task areas will have to be reworked, creating waste of time (Fig. 6-14).

The eighth category of waste is underutilized resources. 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 Fig. 6-15, the load for the two blue skilled resource is 100 percent, but when we look at the load by individual person, one is loaded 170 percent, while the other is loaded only 30 percent and is underutilized.

Pursuing Perfection

The fifth principle of Lean that Womack and Jones (1996) cite is the pursuit of perfection. Lean practitioners are asked to visualize the "perfect" process. No matter how much you improve a process to make it leaner, there are always ways to continue to remove waste by eliminating effort, 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).

FIGURE 6-14 Not resolving variability. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

FIGURE 6-15 Underutilized people. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

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).

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 project.

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, task, iteration, and resource-to-resource.

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 or by not pursuing the correct questions with them. By having the correct participants specify upfront their problems to be addressed by the project, the group can agree on what really needs to be delivered to solve the problems-the resulting project objectives. Additionally, with the right participation and the problem better understood, the correct scope needed is better able to be identified upfront, thus 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).

Task variability (Fig. 6-16) 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 addressed upfront to minimize their occurrence by inserting predecessor tasks, utilizing 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 accomplished reliably. In product development, it may be referred to as a loop. "A project may go through the loop multiple iterations-testing, retesting . . . analysis, reanalysis . . . query, requery 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, 61). 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 between skilled resources within a group-resource-to-resource variability. This variability is often reduced when each resource is allowed to focus on a task without multitasking. If resource-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 the variability actually incurred. Categorizing the tasks by which task met or beat their more optimistic (aggressive, but possible) times allows the organization 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 that require project recovery actions. Which type of variation is hurting the project the most? From which tasks or resource types? Analyze those items that provide opportunity for system-wide lead-time reduction by addressing the variation through LSS events.

FIGURE 6-16 Task variability in a project. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

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 alignment of the system of systems is already established. A portfolio's work is pipelined (synchronized) in accordance with capacity of the organization. More realistic, but shorter schedules are created by first planning the work as more of the perfect process called Network Building. Inherent in this process is the identification 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 customers (Fig. 6-17). Capturing actual to plan and focusing improvement allows more effective utilization of resources to the tasks that drive project cycle time. Through over 20 years of applying the techniques of TOC PM to different project environments, we see the value of driving out waste-faster and faster projects, less compromises, and more capacity freed up.

FIGURE 6-17 Tasks flow toward the customer. 19912010 Avraham Y. Goldratt Institute, LP. All rights reserved.

References

Jacob, D., Bergland, S., and Cox, J. 2009. VELOCITY: Combining Lean, Six Sigma and the Theory of Constraints to Achieve Breakthrough Performance. New York: Free Press.

Ohno, T. 1988. Toyota Production System: Beyond Large-Scale Production. New York: Productivity Press.