If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

To optimize for client value — the promise of the project — rather than for whatever it is that you do requires understanding where there is a limitation in the value stream. We learned that lesson from TOC. All other improvement is only local. While all improvement may be good for acquiring an improving habit, it is only when we improve at the area of the constraint that throughput increases. Just working on the constrained step with those people who perform that step may not lead to improvement in the whole process. To get a performance gain in your work might require that I change what I do. This is done on projects in the workstreams.

Let's look at two extremes of workstreams: loosely-coupled and tightly-coupled. In the loosely-coupled workstream people perform their project work with very clear boundaries and buffers between the work steps. Performers in the workstream act as detached customers of others' completed tasks. In the tightly-coupled workstream performers work hand-to-hand as each person adds to the work of the other until a product is completed.

Work can be designed for either loose or tight coupling. Let's use the example of build a wall from my earlier posting. The steps in the process could be performed one day (or more) after another without performers being in contact with each other. In this situation they don't recognize themselves as part of a workstream team. These people function as specialists who have a function to perform, then they move on. In a loosely-coupled workstream people have their attention on their own productivity, work standards, and work methods. At best, people tend to understand that what is good for me must be good for the project.

In the tightly-coupled workstream people are working proximate to each other. There may be physical hand-offs. In this situation there needs to be a matching of level of staffing from one specialist to another so the work flows and people are not standing around waiting. The tightly-coupled workstream also requires less variability throughout the process.

Without getting into why we might design a workstream one way or another, it is clear that doing kaizen in the two situations has to be different. In the loosely-coupled example someone has to take the initiative to convene performers across the workstream. That may require a special meeting. It probably requires some level of authority or permission to do that. If the performers are strangers, then relationships need to be established to build enough trust where people will learn from each other and contribute to each others' ideas. You can count on this taking time. You will also need to keep bringing people back together to evaluate proposed solutions, track experiments, and plan implementation.

In the tightly-coupled situation the group starts by knowing each other. They probably take breaks together. They certainly have the opportunity to see each other in action. Working on a problem or examining an opportunity might happen by someone stopping the line to point something out to another performer or all those in the workstream. In this setting almost anyone could be the leader. This team can experiment with their work and track their progress in the space they work.

In practice you will find project workstreams lie somewhere on a continuum of coupling. Your approach for doing project kaizen needs to fit the circumstances. Workout that approach with the participants in the workstream. Experiment, learn, adjust, and experiment again.

Gang-of-Seven

• Bill Waddell
• Chuck Frey
• Hal Macomber
• Joe Ely
• Jon Miller
• Mark Graban
• Norman Bodek