Getting the best out of your warranty department.

Warranty departments are usually poster children for the accumulation of excess parts inventory, disorganization, and lack of respect from the other upstream departments in the value stream. It doesn't have to be this way.

One client is doing a terrific job in redesigning its warranty department. They've replaced the piles of excess parts (except, of course, for the components that they always seem to stock out of ) with a two-bin system. Instead of haphazard ziggurats of replacement parts scattered all over the floor, they now have a clean, organized system with cardboard boxes and visual management cards containing all the necessary re-order information. They've effectively reduced their inventory by 70%. While this isn't a huge cost savings -- all their parts are pretty inexpensive -- it's a big savings in floor space and a bigger savings in time. Finding parts in the piles used to be difficult, and now they can pick, pack, and ship customer orders much more quickly.

One other thing this department has done: they've instituted formal "close the loop" meetings with the product designers and developers. When the PD team begins planning the next round of products, they meet with the warranty team to discuss what problems they were seeing in customer returns. Design problems, durability problems, material defects, etc. -- all are brought up in a formal setting to ensure that the PD team doesn't miss the important quality "signals" amidst the larger piles of return "noise." Although it's too early to see the benefits in new product design, it's already easy to see the benefit in morale: the warranty team feels like an important part of the company and the product. They're not the tail of the dog, just another segment of the product circle. Call it respect for people.

How is your warranty department run? Are you getting the best out of them? Are they providing all the value they can?

The use -- and abuse -- of parking lots

A reader writes in:

I've been in organizations that use parking lots in their meetings. But too often, those ideas never go anywhere - the company just ends up with a bunch of flip chart sheets that contain good ideas that never get fleshed out in subsequent meetings, because they're just not "big enough to hold a meeting on" or because "we don't have enough time/resources to investigate this right now" so they're constantly de-prioritized or put on a back burner.

It's a good question. Lord knows you've probably seen more than your fair share of those flip chart sheets rolled up and lying in an unused closet like Dead Sea Scrolls. So what to do?

Given my (ahem) rather strong opinions on the need to live in your calendar (or to set up a personal kanban), it's not surprising that I advocate carving out a specific time to revisit the ideas that have been relegated to the parking lot. You can choose the first or last 10 minutes of the next meeting, or you can schedule a new meeting specifically to clear out the parking lot. It doesn't matter.

Specificity is the key to making this work. You won't just "get around" to talking about those ideas any more than you just "get around" to tackling tasks that aren't on your calendar or your task list. This doesn't mean you have to do it every week: there's nothing wrong with deciding only to review the list monthly, quarterly, or semi-annually. Just be sure to block out sufficient time for the review on your team's calendar.

It's important to bring evaluation criteria to the parking lot review. You'll undoubtedly have way too many potential projects to take them all on, so you'll need some way of selecting the winners from the losers. Some possible criteria are:

• Ease, benefit, and urgency
• Revenue vs. risk
• Alignment with organizational goals vs. departmental goals

It doesn't really matter what criteria you use, just that you have some consistent way of determining whether or not the item is worthy of your organizational time and attention.

Now, the hardest part: throw out the losers. Get rid of the flip chart sheets and move on.

The parking lot is exactly like your personal to-do list: there's an infinite amount of stuff clambering for your attention, but only a finite amount of stuff that you can actually do. With an organization, there's an infinite number of potential projects, but a finite amount of people and money to take on those projects. So you have to cull the list. You have to divest yourself of the fantasy that you might actually take advantage of the opportunities that have been previously languishing in the parking lot. After all, the company has survived this long without implementing these ideas, so clearly they aren't all that vital to its success.

If you don't cull the list, you're sowing the seeds of the parking lot's demise. The list will be 83 items long, and no one wants to attend a meeting with 83 items on the agenda. Eventually, your colleagues will all find themselves too busy visiting their customers or washing their hair, and you won't have any more parking lot reviews.

But at least you'll have a nice collection of Dead Sea Scrolls in the closet.

Busy, not burned-out

I was gratified to read some of the recommendations in Joann Lublin's article, "Making Sure 'Busy' Doesn't Lead to Burnout" in the Wall Street Journal last week. Turns out that a lot of people are championing the ideas that I've been preaching about for awhile:

For some time-starved managers, keeping a detailed calendar often makes more sense than making daily to-do lists.

This advice echoes my argument that to-do lists don't work because they agglomerate items with disparate urgencies and complexities, and they don't provide any context: how long will the tasks take, and how much time do you really have available.

The article also recommends that people

prepare a weekly plan for tackling tasks tracked by their boss, such as regular revenue reports—and scheduling of daily items that eventually will land them in trouble if not completed.

This advice, of course, is nothing more than my suggestion to use the calendar as kanban, which enables you to automatically "pull" work forward at the right time -- and to do so automatically, without the cognitive burden of having to remember to do something at a certain time.

The article also points out the danger of taking on too many problems that aren't your own:

Consider [urgency addict] Liz Bishop. In January 2011, the senior vice president of Heffernan Insurance Brokers in Petaluma, Calif., was juggling 280 emails a day and often distracted by colleagues' crises. "I love solving problems,'' Ms. Bishop says. "That's emotional cookies for me." Meanwhile, her customer revenue had plunged 50% during the recession, and Ms. Bishop, whose clients were mainly in the construction industry, found herself without time to bring in new clients.

This situation reminds me of Jamie Flinchbaugh's advice that our direct reports' problems are not our problems:

Your problem is why is the preventive maintenance program not working that allowed all those pieces of equipment to go down in the first place. Or why are your customers not seeing the value proposition. Or do we have a planning problem or an execution problem that allows so many projects to get behind schedule. You have unique problems, and until you understand that fact, and work on the appropriate problems for your role, little progress can be made.

There are no Copernican insights here, which is both good and bad: you don't have to spend money, buy new equipment, or hire new people. On the other hand, you have to  use your calendar assiduously, delegate appropriately, and learn to address system-level issues.

Nothing new -- but not necessarily easy to do.

Four to-do lists? Try 5S.

My client yesterday showed me her to-do list. Make that her to-do lists. The handwritten one on the yellow legal pad. The messages marked as unread on her Blackberry. The meeting action items listed on her iPad. The messages she flagged for followup in her Outlook inbox. Four lists, four places to look for work that needs her attention.

As I've written about before, 5S for the knowledge worker does not mean putting tape outlines around your stapler or setting rules about how many family photos can go on your desk. That's just a mindless transfer of 5S to the office. What you need to do is translate it for the office -- and that means applying it to the information you manage.

If you're living with four to-do lists, you need 5S. You need a way to organize the tasks so that you can easily see them, assess them, and make rapid judgments about what, how, and when to handle that work. If you're embarking on a scavenger hunt every time you want to plan your day, you're in trouble.

From my perspective, the twin purposes of information 5S are (1) to help surface abnormalities (in this case, work that's not getting done), and (2) to make it easier and faster to access materials. The fewer lists you have, the more likely it is that you'll accomplish those goals.

If, for some reason, you need to work with multiple to-do lists (the iPad for meeting notes, a legal pad for things you remember at your desk, the inbox for stuff arriving via email), that's okay -- but then it's incumbent upon you to 5S those lists each day: review them, consolidate items, and schedule the work in your calendar or on a personal kanban.

You wouldn't want to do something as simple as grocery shopping with four different shopping lists. Why would you want to do something as complex as scheduling and planning your work with four lists?

The personal kanban: not just "vocabulary engineering."

Michel Baudin, who most assuredly has forgotten more about lean than I’ll ever know, wrote recently about the “personal kanban” and concluded that it was much ado about nothing on three counts. First, Baudin argued that it was essentially old wine in new bottles—the Scancard System of the 1980s did much the same thing. Second, its lack of portability makes it impractical to use in meetings or with a network. Finally, it only displays the current status of a project, rather than the whole history. (In a felicitous turn of phrase of which I’m really jealous, he also   called it “a feat of vocabulary engineering,” leveraging the buzz around an aspect of Toyota’s production system to repackage ideas that have little to do with it.) Having just written about value of a personal kanban in my forthcoming book (A Factory of One, available in mid-December), and having seen many individuals apply the concept successfully, I must respectfully disagree.

He’s absolutely right that for a long time now people have known they should limit their work in process. However, the unhappy fact is, they don’t—and it’s not just because supervisors insist on piling more and more projects onto hapless subordinates, like Egyptian slave masters in The 10 Commandments. In large part, people don’t limit their WIP because they have no idea themselves of how much work they have on their plates. Particularly in a modern office, most of their work is invisible, residing in electronic files, email messages, and all manner of stray bits and bytes on their computers. As a result, people are terrible managers of their own workload, and they reflexively accept new responsibilities and commitments when they’d be far better off saying “no.” The personal kanban, like the Scancard before it, does a wonderful job of making that work visible and helping people better manage their work.

Baudin’s comment about the lack of portability is valid, but in my opinion hardly disqualifies the personal kanban as a valuable tool. Much of a knowledge worker’s time is spent in the office, not a conference room, and is therefore accessible to him or her when needed. And besides, if the kanban in the office encourages people to have their meetings where the work is done, and not in the conference room, so much the better.

His final point about the kanban only displaying the current state of a project can be easily fixed. Beneath the “Backlog/Doing/Done” section, you can map out the key steps of the entire project/value stream, as you can see in the photo below.

This section provides the context for each task—both the history and the future requirements, the latter of which the Ybry Chart can’t do.

The last thing I’ll say in defense of the “personal kanban” is this: the purpose of a kanban in a factory setting is to control WIP and pull resources forward at the right time. The personal kanban does precisely that—except that the resources in this case are the person’s time and attention. If the whiteboard and sticky note combination of the personal kanban succeeds in this goal, then I think it deserves the name kanban.

So, Michel, while the personal kanban may not be a breakthrough on the order of, say, Copernicus’s insights on planetary alignment, I maintain that it’s a valuable, capable, and flexible tool to improve knowledge worker production.

Cardboard boxes and common sense.

“Sorry about the mess. These are just the cases that came in the last couple of days. The big pile over there? That’s the research project that I’m supposed to be working on.” Megan sighed despairingly and waved her arm, indicating piles of unread slides stacked like ziggurats on every flat surface in her office. Megan is an experienced, talented, and very hard working pathologist at a major cancer hospital. Her days are spent with her face pressed up against the viewer of her microscope, examining tissue samples for evidence of malignant tumors. I was visiting her because she seemed to have lost her ability to read cases and turn them around rapidly for the referring physicians. Megan was caught in a bind: she was feeling pressure from her boss to work faster, but she was worried that reading the slides more quickly would increase the risk that she’d incorrectly diagnose a case.

Megan went on: “I used to be able to read more cases during regular business hours, but now I have to come in earlier and stay later just to keep up—and obviously, I’m not doing a particularly good job of that. Although to be fair, no one else in the department is either. We’re all feeling swamped.”

Frankly, I wasn’t sure I’d be able to help her. I’m neither a pathologist nor a doctor. (Which, since I’m Jewish, always made my parents very sad. They weren’t exactly cheering when I took a class in the Semiotics & Hermeneutics of the Mystery Story.) I know as much about interpreting tissue samples as I do about designing sub-atomic experiments for the Large Hadron Collider.

So I spent a couple of days watching Megan work. And what I saw reminded me of what Keith Poirier wrote on Jamie Flinchbaugh’s blog recently:

Lean is nothing more than the re-introduction of ‘common sense’ into our daily work lives.

I don’t know anything about interpreting biopsies. But it turns out I didn’t need to. What I saw was a doctor who seldom got more than eight uninterrupted minutes to analyze a slide. Practically every time she nestled up against her microscope, someone came into her office and interrupted her. Following each interruption, she’d turn back to the slide, and start re-reading it from the beginning to ensure that she didn’t miss anything. As a result, reading each case took three, four, five times as long as it needed to.

What’s worse, in the two days I watched her, none of the interruptions were urgent. In fact, the most common interruption was from technicians bringing her new slides to read. They’d walk in, say hello, tell her that they have new cases, and she’d tell them to just put them on the corner of her desk.

My solution? Put a cardboard box outside of her door with a sign telling the technicians to put all new cases inside it. Megan created a fixed schedule to pick up any cases every 90 minutes. Fancy, right? She cut interruptions by two-thirds, and cut the time it took her to process her cases by 40%.

We didn’t talk about takt time, pull systems, or kanbans. As Keith Poirier wrote, it’s just common sense. You’re not going to be able to do your work—whether that’s reading pathology slides, writing ad copy, calculating force vectors on bridges, or writing a patent application—quickly or efficiently if you’re always being interrupted. So we cut down the interruptions to help her do her work a bit better.

There’s still plenty of work to be done in that hospital’s pathology department. There’s waste all over the place. But by focusing on simple, small, and rapid improvements, we made a big difference in Megan’s performance—and her happiness.

Chinese acrobats, Italian judges, and traffic jams.

You might want to reconsider saying yes to the latest project that your boss drops on your desk like a side of beef. Saying no might help you do a better -- or at least a faster -- job. Turns out that managing so many concurrent projects that you're the white-collar equivalent of a Chinese acrobat spinning dishes doesn't work so well.

A study of Italian judges who were randomly assigned cases and who had similar workloads found that those who worked on fewer cases at a time tended to complete more cases per quarter and took less time, on average, to complete a case. The authors concluded that

Individual speed of job completion cannot be explained only in terms of effort, ability and experience: work scheduling is a crucial “input” that cannot be omitted from the production function of individual workers.

The problem is that too much work-in-process causes a system -- whether machine or human -- to bog down.  In a phrase that will likely make Jim Benson and Tonianne deMaria Barry smile (or call their lawyers), the MIT Sloan Management Review draws the analogy that

excessive multitasking may result in the workflow equivalent of a traffic jam, where projects get backed up behind other projects much the way cars get stuck in traffic when there are too many on a highway at once.

If this phrasing rings a bell, it should: here's how Jim and Tonianne made this point visually (check out slide #7):

A few weeks ago, I wrote about the need to use your calendar as a tool to assess your daily production capacity, but not with the goal of filling up every minute of each day. Overloading the system writ small -- stacking up tasks during the day like 747s over LaGuardia -- is a bad idea. But overloading the system writ large -- scheduling too many legal cases or too many projects at one time -- is also a recipe for slow turnaround, frustrated customers, sub-optimal performance, and probably premature hair loss.

Remember, you're not a circus performer. Neither your boss nor your customers "ooh" and "ahh" because you're juggling 26 projects at once. They ooh and ahh when you deliver the goods quickly and with perfect quality.

It's about throughput, not capacity.

For a long time now, I've advocated "living in your calendar" in order to, among other reasons, understand your production capacity. Mapping out your work on a calendar helps prevent you from taking on more commitments than you have the time to handle. I was wrong. (Sort of.)

I just finished reading Jim Benson and Tonianne DeMaria's book, Personal Kanban, in which they point out that capacity is irrelevant. It's about throughput. No one -- not your boss, not your customers, not your family -- cares about how much capacity (hours) you have each day to work. They care about how quickly that work gets done, whether it's preparing next year's budget or cleaning the garage.

What's the lead time? What's the cycle time? How long do I have to wait? These are the key questions they want answered. (Well, only engineers ask the first two questions. But everyone asks the last one.) And those are the key questions you should be asking yourself. Not, "How much time do I have to work this week?", but "How can I get this work done most quickly?"

To shamelessly steal an analogy from Personal Kanban, no one cares what the capacity of a freeway is. In fact, it's completely irrelevant to you how many cars can be packed into one stretch of asphalt. What's really important is how long it takes to move down the road and whether you'll make it home in time to watch reruns of "Webster." And as any urban planner or operations manager will tell you, once your system exceeds 65-70% of maximum utilization, you're guaranteed to reduce throughput and increase cycle time.

This is why living in the calendar can be dangerous. There's a tendency to look at empty space on the calendar as something to be filled up with some ostensibly productive work. After all, if you're not filling those minutes and hours, then clearly you're either a lazy slacker or you're just terribly inefficient. With unemployment at 9%, who wants to be accused of either?

But how fast would traffic move if every square foot of the freeway was occupied by cars? How fast will your work move if every moment of your day is occupied by some pre-planned task or meeting? It wouldn't move at all. Just look at the cars around you at rush hour -- or look at the crap that's been piled up on your desk and your inbox for a few weeks. That tells you all you need to know about throughput.

So, by all means live in your calendar. Use it to assess your production capacity. But remember that 100% utilization of that capacity is ultimately self-defeating. You need slack in the system, because throughput is what counts. Not capacity.

Delegating with a Kanban

A partner in the tax practice of a law firm asked me, "How can I keep better track of the work the associates are doing? And how can I stay on top of the work I've delegated to them?" Tracking work that others are doing is a common problem, particularly in a high-priced law firm, where the clients want answers to their questions at the most inopportune times -- like the middle of dinner, or just after you've settled into watching Toy Story 1 & 2 with your kids. To be fair, if you're charging them $800 per hour, you should be ready to answer those questions. However, hounding your team to get you that information -- especially when they're watching Toy Story with their kids -- is a sure way to get your firm de-listed from the "100 Best Places To Work."

So what can you do?

Inspired by Lee Fried at Group Health Cooperative, and by Jim Benson over at Personal Kanban, I realized that the kanban is an ideal answer. (For those readers who don't know what a kanban is, for the purposes of this post, just think of it as a white board or bulletin board that's visible in the work area.)

Put each person's name down the left side of the kanban and create a row for each of them. Put the task they're assigned in the next column, and the expected completion date next to that. If you want to be fancy, you can even include some symbol that indicates about how far along they are in completing the work. Have another column that holds a simple red/green signal that indicates they're on track or they've fallen behind. And that's it.

What you've created is a simple visual management tool that allows you to quickly see how each person is doing. Here's an example of what it might look like:

In this screenshot, I've adopted Jim's approach (and terminology) by breaking work into three buckets: "To Do," "Doing," and "Done." This added information helps provide context for where you are in a larger project.

There's nothing earth-shaking about this approach, but I think it falls into the sweet spot between something that's too small for full-blown project management software, and something that's to big for a one-person task list. Having it prominently posted ensures that the work doesn't disappear into a computer file. And the red/green status bar enables someone to signal for help without having to schedule a formal meeting.

One very easy way to work faster.

It's a little disappointing, really. I really thought I was being so smart and creative. I read Pete Abilla's recent post about Little's Law, software development, and queue management, and I thought -- "Hey! I bet you could apply this concept to argue against multitasking and overloading one's calendar! Little's Law proves that if you do that, it will actually take longer to get your work done!"

And then I realized that Pete had beaten me to this flash of insight by, oh, about three years. There it is, in semi-permanent electrons, back in April of 2007:

A common result for multi-taskers is that simultaneous projects or items are spawned.  Multi-threaded is sometimes the analogy here.  But, unlike machines, people have a difficult time completing multi-threaded processes.  The end result is that projects and efforts are not complete, time runs shorter and shorter, and demands continue to pile up.  Think of everything I’ve just described as Work-in-Process (WIP).  So, using Little’s Law above, as WIP grows, then Throughput decreases. Translation: As we multi-task, we start several projects, complete only a few, WIP grows, Cycle Time eventually lengthens, and we are less productive.

(By the way, although this is the money quote, the whole post is worth reading. He's far more eloquent on Little's Law than I ever could be. Plus, I can't figure out how to insert the Greek letter Lambda in a blog post.)

I think that Pete's point makes a good case for using a tool like a kanban or your calendar to manage the amount of work you take on. If you don't match your production capacity (which is to say, the limits on your time and attention) with the amount of work you take on, you've got a recipe for stress and slower work.

Jim Benson, over at Personal Kanban (where "It's hip to limit your WIP."), tells this story beautifully in his "Personal Kanban 101" Slideshare presentation. The picture above (from that presentation) makes Pete Abilla's point about Little's Law visual.

Jim's point is that the motorcyclist is the last, little, five minute task that you agreed to do. . . but of course, in a completely clogged day, it can't get done quickly at all. And a kanban (his solution), or rigorous use of the calendar (my solution, so far) is a way to ensure that you don't get yourself into this situation -- where five minute tasks can't get done, where the cycle time for your work lengthens, where frustration and unfulfilled promises mount.

Okay, so my idea about Little's Law and multitasking wasn't original. I stand on the shoulders of giants, and all that. But if it brings a bit more attention to Pete Abilla's orginal post, so much the better.

Lean and the power of communication.

I attended the LEI's Lean Healthcare Transformation Summit last week in Orlando and was impressed by all the attendees' dedication to improvement. The problems with our healthcare system -- and the healthcare insurance system -- are legion, but seeing the accomplishments of this group gives me some measure of hope that things might actually get better. Amidst all the value stream maps and photos of 5S initiatives, one thing that really hit me was how communication lies at the heart of so much of lean. From kanbans to value stream maps, from daily huddles to managerial standard work from 5S to A3s, I kept seeing how clear, concise, and consistent communication eliminates waste, creates value, and focuses activity and attention on what's important. When you think about it, a kanban is a form of communication that tells someone that something needs to be done at a certain time. Value stream maps are a kind of visual communication that helps reduce misunderstandings. Daily huddles are clearly about communication of problems (and solutions), while manager standard work is a way to routinize and clarify communication up, down, and across an organization. 5S is a way to help communicate abnormalities in a process or place. A3s are an elegant and concise method of communicating just about anything. And you can't go to any lean plant or office without seeing visual management boards that essentially are just forms of communication.

So this got me thinking about the waste of time, effort, and energy that goes into what passes for communication in most organizations. You know -- confusing emails with no clear purpose. Voice mails that don't answer questions, but instead just ask you to "call me back" (and race through the telephone number at the end). Soul-sucking meetings that serve no point except the aggrandizement of the organizer's ego. Proposals and reports that deforest half of Brazil without telling a coherent story. That's a colossal amount of waste.

By no means am I diminishing the importance of the lean tools that are so often discussed. But it does make you wonder: what would happen if we spent even just a little time on improving the quality of the communication within and between organizational silos?

Closed Lists, Kanbans, and the Key to Prioritization.

I was recently revisiting Mark Forster's concept of the "closed list." (Mark is the author of Do It Tomorrow, and a leading productivity consultant and thinker based in the UK who's well-worth reading.) The closed list is essentially a to-do list that's limited by the amount of work time you have available during the day. Mark's argument is that making a daily to-do list containing 14 hours of work is pointless, not to mention frustrating and self-defeating. If you're only working 10 hours a day, you'll never finish all the items on your list no matter how efficient and motivated you are. So why bother putting all those items on your list for the day? You'll have to move it to another day.

Instead he advocates a to-do list that can be completed within your workday -- and that includes accounting for the unexpected problems that inevitably derail your schedule. It's a reality-based to-do list.

The closed list reminds me of the brilliant simplicity of the kanban in a lean production line. For those who don't know, a kanban is a signaling device (usually a simple card) that controls the amount of work-in-process inventory. When a person on a production line finishes his operation (grinding a piece of metal, say, or checking the credit scores on a mortgage application), he sends a kanban to the previous station. This signals that he's ready for the next piece of metal or the next mortgage application, and the upstream person then sends the next item down the line. For the purpose of this blog post, what's important is that the kanban controls the amount of work-in-process inventory: there can never be more inventory than there are kanban cards, so you never run into Lucy's famous problem of too many chocolates coming too fast down the assembly line.

Mark's closed list -- which is really the father of my principle of "living in the calendar" -- has the same benefit of the kanban in controlling the amount of work-in-process inventory. It prevents you from taking on more than you can handle in any one day, and thereby forces you to prioritize. You can't do more than 8, or 10, or 14 hours worth of work -- you have to decide what's most important, and ruthlessly weed out the rest (a la Jim Collins' stop doing list). It also creates a basis for a conversation with your boss when yet another "critical project" with an impossible deadline is added to your load.

The closed list doesn't reduce the amount of work you have to do. The truth is, that work is pretty much infinite. But it does force you to assess your work more closely, and helps you prioritize and keep you focused on what's really important to you.