Labor Productivity vs. Information Effectiveness

Productivity is a popular measure of process performance.  It can be misleading if too much attention is paid just to it.  The Agile and Lean Glossary defines productivity as a ratio of the customer value produced per unit of labor.  When labor productivity is the primary focus information effectiveness suffers and the result is higher costs, poorer quality, and lower customer satisfaction.

The emphasis on productivity causes too much attention to be placed on the labor cost denominator of the productivity calculation rather than the customer value numerator.  Reducing the number of hours or cost per hour to produce customer value increases productivity.  This then becomes the goal.

For example, investments in information technologies are typically justified by increasing labor productivity.  If it takes 8 labor hours to create a unit of customer value and a tool can be created to reduce this to 4 hours; the result is a 50% increase in productivity. 

Productivity in our Blood

The use of a tool to increase productivity is something people understand.  It is in our DNA.  We have been prodigious tool users for a very long time.  But too much of a good thing leads to an unbalance. 

To say that the only measure for process improvement is productivity is the same as saying the only tool needed to build a house is a hammer.  Certainly conceivable to do, but add a few more tools to the tool box and the power of possibilities increase.

Lada’s Laws define Service Time and the Lean Ratio as two additional measures that help identify new possibilities for process improvement.  

The calculation of service time is divided into two components:

·         work time

·         wait time

Productivity measures the effectiveness of work time.  Reduce work time and productivity increases.  But reducing work times may not have an impact on wait time.  In fact increasing productivity by reducing work times could cause wait times to stay the same or even increase.  Longer wait times lead to increased cost, more errors, and lower customer satisfaction.

Information Effectiveness

If work time is an indicator of labor productivity, wait time is an indicator of information effectiveness.  What is waiting during that wait time is information.  People are busy.  At any point in time they are applying their labor somewhere. 

In the typical process information is lazy.  It spends a lot of time waiting around for someone to pay attention. And if information is waiting then so is a customer.

Two Perspectives of Improvement

Take the case of customers waiting for their service requests to be completed.  Let’s say that the average service time for those requests is 4 weeks and that the total work time to complete the service request is 16 hours.

If we were able to increase the labor productivity associated with the service request by 50% our work time would be reduced to 8 hours from 16.  Most organizations would consider a 50% increase in productivity a huge win and a significant cost savings. 

From the customer point of view, what used to take 4 weeks would now only take 3 weeks and 4 days.  Would the customer even notice the difference?  An organization focusing only on productivity may not even notice the problem, but their customers would.  Under this scenario you could conceivably reduce the work time to zero and still take 3 weeks and 3 days.

This is a hard lesson to learn.  Time after time, organizations attempt to reduce service times by solely measuring and increasing productivity.  Paying attention to the wait time component of service time, in addition to the work time, provides a more balanced view that leads to increases in both labor productivity and information effectiveness.

Case Study: Measuring Process Performance

Service time is defined by the Agile and Lean Glossary as the wall clock time necessary to provide a service from start to finish.  It is measured by noting the start time and the end time of a unit of customer value as it flows through a process.  Service time can be averaged over a period of time to determine how long customers must wait to receive a product or service.  But averages can be misleading, especially if there is a wide variation in delivered service times.

Figure #1 is a histogram of the service times of an organization’s customer service requests over a four month period prior to implementing a Lean process improvement project.  The histogram was created by counting the number of service requests that completed for each time bucket across the bottom axis.  Those that completed from 0 to 10 days were counted in the “10” bar on the chart.  Those that were completed from 11 to 20 days were counted in the “20” bar, etc..  The total service requests for each month are shown using a different color segment on each bar.

Figure #1

The distribution of service requests shows a peak around 40 days with a long tail out beyond 300 days.  Building to an initial peak followed by a long tail is a common distribution curve of service times.  In this case, the tail was unusually long, with almost 20% of the requests taking over a year to complete.

Averages can be Misleading

Prior to development of these service time histograms, the organization simply calculated the average service time of their service requests.  Although many improvements made as part of a Lean process improvement project, the average service time remained stubbornly flat at 150 days.  Simply calculating the average service time did not reflect the impacts from the improvements being made.

Figure #2 is a histogram of service times for the same organization two years later.

Figure #2

Comparing the histograms of Figure #1 and Figure #2, the latter shows a tighter distribution of fulfilled requests at a peak of around 30 days.  Then a rapid fall off at 60 days to a long flat tail.  The histogram of Figure #2 shows progress over Figure #1 by reducing the customer service time for the majority of customers.  Even though the average service time each month was still around 150 days.

Average service time was never an accurate measure of performance because of the length of the distribution tail.  The average service time only rose or fell in a given month based on the number of 300+ day service requests that were delivered in that month.  It did not take many 300+ day service requests to increase the average service time calculation; even with service times in the 30’s. 

One of the efforts of the Lean initiative was to reduce the work-in-process (WIP) and close out old service requests.  During those months the average service time was worse than 150 days.

Why the long tail?
In this case study root causes were:

1.   Customers learned to put projects in the queue long before they were needed just to insure they would be completed on time.

2.   There was a mix of customer requests; some fully ready for execution and others that first required complex analysis. There was only one process to handle both alternatives.  The second peak at 130 days in Figure #2 represented complex projects.

3.   There was a lot of WIP with no priority to which work should be completed first; causing some work to flow through quickly and other work to literally get lost on someone’s desk

Process Predictability
The lesson learned from this case study is that average service time is not a sufficient to measure process performance.  Average service time is easy to calculate.  Little’s Law defines the average service time (total cycle time) as ST = WIP / Throughput.  But this equation does not consider which element of WIP is throughput next.  

Charting the distribution of service time provides insight into the predictability of a process.  Providing a customer a service ready date based on an average calculation can cause dissatisfaction if their actual service ready date can vary greatly from the target.  A tight service time distribution with a Lean Ratio of 2 or less is an indicator of a high performing Lean process that delivers maximum value for minimum cost.

 

Effective Information Flows

The previous post, Measuring Process Flow, defined the first component of Lada’s Laws as Service Time = Work Time + Wait Time.   This post describes how the ratio between work time and wait time indicates how effectively information is used within an office.

Let’s face it.  Information is lazy.  Billions have been spent on information technologies but no one is able to get the right information at the right time in the right format.

Lada’s Laws are an indicator of information effectiveness.  The Agile and Lean Glossary defines the Lean Ratio as the second component of Lada’s Laws:

Lean Ratio = Service Time / Work Time

Where:

Work Time = The total time it would take to create a product or service if there were no blockages or interruptions

Service Time = The wall clock time to provide a product or service to a customer from initiation to delivery

A Lean ratio of 2 our less indicates the effective use of information within an office.  A Lean ratio of 10 or higher is more typical.  A ratio of this magnitude indicates that even if the people are busy the information is not. 

The Paper Mentality
There are two primary causes of ineffective information:

1)   Processes still conforming to paper-based constraints

2)   Data processing systems

An amazing number of processes are still designed as if paper were the primary transport of data.  This was the case during the 50s when time and motion studies were popular; but not today.  The large investments made in technology have largely eliminated paper.  It’s no longer the preferred transport for information.  Whereas paper is disappearing, paper-based constraints to processes are still prevalent.

One constraint paper placed on processes was to make them serial. It was too expensive to copy paper to make parallel flows.  Since paper was hard to move, batches of work were passed from one person to the next.  The arrival of paper was the equivalent of a baton transfer that indicated a transfer of responsibility for who was to work on it next.  Since it was difficult to predict the arrival of paper, people were given many different tasks to insure they stayed busy.  And once paper started down a process, it was almost impossible to find it until it emerged out the other side.

Today processes are still bound up by these paper-based constraints.  Even though most data now travels electronically.  In fact many processes have worse performance now than they did when they were purely paper-based.

Serial processes are still the norm.  Batches of work must be completed before new work is started.  People keep so many balls in the air that more time is spent juggling than working.  Exception processing and expediting are 80% of the effort not 20%.  And meanwhile, everyone is deluged with data making it harder and harder to find the information they are looking for.

Breaking Free from the Paper Legacy
To achieve a Lean ratio less than 2 requires a clear focus on discarding paper-based constraints.  Lean processes are designed to achieve the continuous flow of information from one customer value added step to the next. 

Parallel processes are used to segregate complexity and reduce service times.  Work is pulled in priority order only when needed so work-in-process is kept to a minimum.  Expediting is eliminated and exceptions are reduced by delivering the right information to the right person at the right time. 

The Lean ratio is easy to measure and gives an organization a clear target to shoot for.  Rather than a goal to work harder or faster, the Lean ratio focuses attention on making information more effective and as a result makes the organization more effective as well.

Measuring Process Flow

The previous post, Measuring Service Time, defined service time as the wall clock time to provide a service from start to finish.  This post describes how to use service time as a measure of process flow.

The productivity of people and tools has dramatically increased over the last 20 years.  Yet with all of that increase in productivity, things still seem to take too long to get done.  The service times of processes have remained stubbornly high.

Traditional process improvement is conducted from the perspective of helping make people more productive.  But what about information?  It’s impossible to perform any process without information.  However, the productivity of information is largely ignored.  In most organizations people are busy but information is lazy.

Why Information is Lazy

To understand why this is true, it is necessary to break service time down into two parts.  The Agile and Lean Glossary defines the first component of Lada’s Law as:

Service Time = Work Time + Wait Time

Where:

Service Time = The wall clock time to provide a product or service to a customer from initiation to delivery

Work Time = The total time it would take to create a product or service if there were no blockages or interruption

Wait Time = The total time a product or service, that is started but not completed, is waiting for any work to be performed

The first component of Lada’s Laws defines the two parts of service time from an information perspective rather than a people perspective.

For example, consider the following process:

1.   A service request is received via email

2.   Information about the request is entered into a database

3.   Phone calls are made to gather additional information about the request

4.   The additional information is entered into the database

5.   It is determined which resources are necessary to complete the request

6.   The request is sent for fulfillment

 

For the above example process there are periods of time when someone is working on the service request (work time), followed by periods of time when the request is waiting for someone to work on it.  From the perspective of the request’s information, it is alternately waiting and then being worked.  For this process the wait/work cycle repeats at least 5 times.

From the perspective of the individual handling the request, they never wait. They work on multiple service requests, one at a time, each at a different step in the process.  The individuals performing this work have very little non-value added time.

It is a different story from the perspective of the service request.  Whereas the people are busy, the information about the service request is very lazy.

 

Making Information as Busy as People

Let’s define the following for the process above:

• The average work time to complete the process above for one service request (work time) is .5 hours
• Each person averages a throughput of 2 service requests per hour
• At any point in time each person is assigned an average of 15 service requests; their work-in-process (WIP)

Little’s Law establishes that Work-in-Process = Service Time * Throughput.  Since Service Time = Work Time + Wait time, the average wait time for a service request is 7 hours; [(13 / 2) - .5].

Based on this information the people performing the process are very efficient.  Their average work time equals their average throughput.  

However, the service request information is very lazy.  For just this segment of the process, the average service time is 7.5 hours.  This means that if you put a tag on a service request that entered the process, that same tagged service request would exit the process an average 7.5 hours later.

For that same tagged service request, someone is actually only working on it for a total of .5 hours.  For the 7.5 hours our tagged service request is working its way through the process, it is sitting around doing nothing for 7 of those hours.  How lazy can it be?

The invention of Lean is how to make information just as busy and productive as the people of a process.  Lean does this without adding more people or more automation.  It just requires some process design changes.

The next post, Effective Information Flows, describes how the ratio between work time and wait time indicates the effectiveness of information flows.

Measuring Service Time

It’s hard to measure what you can’t see and what you can’t manage you can’t measure.  This makes measuring and managing the flow of work through a process difficult since flow is a concept of time.  Time is hard to see.  Many organizations are comfortable with taking snapshot measurements that freeze time.  But measuring process flow over time can be both hard to conceptualize and hard to do.

The overlap and inconsistencies in use of the common measures of flow and time is an indicator of the complexity.  To establish a framework for discussion consider the following definitions of time as found in the Agile & Lean Glossary:

Wall Clock Time – The continuous measure of time between two milestone events

Cycle Time – The wall clock time necessary to complete a single item of work

Lead Time – The wall clock time from when a customer request is made until the request is fulfilled

Service Time – The wall clock time necessary to provide a service from start to finish

Cycle time and lead time are probably the most commonly used terms to measure process flow.  However both measures are just as commonly misused.  Cycle time is the wall clock time to complete one cycle or unit of work such as fill out a form or send an email.  Lead time is the wall clock time to fulfill a customer request.  Both are used to describe the wall clock time to provide any service from start to finish but each usage is incorrect.

To measure the time both to fill out a form and send an email is actually the sum of the two individual cycle times, or the total cycle time.  It’s possible to measure the total cycle time of each step of a process.  But what should the sum of the total cycle times of each process step called.  The total total cycle time?  Can see where this is going?  What do you call the measure of time to perform two sequential processes?

Lead time has similar constraints.  It is strictly defined as the time from a customer request to fulfillment.  If a customer buys a computer on the Internet the lead time is from order submittal to the delivery of the computer to the customer’s location.  Good to know, but what if it is also helpful to know the time from order completion to the computer shipment to the customer?  By definition that is not called lead time.  Partial lead time?  Or perhaps total total total cycle time?

Time for a New Approach
Both cycle time and lead time are important measures but their definitions are very specific and do not apply to measuring flow for discrete segments of a process.  Service time is defined to fill the gap left by cycle and lead time. 

Service time measures the flow of work/information between any two points of a process.  It is called service time to emphasize that it is a measure of the wall clock time to provide a specific service either to either an internal or external customer. 

Examples of service time (measured in wall clock time):

• The time to capture a customer request at a walk-in customer service counter
• The time to finalize a customer request and submit it to engineering
• The time to complete the engineering design of a customer request
• The time to obtain customer approval of a completed engineering design

Time for Service
Service time could be established for a combination of the above process segments.  As well each of the above segments could be broken into more granular service time measurements.  In each of the above examples, a service level agreement (SLA) based on service time could be established as a measureable objective for those providing the service.

Lead time and cycle time were originally developed as measures of manufacturing processes.  In a non-manufacturing environment their use is limited due to their specific definitions.  Or worse their definitions are extended to serve other measurement functions leading to miscommunication and confusion.  Service time avoids these limitations by specifying both the service and the time to provide that service, providing an important measure for effectively managing that service.

The next post, Measuring Process Flow, describes how to use service time as a measure of process flow.

Kanban, Kaizen, or Scrum?

What do an Andon Board, Kanban, Kaizen, and Scrum have in common?  They are all Agile and Lean techniques that can be applied to manage projects.  This post briefly describes how these techniques work best when tuned to the type work-in-process found in your project. 

The Agile & Lean Glossary includes the following definitions:

• Andon Board – A Lean term for a visual control device that allows anyone to see and manage the status of the value stream.
• Kanban – A Lean term for a visual indicator that indicates when to execute an activity in a value stream.
• Kaizen Workshop – A Lean term for workshops to identify and implement improvements to a value stream.
• Scrum – An Agile term for a lightweight framework to manage complex projects.

Unfortunately, the above terms are not used consistently by all Agile and Lean practitioners. This in itself is not an issue, but common definitions are useful for clear communications. Current usage may be confusing the concepts behind some of these terms and their fit within organizations.

The term Kanban Board is sometimes used to describe an Andon Board for managing the work-in-process (WIP) of an organization. The board facilitates the movement of WIP from one queue to the next using rules to balance flow and minimize overproduction. It can be a useful tool to help prioritize work and minimize total cycle times.

Agile Scum also has an artifact known as a Scrum Board that is also an Andon Board for managing complex projects. Because of the similar look and feel between the two types of Andon boards sometimes Kanban and Scrum are considered two alternative approaches to accomplish the same goal.

A Kanban Board and a Scrum Board are similar. Both are used to help manage WIP. However the type of WIP that is managed by each is different. A Kanban Board helps to manage the WIP of a value stream or process. A Scrum Board helps to manage the WIP associated with a complex project. A Kanban Board is usually better suited to manage the WIP of individuals and a Scrum Board the WIP of cross-functional teams.

Scrum is actually closer to Kaizen than it is Kanban. Both Scrum and Kaizen are project management approaches to engage cross-functional teams to rapidly complete meaningful improvements within specific time-boxed iterations. In practice Scrum has advantages over the typical Kaizen. Scrum’s approach to managing WIP provides better visibility, prioritization, and predictability of project outcomes over time than Kaizen.

Regardless of what terms you use, managing the WIP of a value stream is different than managing the WIP of a complex project. Visual task boards are helpful for both; but pick the board best suited to your type of WIP. In any case, consider Scrum as an alternative to your next Kaizen.

The Agile Lean Enterprise

Agile was originally developed within the software industry and Lean was originally developed within the manufacturing industry. Given their diverse roots, they are not as different from one another as you might expect. In fact, if you peel back the layers of industry specific terms and perceptions, the two approaches are conceptually identical.
 
Agile and Lean both:

• Maximize value and minimize waste
• Manage time as an asset
• Establish a culture of continuous improvement
• Enable safe failures
• Increase predictability
• Proactively adapt to change
• Strive to achieve measureable results early and often

Traditionally, the difference between the two is that Agile focuses more on enhancing project management, whereas Lean focuses more on enhancing process improvement. However, in an era of almost continuous change the differences between project and process management are blurring.

Given project/process management convergence, rather than choosing between Agile or Lean, the opportunity is to pick the best of both. With the two approaches being conceptually identical, it is relatively easy to merge them to realize their combined strengths.

Agile’s strength is in managing the processes of how teams create customer value. Agile’s lightweight approach to self-organizing teams helps create flexible work cells that require less management overhead, have fewer handoffs, are less specialized, are more modular, and produce a greater diversity of products/services.

Lean’s strength is in managing the processes of how individuals create customer value. Lean’s focus on continuous flow helps to define the next most important thing to be done by each person in a process and provides techniques to ensure the maximum value is created from separate but interdependent resources.

Together Agile and Lean techniques can be applied to manage work environments with a continuously shifting mix of individuals and self-organizing teams. The resulting Agile Lean enterprise can:

1)  Operationalize both the execution and enhancement of a process as one management activity; and

2)  Leverage the best use of individual specialization for explicit linear tasks, and diverse teams for indeterminate non-linear tasks.