5S for Product Developers?

Things have been quiet on the blog for the last week as I've undertaken a major 5S project in my office. I don't normally recommend 5S and most of the time, it's an exemplar of how not to transfer lean concepts to product development. When I see others' presentations on lean product development, there is one slide that is almost guaranteed to get my dander up: Before-and-after pictures of engineers' desks championing the tool.

In English, 5S most often stands for Sort, Straighten, Shine, Standardize (sometimes Systematize), Sustain. The 5S entry in Wikipedia spells out 5S in Japanese. In a plant, 5S leads to outlines on the floor for specific equipment, cut-outs in drawers that hold specific tools and labels everywhere. Lean manufacturing gurus consider it to be one of the pillars of lean, and it is often the first thing done in a lean manufacturing transformation.

The biggest misguided abuse of 5S that I've seen are those who have tried to mandate 5S for individual engineers' desks or team workspaces. I can understand using 5S in model shops or prototype labs. There are born-organized engineers who seem to thrive on it. But there are others who will just resent the whole thing. Engineers hate wasted effort, and there is nothing more wasteful than putting everything back at night only to have to pull it all out again in the morning - if there is no discernible impact on anyone else. In fact, in the wrong environment, it can derail an entire lean product development effort by reinforcing the false impression that lean is all about standardization at the expense of innovation.

Some of the most creative, productive engineers have so many spare parts, test equipment, etc. in their cubicles that you wonder how they can get anything done. . .because they need all those things to support the experimentation that leads to such great product designs. After all, aren't we trying to encourage people to get direct, hands-on experience with the problems they're solving? It's hard to do that if the engineers feel like they can't get their hands (or their desks) dirty.

I'm a "get my hands dirty" kind of person myself. So how did I come to accept 5S for my office? My business has grown in the last year, and I've brought on a part-time assistant to help with administrative tasks. I have three products in the pipeline for summer that she will assemble and ship. Suddenly, half of my office is shared space and I have a microfactory.

Intuitive organizing no longer fits. For her productivity and for mine, we need some agreements about how the shared space will be organized. I still have private space that I am free to clutter or unclutter as needed but it's now confined to its own area that she will not disturb. 5S reminds us that organizing is just the beginning - we need to also keep the space clean and periodically reflect on how well it's working - that's the Shine and Sustain parts.

Where are the shared spaces in your organization? How can you empower the people who use them to organize them to maximize productivity for everyone? Where are the private spaces? How can you empower your product developers to organize their private spaces in the best ways that work for them?

Converting Skeptics with Consistency

Jamie Flinchbaugh of the Lean Learning Center in Novi, MI published a column Consistency Erodes Skepticism in Assembly Magazine this month.

Skeptics and naysayers can be annoying at best and destructive at worst, but Jamie reminds us that they play an important role in any change management process: "Here’s the great news about skeptics. When they do turn in your favor, they become a much more powerful force for change than you may ever be."

I especially appreciated his advice to take the time to learn from skeptics but to keep the team focused on making forward progress. The skeptics will come around when they see that the team sets achieveable goals - and then achieves them - consistently.

Information Pull vs. Push

Product development teams can quickly get buried in information, and it seems like the amount of information passing around grows exponentially the closer a product moves towards release. To help relieve the burden of information overload, I often recommend moving from information push to information pull. "Pull" is one of Jim Womack's fundamental principles of Lean because this simple concept permeates a Lean organization, including its information systems.

Push systems dump stuff on the recipient with no regard for when it will be needed. Email (especially those emails that include dozens of people on the cc: list) are inherently information push systems. As a recipient, I have no control over when or how the senders send information. I may have needed the information yesterday, or I may not need the information for months. No matter - it all ends up in my inbox where I have to figure out what to do with it.

Pull systems make stuff available to the recipient when the recipient is ready to receive it. Blogs are inherently information pull systems. I post content to my blog, and then with almost no intervention on my part, my readers can get this information when they want it in the frequency and form that works for them. Some want an emailed digest, others just want to visit the home page periodically via a bookmark. Those with RSS readers can subscribe to one of my feeds, and pull the content on exactly the schedule that works for them.

I lose a little control. When I post something, I have no idea when you receive it because it depends on your schedule, not mine. When I talk to one of my readers on the phone, I don't know whether or not they've seen the thing I posted that morning. It's a small price to pay for me to know that when you do pull the information, you have chosen to do so at a time and place that works for you. It's waste for both of us if I send you an email that goes straight to the trash so that you can get to the 499 other emails you received that day. Information pull systems also require that we assume that our recipients are grown-ups responsible for their own information needs. "I didn't get the memo!" is no longer an excuse when the memo was posted to the team's web site on time.

I'm not advocating that product development team members start blogs - although an internal team blog with its own RSS feed might be a good way to provide simple updates. I am suggesting that they think about ways to use their web sites and collaboration tools such as SharePoint® to provide information to people who need it at the moment that they need it in the form that works best for them. We use emails because it's the path of least resistance. It's quick, easy and we know that it will get at least a few seconds of attention before it's deleted. How can we create pull systems that are just as easy to use?

The Stand-Up Meeting

A stand-up meeting is a brief team meeting for communicating project status and raising issues with minimum disruption. Experiments with the Scrum method of agile software development were my first exposure to these meetings, and they've been a part of my own management process ever since.

These fifteen-minute quick round robins rapidly surface issues and keep the team on track. They provide daily accountability and improved coordination without overburdening the team leader. They help a team react quickly to changes, and stay proactive in a dynamic environment.

In these meetings, these are the only three questions asked: What did you do yesterday? What are you going to do today? What's in your way? The team leader records the answers (sometimes on a Visual Project Plan) and the team resolves the issues off-line. Team members stand up to emphasize that this is supposed to be a quick update, not an exhaustive narrative.

I just found an article that describes the mechanics of a stand-up meeting: It's Not Just Standing Up. It describes the attributes of a well-functioning stand-up meeting, and identifies some remedies for common problems such as lateness, over-running the time or digressing into problem-solving. I especially liked the author's description of the effective stand-up meeting's energizing effect on team productivity, and the various ways that a team leader can encourage the team to take more ownership for the meeting, which makes them run more smoothly.

Value Stream Maps in PD

I'm going to say something radical today: Most time spent on value stream mapping (VSM) in product development is waste. I saw an example of that come across my desk today: a beautiful VSM that a team had obviously spent a lot of time on - that told me absolutely nothing about the biggest things getting in the way of their product development performance.

Doing VSM in many product development organizations is like doing a three day kaizen event in a factory where the critical machine in the process is out of oil. I don't need a sophisticated tool, the whole production team or an entire day to see what the immediate problem is and recommend a solution: "Get some oil in the darned machine and put some changes in place to keep it from happening again!" If I took the analysis any further without fixing the obvious things first, the data I collected would only reflect the system as it runs while the critical machine is out of oil.

As a deeply experienced product development consultant, I've learned how to spot the "critical machines" and identify the problems that tend to get them backed up. I am remiss in my responsibilities if I insist upon leading my clients through any complex diagnostic tool when they've got something obvious that's clearly holding them back. That may meet my need for more personal involvement (and therefore more billing opportunities) but it doesn't meet my clients' need to achieve higher performance as expeditiously as possible.

I rarely encounter an organization that is truely clueless about the biggest barriers that keep them stuck at their current level of performance. Finding the issues is the easy part. It's harder to prioritize the challenges, and to identify solutions that will create sustainable high performance, and stick beyond the pilot program. That's where I have the opportunity to add the most value, and so that is where I focus.

Steve Jobs as Apple's Chief Engineer

This article from MIT's Technology Review describes the role that industrial design plays in Apple's product development process. One quote highlights the role Steve Jobs has played in reinforcing Apple's dedication to well-designed products that do exactly what the customer wants - no more.

"Critical to Apple's success in design is the way Jobs brought focus and discipline to the product teams," Norman says. "[Jobs] had a single, cohesive image of the final product and would not allow any deviation, no matter how promising a new proposed feature appeared to be, no matter how much the team complained.

The ability to define and then maintain the "single, cohesive image of the final product" is the distinguishing characteristic of a true Chief Engineer. If you ever ask yourself whether or not every development project really needs one, just look at the success of the iPod, iTunes and the resurgence of the Mac

Target Costing must be in the air

I've been catching up on my reading about Target Costing - researching tools for an existing client and refreshing my knowledge as I create a proposal for a new one. This is an area within Lean Product Development that hasn't received the same level of attention as the A3 report and set-based concurrent engineering, probably because reducing product cost is not nearly as exciting or glamorous as cutting time to market in half.

However, it's an area that a product development manager cannot afford to ignore - Toyota certainly does not. The tools required to effectively manage cost include things such as conjoint analysis to understand the relative value of specific product parameters, cost modeling to make the cost implications of specific decisions more visible, and value engineering to drive out costs at the system level. Underlying it all is a mechanism for accurately predicting product cost and then monitoring changes as the new product moves through the development cycle.

My new client has used Target Costing by M. Bradford Clifton et al as their guide. I find it to be a nice introduction with good descriptions of the basic tools.

I've just been invited to speak at the Lean Accounting Summit this September in Orlando, Florida. I'll present "Lean Accounting for Product Development" which will provide an overview of the financial information that product development teams need to effectively manage product cost during the development process. I'm looking forward to more interaction with this dynamic community. I think it may represent the next frontier in lean product development.