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.

Banish the Problem/Solution Mantra

Find a problem, find a solution. Find a problem, find a solution. This is the problem/solution mantra. One that is widely followed. Yet for every problem solved it seems like two more appear. Is this progress? Or does this mantra create an endless problem solving treadmill from which there is no escape?

In our information intensive, reactionary work environment it appears that problem solving and firefighting are becoming the job descriptions of more and more people. Within the age of the sound bite there is no time to analyze the root cause of problems. There is only time to stamp out each problem as quickly as possible - knowing full well that the next problem will arrive all too soon.

Enterprise Lean suggests there is another way. An alternative to the problem/solution mantra is the value mantra. Instead of “find a problem, find a solution,” the value mantra is simply “increase customer value.”

Imagine that someone followed the problem/solution mantra for 30 days. What would they have at the end of that time? More problems! However, if they followed the value mantra for 30 days what would they have? More customer value! Which path would you rather take?

In either scenario after the end of 30 days there may be fewer “problems.” But “increasing customer value” provides a worthy goal. It leads an organization to identify both the highest priority problem/solutions, as well as the product/service enhancements, that maximize customer value.

Conversations about increasing customer value also tend to be less defensive that those about problems. Asking “How can I help you to increase customer value” can be a lot less threatening that asking “How can I help you to solve your problems.”

Our words define our reality. A problem solving culture can be easily identified by its use of the problem/solution mantra. Whereas an Enterprise Lean culture all but banishes the problem/solution mantra and instead continuously increases customer value.

Updated August 22, 2010; first posted December 20, 2005

Fix a Dilbert a Day

Scott Adam’s Dilbert cartoon strip was launched in 1989. Ever since then we have been entertained by the foibles Dilbert found in everyday corporate life. What may or may not be surprising, depending on your point of view, is that the things that we laughed about for all of those cartoons with Dilbert over the year are still true today.

Dilbert has been brilliant in pointing out areas of waste within corporations. Any collection of Dilbert cartoons provides an excellent portrayal of the non-value added activities within any organization. With such succinct and accurate problem descriptions, you’d think that since 1989 companies would have made more progress towards eliminating all that waste.

Now would be a good time to reverse this trend. With global competition, what organization can afford to waste over 50% of its resources on non-value added activities? Dilbert is proof that most still do. Eliminating the wastes highlighted by Dilbert will help produce greater stakeholder value at less cost and higher quality.

Scott Adams has not yet run out of new material; new Dilbert cartoons are published every day. Imagine the impact if an organization maintained a prioritized list of Dilbert Cartoons as a backlog for performance improvements, and then worked off the backlog day after day. Waste would be eliminated. There would be no need for expensive analysis, pareto charts, or whatever to discover how to improve performance. Just fix a Dilbert a day.

Updated August 22, 2010; first published September 13, 2005

The Time for Lean Office 5S

AGILEAN’s Agile & Lean Glossary defines the Five S’s as five terms beginning with "S" used to create a clutter free workspace:

• Sort - Separate needed items for those not needed.
• Straighten - Arrange an appropriate location for all items.
• Shine - Clean the work area.
• Standardize - Establish a standard process for maintaining a clean uncluttered work area.
• Systemize - Maintain a consistent standardized approach.

Because 5S was developed by Toyota, the original Five S’s were all Japanese words. That’s why there are several different English translations that use different “S” words, but the intent is basically the same.

In Manufacturing Lean, a 5S program is typically the first Lean technique applied to a new environment. The targeted area is literally swept out, clearing the decks for future improvements. After 5S then other Lean techniques such as pull scheduling, workload balancing, and waste reduction are applied to cut total cycle time and increase customer value creation.

In Office Lean a 5S implementation can sometimes be too big a pill for information workers to take all at once. Many of today’s office environments are built on the premise of worker independence. Setting a standard of how employees should maintain their workspace could be considered by some a violation of their rights and lead to a loss of morale; even though it may help performance. Given this, why start a new Lean Office project with a full 5S implementation? There is probably not a more difficult place to start.

As an alternative, consider beginning with only one of the Five S’s: Systemize! Because of the sense independence that can lead employees to perform tasks “their way,” there is typically a lot of process variation; leading to high cycle times, costs, and defect rates. A systemize initiative looks at all the ways a process is currently performed and picks one, or builds a best composite, from the many.

Systemizing makes an easier a first implementation because the “new” process is probably already in use in somewhere. Therefore the organizational change management implications are reduced making it an easier early win. It also establishes the baseline for future improvements. When future process modifications are made after a process systemization, the people impacted by the change all start the journey from the same place.

After systemization takes hold, then other Lean techniques can be applied to continue to build on the early success and solidify the overall return on investment. Once the organization fully understands how to wield the power of Lean, then is the time to determine when and how to (judiciously) apply the other four of the 5S’s.

Updated August 11, 2010; first published January 30, 2007

The Voice of the (Internal) Customer

Customer service is about understanding what your customers value and then giving it to them. Great customer focused organizations are known for listening intently to their customers and then responding with products and services tailored to what they hear. But how many do this internally and listen to the voices of their own employees as effectively as they do their external customers?

Identifying the Voice of the Customer is a technique for capturing customer feedback in exactly the terms used by customers from their point-of-view. The Voice of the Customer becomes the basis for future product and service enhancements. It helps avoid the internal we-know-better bias that can spring up in any organization.

Typically it is a minority of people within an organization that interact directly with external customers. Yet those involved directly with external customers are the internal customer of a fellow employee. And they in turn are the internal customer of other employees, and so on. Any break or let down in this chain of internal customer support eventually is experienced by the external customer as well.

What works for external customers works just as well for internal customers as well. Here an internal customer is defined as anyone in an organization who receives a work product from anyone else. A work product can be data entered into a computer, information obtained through individual research or analysis, or a decision that was made.

Applying the Voice of the Customer internally is a process of listening to fellow employees about what they value about the work products they receive. Just as with external customers, statements of value and corresponding areas of waste are captured in exactly the terms used by the employee.

Been filling out that form the same way for years? Providing that analysis exactly the same way day after day? You might be surprised what your internal customer would say if you asked them to describe in their terms what the value is of the work you give them. What may appear to be an important and valuable contribution to you might reflect back differently when held up to the mirror of your internal customer’s words.

In fact it can be quite a shock; one that you should prepare for. When seeking out the Voice of the (Internal) Customer:

• Ask unbiased questions on what adds value to them and what doesn’t
• Write down (where everyone can see) everything you hear using the exact words
• Do not become defensive as a result of what’s said
• Remember that it’s hard to listen while talking

Updated August 10, 2010, first published March 25, 2007