Why people observe but don't see Lean

Why people observe but don't see Lean

I've wondered for a long time why people seem to ignore or not seek to understand Lean. I got some insight last week when management writer Jeff Angus wrote on why humility works. His subject was Terry Ryan, a little known, understated but highly successful executive from Minnesota. Here's the salient summary of Jeff's observations:

There's also intellectual humility. He [Ryan]works very hard to make [success] look ordinary. That, of course, is a competitive edge...competitors in any endeavor figure anything easy must not be a very important differentiator (bass-ackwards of course, but the erroneous mental algebra is that if it was important and easy both, everyone could/would do it and since they're not doing it and it's easy it, therefore, must not be important. Goofy but widespread thinking). As long as Ryan and his team make this seem like luck or just simple stuff, others won't feel like they're being outfoxed (which is not an incentive to deal with the fox again).

And the managers[who work with Ryan] know that they can make mistakes...by acting and being humble, they never get too comfortable with problem --> solution automation, continuing to practice self-examination, continuing to see if their decisions are working. A further side-benefit: this knowing-you-can-make-a-mistake diminishes (not eliminates) the office politics of assigning blame -- everyone knows that mistakes will happen and it defuses a lot of the harsher toxicity of office blame.

Jeff writes about a management principle in general. But it hit me that this is a reason for the dominance of folks who can really drive a Lean system. Those who do it well make it look very easy. The improvement efforts, the involvement of associates, the self-funding of new products; it all seems to flow. And the usual reaction is “Yeah, it’s common sense.”

As Jeff says it takes intellectual humility to get it. My colleague Kevin and I talked about this late this afternoon. It takes a willingness to accept the utterly elegant simplicity of a Lean mindset to make it work.

I hope you can find that humility. And “get it” even better.

Christmas Eve, 2005

Christmas Eve, 2005

Once a year, I take the opportunity to make some personal comments. Thanks for indulging me a move away from what I hope is normally a professional approach!

It’s fascinating to look at my comments on Chrismas Eve of 2002, 2003, and 2004. Things progress and grow. And some things remain the same.

We were thrilled in late July to have our son David return safely from his tour of duty as an Army medic in the Sunni Triangle in western Iraq. Words don’t really capture what we felt to have him there and the joy of his return. He, Susan, Nathan and Andrew are now together, stationed in Colorado Springs, spending their first Christmas together in three years.

Our middle son Nathan is really finding a niche in Human Resources in Portland, Oregon. Hard to believe our youngest Matt is deep into planning for college. But I guess the math works, as Gretchen and I celebrated our 30th wedding anniversary this year. Oh my.

I remain very grateful for my Dad, who died 12 years ago today. The values and insight I learned from him will never leave. I hope I’ve passed those same values on to my sons. I’m a very fortunate guy.

Where will 2006 go? Don’t we wonder about that every year?! To the degree that we each focus on others, apart from ourselves and seek to serve in the worlds we find ourselves, we will have opportunity.

I’m grateful for Immanuel, God with us, as we celebrate the birth of Christ tomorrow. This faith undergirds everything for me. It is an exciting and humbling journey.

Merry Christmas to you and yours.

Project Kaizen: Day Five

Project Kaizen: Day Five

Wow, quite an amazing week of blogging on Project Kaizen. I was discussing this exercise over supper with my mother-in-law tonight. In her early 80s, she is very up on technology and has been following our discussions all week on-line. “It is a pretty amazing world,” she commented “when such a cool thing can happen. And it has been neat to learn about kaizen!”

She’s right…it is amazing. And let’s not take it for granted. From any background or perspective, anyone who wishes can learn. And the seven of us owe a debt of gratitude to all of our readers.

Hal will soon be posting some compilations of our postings. You can catch this announcement on Reforming Project Management; I’ll mention it here as well.

I’d welcome any summary comments from our readers. Post them here in the comment section or feel free to email me. The input from our readers is wonderful.

Thank you for listening and having a mood of optimism and inquisitiveness.

Project Kaizen: the Kaizen Blitz

Project Kaizen: the Kaizen Blitz

The Kaizen Blitz or Kaizen Event is a technique that our own Norman Bodek was instrumental in demonstrating for the first time here in the US. At that time, they called it “Five Days and One Night”, indicative of the fact that four of the five days of work allowed for no sleep, at least symbolically.

I first learned how to do a Kaizen Event during a fateful week at Wiremold’s Brooks Division in Philadelphia. They invited me, an outsider, to fully participate with them as “fresh eyes” for the event. They did far more for me and my company than I did for them…it was truly one of the most influential weeks of my entire career.

I’ve since participated in and led a lot of Kaizen Events. I always (and I do mean always) learn something new and significant. And the more I do them, the less I realize I know. This business of relentlessly eliminating waste is a very humbling exercise.

I have thought a lot about how to describe a Kaizen Event in the context of a project team. I’ve come to the conclusion that it would be close to impossible to do in a loosely coupled team as Hal described one. I had the chance to do this once. A very talented leader took us through a week-long event with four different companies, all involved in sequential supply to one another. We documented, conservatively, $11M of cash savings to be had in six months with no capital investment. And it went nowhere. There simply was not the shared belief or trust or dependence to make it happen. A major disappointment, to say the least. The lack of “coupling” between the parties destroyed any chance of success.

To do a Kaizen Event in a workgroup or a closely coupled team, however, would be much like doing an event in single work cell. It takes some planning and leadership. And there is no way to learn to do this without actually being a part of it in practice.

George Koenigsaecker, along with Norman, is one of this country’s most seasoned Lean leaders. In his recent article Leadership in Lean Transformation, (thanks again to the Society of Manufacturing Engineers for this publication) he describes how one learns to lead a Kaizen event. In short, you have to watch it and do it. And do it. And do it. The article will help you understand it.

Why is it hard to learn to lead a Kaizen event? Because it turns most conventional logic on its head. You have to experience it to grasp it. You can make big changes quickly. It is exciting. It is boring. You will freak people out. You will threaten others. You will learn more than you ever imagined you could learn. It is a project that accomplishes so much in so little time, you will be breathless. And others, being threatened, will seek to undermine it. And you.

If you have been involved in a Kaizen event, you are smiling and nodding now in a knowing sort of way. If you have not, you are probably looking for a hyperlink to click and move away from this senseless text. But if, by chance, you are still with me I encourage you to read what my cobloggers have to say on the subject. And, then see if you can participate in a Kaizen Blitz. Somewhere. Somehow. I wish I could make it easier for you. But I can’t.

And your project team will never be the same.

Read my friends’ comments on this today.
Gang-of-Seven
Bill Waddell
Chuck Frey
Hal Macomber
Jon Miller
Mark Graban
Norman Bodek

Project Kaizen: Day Four

Project Kaizen: Day Four

I’ve tried to put together a summary of our Gang-of-Seven’s inputs each evening for you. Today, though, Chuck Frey already did it! His is a great summary, so enjoy it!

I have to go dig out of six inches of snow…see ya tomorrow!

Project Kaizen: Rapid Improvements for You!

“My life is a pain. How do I make it better?”

No, this isn’t a lonesome lover’s blog (just in case you were wondering…). Our discussion on Project Kaizen moves today to the individual.

The most significant work on this topic comes from Norman Bodek, particularly captured in his excellent book subtitled Quick 'n Easy Kaizen. I got this book when it came out a few years ago, applied it, verbatim, and it is superb.

The essence of Norman's work is captured by writing down the completion of two simple and then taking two simple actions:

I currently have a problem with …

I could improve this if I ….

Write it down.

Show it to others.

And this is the kicker. Lots of our folks know how to improve their work, to make it more enjoyable. Yet, writing it down is downright difficult.

So, I humbly present my Top Ten List of Why to Write Small Local Improvements.

1 Writing forces you to think.
2 You capture the problem or at least a part of it.
3 You learn to see more clearly by writing.
4 You help others see your world.
5 You find a practical, incremental improvement.
6 You show that saving 30 seconds a day is a good thing.
7 You build a history of improvement.
8 You can measure your focus on improvement.
9 You learn from the attempts that don’t work.
10 You get involved in your work world, rather than just passively accepting life as it is.

Make it a habit:

1. Make a simple, half-page form with these questions on it.
2. Write two local improvements today.
3. Show both of them to two co-workers. Today.

Read my friends’ comments on this today.
Gang-of-Seven
Bill Waddell
Chuck Frey
Hal Macomber
Jon Miller
Mark Graban
Norman Bodek

Project Kaizen: Day Three

Project Kaizen: Day Three

Three days down on this exercise on Project Kaizen. I mentioned handoffs as key in understanding a workstream. Bill Waddell took this concept much further, describing handoffs in the workstream, using a track example.

And, lest we forget, people matter most. From Tuesday’s postings, Jon Miller examines just how well (or not) we seven bloggers practiced what we preach. This type of robust conversation is an example of what a good project team gets to. Kathleen offers another take on networked conversation and the key role they play in improvement.

On Thursday…individual kaizen. I’m looking forward to that!

Project Kaizen: Making the Workstream Flow

Our week-long study of Project Kaizen gets tough today: How do we regularly improve a workgroup that spans different companies?

The workstream is different than the workgroup. It usually involves people who don’t know each other, work for different companies, have very different allegiances and are united (often) only by the project. Hal Macomber wrote well on the distinctives of a workstream last week if you want to understand the distinctives better. .

Examples abound. Most outsourced issues are workstreams. Building maintenance and cleaning. Most construction projects. Many contract technical evaluations. Funded research. Very different from the workgroup. Yet, often the source of a lot of cost to a company and a basis for improvement.

In very large companies, many projects also become workstreams for similar reasons. Mark Graban speaks on this phenomenon from personal experience.

My fellow bloggers (Bill Waddell, Chuck Frey, Hal Macomber, Jon Miller, Mark Graban, and Norman Bodek) will cover this well. These guys see it more than I do. I’ll simply contribute some of my observations from my experience.

Workstream kaizen is much harder than workgroup kaizen. Deal with it. Don’t have expectations that things will happen as fast or as well or as deep as workgroup or individual kaizen.

The relative size of the organizations have a big impact. If you work with a vendor who really, really needs your business, you can make some headway. If you are a twig on the end of a stick on the tip of a branch at the split of a trunk of a very big tree to the other entity, well, it’ll be tough.

Pay close attention to the handoffs in a workstream. What happens when the project work shifts from one group to the next? There is your prime opportunity for improvement. Simple meetings, clear statements of satisfaction, declaring a job finished, metrics for handoffs; all of these work.

So how can you improve the workstream if you are the twig and not the tree trunk? Try what I call a “one-sided” kaizen effort. Make things happen for your side of the transaction. Don’t expect any reciprocation. Do pull, even if they don’t cooperate. Do mistake-proofing, even if they don’t ask about it. Do visual management, even if they don’t see.

My good pal Ken Kellams and I learned this approach with a number of vendors during my days at FBi Buildings. What was amazing to us was that, after a year or so of consistent effort (solely on our part), several of these outside entities said “Hey, you guys are doing something different.” We explained. A couple actually adopted our lean practices. Ken told me a month ago that one vendor adopted lean tools and increased his total inventory turns from 5 per year in 2002 to 14 per year in 2005. Given that this vendor was landlocked in his facility, this nearly tripled his capacity. With no capital expenditures. Guess who gets good service from that vendor?? Ken’s a happy man.

It is possible to improve workstreams. Read up from my blogging pals. Try something and measure the results. You may well surprise yourself!

Make it a habit:

1. Identify one or (at the most) two workstreams.
2. Identify two handoffs for each.
3. Find some improvement on each of the handoffs.

Project Kaizen: Day Two

Lots of awesome input today. Two things really grabbed me from today’s posts and links on Project Kaizen.

First, Bill quotes my web pal Karen Wilhelm On Project Kaizen. Karen works at the Society of Manufacturing Engineers, is a frequent commenter on this blog and tolerates my poor grammer and weak logic in a very patient fashion. Karen edited a marvelous paper on Quickening the Pace of Product Development which is worth your read. Among other things, this paper includes a wonderful example of what project metric displays should look like. I’ve been searching for this and it only came to me today. Thanks Karen…you are welcome to make my blog look that good any day!!

Second, I discovered Kathleen Fasanella’s wonderful blog Fashion-Incubator. Those of you who know me will think it a good thing that I read a blog on “fashion.” Alas, the mismatching shirts and pant will continue. Kathleen is a marvelous writer on how systems and people interact in her world, the production of clothing. She wrote last week the most marvelous description I’ve ever read on why improve a process that is working OK. Complete with illustrations. Go read it. You’ll get it. Thanks, Kathleen, for jumping in. I learned a lot.

Gotta head for bed…more projet kaizen on workstreams tomorrow.

Project Kaizen: Single Piece Flow in the Workgroup

Project Kaizen: Single Piece Flow in the Workgroup

A workgroup is just that; a group that does work. More importantly, though, a workgroup is usually a somewhat constant group. The individuals likely know each other, are often get paid by the same entity and have some generally shared objectives. It is one of the most obvious contexts for project kaizen. Examples are easy to see: A research group, a purchasing department, a construction crew, a software team, a maternity ward staff.

Projects happen in this context. Complete a research paper and submit. Find a new vendor for welding rods. Improve on-site safety performance. Add two new features to version 4.5. Find a way for siblings to visit Mom and new baby.

A project in this setting has the advantage that the people are already there and may have a shared interest. The problem is that these people also have regular work to do. They also have history, good or bad, with each other. Project success has to account for each of these things.

Kaizen here means;

Identify the project
Account for loading
Lead
Eliminate multi-tasking
Communicate simply.

I remain fascinated at how many projects workgroups take on without even knowing they have done it, almost as if they contract a virus, unawares. It is in stating, clearly, the name and objective of a project that success starts.

Which leads to loading. Just how many projects does a work group have? Does anyone know? All too often they don’t.

I mention “Lead” third, because it is only after identifying the projects and being aghast at the subsequent overloading that Leadership can really happen. Before that, most of us consider it only so much meddling. But who else can help a workgroup better than the leader? And who else can really say “we will do this” and “we won’t do that?” And then, by making that declaration stick, who else can truly communicate priorities?

The most crucial task for the Leader is to rid the group of the curse of multi-tasking. The Leader must replace it with single piece flow. I believe this is the most foundational priciple of workgroup improvement strategies.

And you laugh.

Most folks in workgroups simply do not believe they can ever get to single piece flow in the project setting, that sweet spot where they see a task through to completion, without interruption, without pause, without distraction. Kaizen begins when the workgroup leader declares “Yes, we can get to single piece flow. What is the first step?”

How do we get rid of multi-tasking?
First, decide to do it.
Second, break big tasks into smaller tasks.
Third, make each individual task for a person something that can be done in 90 minutes or less…preferably 45 minutes. This may make for a long list. Stay with it.

Describe each task in the form “Verb the Noun with Tool by Date/time.” For example: “Write the supplier specification in MS Word by Tuesday noon.” “ Mail the proposal to Marcie at Acme on Friday by 9am.” Don’t list the task as “Supplier Spec” or “Proposal finished.”

Discover when, each day, individual work group members can best concentrate and work. Some are morning people, some late night candle-burners. Accept this as part of the joy of a diverse workgroup and embrace it.

Let people work odd hours, when it is easier to be uninterrupted.

Turn off email for a period of time. Yes, you heard right, turn it off. There is life without email. My grandfather told me so. Turn it off while you are working on a project. It will all be there when you come back. If the task or sub task takes only 90 minutes, you won’t miss much.


In the workgroup that is physically located together, a great tool is the Project Poster. This is a visual tool at which the project team who are can interact.

Method:
Make it big. At least 3 x 4 feet. Yes feet
Make it change. Add something new, daily.
Meet, with your project team, standing, next to it. Frequently. Daily, if possible.
Put names on it.
Make project metrics clear. An easy one is “finished 90 minute tasks.” You can make this a Plan to Actual metric as well. Then look at the percent plan complete.
Don’t make it “nice”…do it in hand writing.
Encourage others to write comments on it.
State when the project is done. Then take it down, replace it.

By focusing on a single project, breaking down tasks and making it visible, you can see better how to get to single piece flow. And dramatically improve both the performance and the results of projects in the context of a workgroup.

Get in the habit:
List the projects in your workgroup.
Buy a “science project display”, the tri-fold sort of thing that kids use. Set it on a table near your work group. Populate it.
Measure how many times in a day you and your workgroup finds interruption to single piece flow. Reality hurts…and it is a beginning.


Check out what the rest of my co-bloggers have to say:
Gang-of-Seven
Bill Waddell
Chuck Frey
Hal Macomber
Jon Miller
Mark Graban
Norman Bodek

Project Kaizen: Day One

Project Kaizen: Day One

Our Gang of Seven is off and blogging on project kaizen. Several emails reminded me I’ve left some folks in the dust!! Kaizen is a Japanese word that means “continuous improvement.” In practice, it is about a steady flow of small changes to make work more enjoyable, smooth and waste free. You can apply it anywhere (as my kids groan, having noticed). Our intent in this coblogging exercise is to apply it to the world of projects.

Two things strike me this evening, as I reread today’s entries.

Hal wrote on a familiar theme to us who know him: being mindful of your surroundings and, importantly, being mindful of how to improve those surroundings in the project setting. Mull on this one a bit.

Norman produced a very useful piece on Running Effective Meetings. Oh my, how projects could improve with just this discipline!

Tuesday, we all take on kaizen in the workgroup. Join us!

Project Kaizen: Why improve Projects?

Project Kaizen: Why Improve Projects?

Marie had a problem. Why was the supplier slow? Why did they miss promised delivery dates? Why were there quality problems with this vendor? How could she get the design improved? How could she evaluate alternate designs? To do this, she had to involve the vendor, sales people, engineers and production staff. She had a project. She could apply project kaizen.

Scotty had a problem. Organizational changes meant a product previously made elsewhere was coming in-house. How did he locate supplies? How did he modify standard work? How did he let end-users know where to order? How did he find the manufacturing space? To do this, he had to involve production engineers, customer service and sales folks, shipping team. He had a project. He could apply project kaizen.

We often solve problems by initiating a project. And since there seems to be no shortage of problems, we are surrounded by projects. Even in a process based system, projects are everywhere. So, why not get better at them?

A project is different than a process. A project is a one-off event. It has a start and an end. It often involves a variety of tasks. Many depend on other. Often, the project has multiple performers. It almost always affects multiple people.

Projects originate from multiple headwaters. Most often, they come from a) top-down demands (the big guy issues a declaration) or b) bottom-up “gotta improve this” demands (this process is impossible to do).

Often, we don’t see projects for what they are; one time, time-consuming events. Instead, we pretend they are a potted plant in the corner, there, but of no real significance. So we pile them on top of other, regular work. And then we wonder why we feel overloaded.

Projects are central. No less a guru than Tom Peters wrote a book The Project 50 to show just how crucial our projects are. While Tom ranted well in this book, we can do better in making them work better.

Projects happen in four settings. We’ll talk about each. But get started now.

Get in the habit:
1. Identify, in writing, three projects for you or for others that you come in contact with in the next four hours.

2. Write down 4 things about each one: The start date, the end date, the person responsible and the person who has the power to say “I am pleased, the project is done”.

3. Use this short list as your context to understand what my cobloggers and I will discuss this week on improving projects.

Check out what the rest of my co-bloggers have to say:

Gang-of-Seven
Bill Waddell
Chuck Frey
Hal Macomber
Jon Miller
Mark Graban
Norman Bodek

Project Kaizen: A Co-Blogging Adventure

Project Kaizen: A Co-Blogging Adventure

This week, I’ll be joining six fellow bloggers to discuss one topic: How do we apply lean principles to improve the process of projects? How do we bring kaizen to projects?

All of us are deeply involved in continuous improvement. And while kaizen is reasonably well known (if not well practiced) in processes, it is very much unknown in the project setting.

There are four settings in which projects happen; each of them have a context in which we can improve them. On Tuesday through Friday, we’ll discuss each of these settings. On Monday, we’ll all lead off with asking “why bother with kaizen in projects anyway?”

My buddy Hal Macomber, a regular referent from this blog, initiated all of this out of his passion for excellence in project management and recognition of the need for kaizen in the project setting. I’m really humbled to be included in this discussion group, as some outstanding writers and thinkers will write along with me. I’ve added links to this “gang of seven” on the side of my blog here. I’ll include links with each posting as well. Our objective is that the mix of writing on one topic from seven points of view will add significantly to the understanding (and more importantly) the practice of improving projects. I urge you to follow the links each day. Please comment at any or all of our postings. If you have a blog, feel free to pick up on any theme that strikes you; include the words “Project Kaizen” in your blog title and folks can follow it as well. Hal promises a compilation of our writings and relevant comments in the next month or two.

Here’s a list of the other contributors and Hal’s introduction of each:

Hal Macomber, Project Reformer
Norman Bodek, Godfather of Lean
Mark Graban, Lean Commentary
Bill Waddell, Lean Provocateur
Jon Miller, Lean Leader
Chuck Frey, Innovation Maven

And…we’ll add one more blogger each day. It might be you! We’ll scan the other blogs keying off of our posts and one will be included in the Gang of Seven.

Hope you enjoy this exercise…and more importantly, it moves your projects along better, with less waste.




Feel free to forward to a friend. Email me