Workstream Kaizen for Project Teams



By Jon Miller | Post Date: December 7, 2005 8:37 PM | Comments: 2

The topic for today is Workstream Kaizen. The word “workstream” has been in my vocabulary for less than three weeks. The more I come to understand what a workstream is in a project team context, the less I like it. Why? The very nature of workstreams generate waste and call out for kaizen. First let's define a workstream.

Our resident expert on project management Hal Macomber gave the Gang of Seven a good description of a workstream using the example of building a house. Even just to make a wall you need someone to provide a drawing, carpenters to frame the wall, plumbers, electricians and a telecommunications trades to do their work and a drywall crew to hang and finished the walls. The general contractor may inspect the work, followed by painting, trim, flooring and so forth. While a workgroup would be a team of framers, the workstream includes all of the people from various trades and companies required to complete the project of building a the whole house, across time and distance. This requires communication, coordination and hand-offs.

To paraphrase two of Kent Bowen and Steven Spear’s four points describing the Toyota Production System from their paper Decoding the DNA of the Toyota Production System, every customer-supplier relationship should make a direct connection and there should be a clear yes/no signal response to requests. If you've ever built a house or had one built, you know these rules aren't followed. A goal of workstream kaizen is to be able to follow these rules.

Part of the answer to how to do workstream kaizen in terms of building of a house can be seen in the video titled the 4 hour house. Teamwork, coordination and planning can eliminate many of the losses in a typical workstream of building a house. The same lessons can be applied to any project. The video certainly motivates and inspires, but does not instructional in great depth on workstream kaizen.

Another approach to workstream kaizen, again with building a house, comes from the steel frame modular home builder Toyota Home. I call it workstream compression. At Toyota Home the dozen or so "modules" that make up a house are finished in the factory on an assembly line with about a 6 minute takt time. Carpenters and electricians are working inside of a room that is moving slowly on an assembly line. Complete with andon lights, fixed position stop mechanisms, and sub assembly lines to moderate the effect of the extreme variation in assembly times, this factory is a marvel of TPS applied to high mix low volume custom work. If you can walk through a Toyota Home factory and still say "but we're custom" you had your eyes closed.

As a result of putting all of the trades on an assembly line, building the modules that make up a house complete with doors, windows, drywall, electrical, plumbing, and so on these modules (welded steel frame boxes finished as rooms) are installed on the construction site into an attractive, earthquake-proof two-story $250,000 house, in about eight hours.

The benefits of the Toyota Home construction system are that the house is not exposed to the elements very long since the work of putting the house up is done in a day. Just pick a sunny day. In addition, due to the land shortage Japanese homeowners tend to raze their home and "rehome" or build new on the same site. You don't want to spend months building a house while your family lives in a hotel.

The Toyota Home example takes the workstream and compresses it into a factory to radically simplify the work done on the construction site. Essentially the workstream is between the customer, salesman, factory and installation crew, rather than all of the trades normally managed by the general contractor. Even some of the supplier processes within the workstream have been "compressed" by bringing the supplier company (staff, equipment, and materials) under the roof of Toyota Home. So there's no transportation cost or inventory. The supplier builds a wood window on a subassembly line minutes before it goes in the module on the main line.

If everyone who was involved in project management was a fan of assembly lines like me, we could end here with workgroup kaizen. However in my experience many designers, knowledge workers, artists and crafts people abhor any suggestion of making their work resemble "production". American manufacturing has given assembly lines a bad name, so we have a duty to dig deeper and offer some more workgroup kaizen solutions.

If workgroup kaizen Toyota Home style is abhorrent or unimaginable to you at the moment the biggest impact you can have is to stop overproduction. Project team members can be specialists who hand off their work to others. They may be considered highly skilled resources that must be kept busy. Or the output of a team member may be measured at the task level rather than overall project output. Keeping busy may seem like a good thing, but Taiichi Ohno stated decades ago that overproduction is the greatest waste and it is certainly true for project teams.

Here I'll rely on a sports analogy by Bill Waddell to how people behave in a workstream:

"In a swimming relay, swimmer number two cannot leave until swimmer number one has completed his or her leg of the race and touched the wall. There is a clear, well defined handoff - swimmer one has an absolute, measurable distance to go; and swimmer number two cannot go to work until swimmer number one is finished."

But is this the way project team members really behave within a workstream? If so then workstream kaizen wouldn't be quite so tricky. In my experience what often happens is that swimmer number two is waiting for swimmer number one who has a cramped foot, but needs to keep busy so swims off to join a pick up water polo match. The resulting delay and shuffling of resources causes the typical cost and launch date overruns.

Multi-tasking, or having more than one project task open at one time is batching. You are creating inventory. When doing kaizen, you want to find inventory, ask why you have it, and attempt to get rid of it. When you make inventory (multi-tasking) you have added value and cost to each project task, but these unfinished tasks are sitting in process and you can not yet sell them and turn them into cash. They may or may not take up space in case of a software development project, but a house half-built certainly does. If assembling an automobile was a “project”, a supply chain would be a workstream. Just as inventories plague supply chains, multi-tasking and juggling projects. A goal of workstream kaizen should be for team members to be able to move from batching to one thing at a time.

Joe Ely asks on his bog "Just how many projects do the team members within a workstream have? Does anyone know? All too often they don’t." Part of my definition for projects is that they typically take more than a day. So it becomes important to understand what needs to be done each day in order for a project not to fall behind. With so many projects in work by the team members of each workstream, the question becomes "What is today's work?"

I don’t remember exactly who I heard it from but a Japanese manager in one of the factories we visited in southern Japan a few years ago said that one of the goals he stressed for everyone in his company was “Do today’s work today.” I remember feeling like I’d been knocked on the side of my head at the simplicity and power of this statement. But how many of us who are workstream members of a project even know what “today’s work” really is? A project team member within workstream may find their work today changed based input from another team member in the workstream. How many mornings have you had something in your e-mail inbox that completely reshuffled your priorities for the day.

Do one thing at a time. It sounds easy enough. Yet in a workstream your "one thing" may depend on the "one things" of many other people, and these people's "one things" on other people's and so on. It gets complex when you are separated by time and distance and your projects spans more than a day. Workstreams don’t promote this. We can’t just finish one project before starting the next one? It's human nature to keep busy and overproduce rather than wait. This is where the "compression" option starts to look sensible.

Workstreams, like supply chains, are by nature inelegant things. They are lumpy in some parts, smooth in others. Signals between parts of a supply chain or workstream tend to be less than clear and direct. The kaizen approach is to get at the root cause of why you need a project team (why there is separation between processes) in the first place. Why can’t the construction project flow one at a time, and finish in less than one day? Why can't there be clear and direct yes/no customer-supplier relationships throughout? Examine the various hand-off steps along the way. At various points where decisions can be made or changed, where work is started without clear instruction, information or customer input, there will be opportunity for workstream kaizen.

Read about what the other 6 bloggers wrote today about Workgroup Kaizen for Project Teams Hal Macomber, Norman Bodek, Chuck Frey, Joe Ely, Bill Waddell and Mark Graban on their respective blogs.

The Kaizen for Project Teams blog entries on Panta Rei are Making the Case for Kaizen for Project Teams, Workgroup Kaizen for Project Teams, Workstream Kaizen for Project Teams, Quick and Easy Kaizen for Project Teams, and Kaizen Blitz for Project Teams.

Good point on the swimming analogy, Jon. Ohno's example of a bad process is actually the best case scenario in most instances.

Poster: Bill Waddell | Post Date: December 7, 2005 8:52 PM

Like the term or not, the work of projects is not engineered like production work is engineered. The workstream, at best, is designed on the fly by the performers. But more often than not, the contracting process and selection of people to perform the various specialties doesn't discriminate such that the best team comes together, just a collection of people. These circumstances are the very reason why we need to bring kaizen to the design and functioning of the workstreams of the project.

Poster: Hal | Post Date: December 7, 2005 9:06 PM
Comments are moderated to filter spam and inappropriate content. There may be a delay before your comment is published.

Leave a comment