Gemba Project Kaizen

December 4th, 2005 by Hal

Article Series - Project kaizen Co-Blogging

Starting tomorrow the gang-of-seven will be blogging on project kaizen. We are sticking to the same five themes day-by-day. You might want to know where those themes came from. (My six partners did!) The first theme is making the case for project kaizen. We decided to start with answering why do kaizen on projects simply because we don't find kaizen today in the project setting. What about the other four themes?

Here's a little background on how I've come to think of the four themes the way I do. Masaaki Imai wrote the book kaizen in 1986 that introduced and popularized kaizen. He updated the book in 1997 calling it gemba kaizen, meaning workplace continuous improvement. On my visit a few years ago to the Toyota factory in Kentucky I got to meet the plant manager. We asked about improvements. He said they don't consider improvements away from gemba. The idea has stuck.

As I've examined the circumstances for introducing project teams to kaizen I can't take my attention off the work environment, whatever that is. Getting ready for this series I started generalizing the gemba situations I've seen while working with a variety of teams. The four selected make a nice taxonomy. They are:

Workgroup
Workstream
Individual
Whole Project

I'm looking to test that taxonomy with the gang and with readers. We might find it's not complete. That would be great.

I've had the most questions about workstream kaizen. In the project world, specialists often work for different organizations, even different companies. They only loosely recognize themselves as being part of a team, let alone adjacent performers in a value stream. The term workstream recognizes that there are project performers whose work is dependent on others. Good project planning brings these people (or their supervisors) together to plan the work across the workstream. Good project management also brings the same people together on a frequent (daily) basis to provide the opportunity for the performers to declare what work they've completed or not completed and make promises of what will come next. This is done in a public setting that includes the performers in the workstream.

Here's a simple example:
In the construction setting, to get a finished wall it takes a series of trades operating in a predetermined sequence of work steps. It starts with someone laying out the wall and the location of items within the wall. This person might work for the general contractor. Next a carpenter frames the wall. Once enough lineal feet has been framed a plumber comes along and rough plumbs the wall. The plumber is followed by an electrician and a telecommunications person. Next the carpenter comes back and installs blocking and bracing in the locations where cabinets or fixtures will be hung on the wall. Next up, drywall is applied one side then the other. Another specialist comes along and tapes and muds the wall including sanding until a smooth finish is achieved. The wall is then inspected by the general contractor before releasing it to the painter. A primer coat and finish coat of paint are applied before the ceiling grid is installed. That is followed by bringing the carpenter back for finish trim and a flooring person to apply cove base or carpet base. The finishing touch is done by the electrician when coverplates are installed.

Most of these specialists are working for different companies. All of these people are impacted by the work of the people upstream from them. Small variations accumulate to the point that it is often impossible to say when the wall will complete. Improving the workstream — a complete wall — takes coordinated changes by a number of people in this mixed organization.

We can help in the adoption of kaizen if we speak to the working situation of the project participants

I called the example simple. Working in the interstitial space (above the ceiling and below the next higher floor) of a building is far more challenging. Improvements to putting that work in place often requires changing elements of the design. Software development is also complicated. As is product development, marketing projects, computer systems integration efforts, etc.

The construction example is a special case given the multiple companies, but we've all seen organizational fragmentation among project participants in corporate settings. My proposition is we can help in the adoption of kaizen if we speak to the working situation of the project participants. Workstreams are one of four ways people engage in work. Workgroups are another. The whole project is the third. And, people function in individual performer roles too. I think this is a complete taxonomy. If it's not, then we'll add to it later. From my experience it covers the vast majority of project circumstances.

When I visited the Toyota plant in Kentucky we always talked about kaizen in the context of gemba. We would walk to the location on the production line to examine what needed to change or had been changed. It is this idea of going to gemba that guides our effort this week. While gemba is always different from one project to the next, the four settings I've identified represent the classes of gemba that we can expect to find. Those different settings demand different practices for kaizen.

Help us out as we explore the various settings for project kaizen. What seems just right? What are we missing? What needs more attention? Please leave your comments anywhere among the gang of bloggers.

Gang-of-Seven

Project Kaizen Day Two

Jon Miller, Lean Leader

Kaizen and Safety Go Hand-in-Glove

Start Sharing Your QnEKs

Project Kaizen Co-Blogging Themes

This entry was posted on Sunday, December 4th, 2005 at 10:40 am and is tagged: lean, project kaizen. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed. Convert this post to a PDF document.

Social Bookmarking

2 Responses to “Gemba Project Kaizen”

Will Lichtig Says:
December 5th, 2005 at 12:13 pm
Hal,

What about the context that is broader than the project itself — how each of the individuals or work groups relates to the company to which it belongs? It would seem that this is the background or setting for Project kaizen.

While process kaizen may need to battle internal incoherence, say between manufatcuring and the accounting department, in projects this battle is “multi-front.” Unlike process kaizen, this context may be wildly different for each of the performers in the project setting. Without understanding the concerns of each performer in the context of its own organization will we be able to fully explore Project kaizen?

Just by way of example, if an individual company measures and rewards its managers based upon cash flow metrics, those managers might be incentivized to put work in place before the project is “ready.” Any effort to control workflow for the benefit of the project might run up against the realities of the non-project context in which we are operating.

If project kaizen is to be effective, do we need to explore these underlying concerns? If so, how do we incorporate this into the pracitce of Project kaizen?
Hal Says:
December 5th, 2005 at 1:11 pm
Will makes an important point. Even people from the same company can find themselves on projects where their bosses are measuring their performance differently from others on the project. The resulting incoherence impedes not just the opportunities for project kaizen. Incoherence also impedes the progress of the project.

It seems to me that project participants, certainly leaders, need to take responsibility for keeping coherence of intentions throughout the life of the project. I’ve written about coherence before. I’ll give it attention during the series.

Comment On This

If you haven't left a comment here before, you will need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.