Report from the IIR Lean Design & Development Conference in Chicago

I thought that I would have a lot to write about the IIR conference in Chicago. I was wrong. It was disappointing to me, and I've been unsure what to say about it. Last year's experience was such a positive one so I had high expectations going in.

A little background: IIR lost their conference coordinator in the middle of conference organizing, and had to fill in with new people. Their marketing campaign got off to a slow start and attendance was low, so they had to consolidate the agenda and ended up cancelling speakers. However, they didn't consult ANYONE in the Lean Product Development community when they decided whom to cancel. In fact, they almost cancelled Durward Sobek (the guy with the most direct insight into Toyota's product development system) until I got wind of it and called them to complain -- loudly.

As a result, 9 of 21 presentations had everything to do with Lean Manufacturing and nothing to do with Lean Product Development - and some of the others had only the most tenuous links to NPD. I had hoped that the high numbers of practitioner presentations would make it a stronger conference - but they cancelled the speakers who would have been able to contribute that perspective.

On the bright side: there were three presentations worth the price of admission. Durward gave a fantastic talk on A3 thinking. I may be a little biased here, but it seems like his message gets clearer and more on-point every time he speaks. Mike Shipulski, Director of Engineering at Hypertherm gave a dynamic talk about his efforts to get his engineers to reduce part counts, taking "go-and-see" to new heights for the engineers involved, and reducing assembly time from ten hours to one hour for one product. Jay Mortenson, former CFO of RexNord shared a clear and succinct introduction to target costing.

Another bright side: Bretford donated the use of some rolling whiteboards so that I was able to show my Visual Planning demonstration. I love how they demonstrated just how flexible a Visual Planning system can be.

Since I consider myself fortunate to get one or two things to take away from a conference like this, it was a worthwhile experience for the attendees (including me) despite the problems.

The best thing to come out of this may be the plans that Tricia Sutton, Durward and I began cooking up for a "Lean Product Development" summit sometime next Spring. This would be the conference that we'd hoped to have. In our vision, the conference would draw from our client lists to deliver carefully-chosen practitioner presentations that reflect real-world experiences implementing the Toyota Product Development System, and workshops centered on the elements of the system, like set-based concurrent engineering, chief engineers, target costing and visual knowledge.

Unproductive Meetings and Waste

How much time do you spend adding customer value? What do you do the rest of your time?

If you are like most product development folks, you spend a lot of your time in meetings. Yet it amazes me how often I walk into a company that claims to understand lean which is still using "batch process" meeting management:

• Standing meetings at a specified time to cover a wide range of topics.


• Decisions that get revisited because the wrong people are in the room when the group makes a decision.


• Presentations that take hours to prepare, only to get short-circuited when the team runs out of time (or the wrong people are there).


• People who are there merely to receive status updates because otherwise, there is no way for them to get the information they need in their jobs. You can recognize these people in a technology company by the ratio of time spent talking to time spent answering email or surreptitiously surfing the Internet.


• Meeting schedules that are so full that there's no time for informal "hallway conversation" or meeting preparation.

Meetings are one of those things that respond well to traditional lean thinking, especially the concept of one piece flow. Why do we batch up our issues and decisions for once-weekly team meetings or once-quarterly project reviews? Why not simply take care of them as they arise?

I coach the teams I work with to use "one piece meeting flow" - one topic per meeting - for everything except status updates. A "one piece meeting" includes everyone who has necessary input into the decision at hand - and no one extra. The organizer sends an A3 or similar brief report ahead of time with the expectation that the attendees will read it in advance. There is no opening presentation because everyone already knows why they are there, and what they need to contribute. There is no time for email because everyone is engaged in the discussion from the beginning of the meeting. At the end, the organizer updates the report with the meeting's outcome and forwards it to all the people who need to know.

For status updates, I like stand-up meetings that last no longer than ten minutes per day, or a half hour once per week. That is just enough time to get progress updates from the team, but not enough time to get bogged down into issues that should really be solved in a "one piece" meeting.

Set-Based Concurrent Engineering: Lean Friend or Foe?

Set-based concurrent engineering (AKA set-based design) is one of the more intriguing and difficult-to-explain practices that Toyota uses in its product development process. Set-based concurrent engineering is a technique for resolving design issues that explores a range of alternatives simultaneously. Over time, those alternatives converge to a final solution. When design decisions cross boundaries, multiple subsystem teams may work concurrently to explore alternatives, meeting up at integration events to evaluate their progress from a whole system perspective.

On the face of it, it seems anti-lean: pursuing multiple alternatives at once, delaying specifications, insisting that downstream partners operate with incomplete information, spending more money on the front end in the hopes that the back end is less expensive. From the perspective of a part design, it sure seems wasteful.

Meanwhile, the research shows that this is one of the most powerful weapons in Toyota's PD arsenal by eliminating a ton of rework in late-stage development. It is also one of the most difficult for lean product development organizations to adapt. Unfortunately, I've seen badly-implemented SBCE derail an entire lean product development effort.

There are two problems that I see in Lean Product Development implementations with respect to SBCE:
--Assuming that the alternatives that don't end up in the product are waste, and refusing to consider it.
--Rushing into it too quickly before the team has a good grounding in lean problem-solving and decision-making.

The way to avoid the first problem is to remind people that the product design is the value that flows in product development. SBCE strengthens the design, making it more robust to changes late in the design process. The way to avoid the second problem is to start slowly. Use convergence techniques on small, isolated problems before trying to solve full-scale system-wide problems. And get some help from someone who's done it before. This is one area where a few days spent with a guide can pay big dividends for the team.

A3 Reports in Product Development

I don't believe that there are any silver bullets in product development. However, Toyota's A3 report is the closest thing I've ever found.

An A3 report is a document written on a single sheet of 11" x 17" paper. Writing one forces the writer to distill things down to the critical elements of the subject matter, and focuses the reader's attention on the most important information. The paper size is large enough to include a significant amount of information, but not so large that the reader cannot take it all in at a glance. Pictures, diagrams, charts and other visual models replace words wherever possible to enrich the communication.

A3 reports immediately improve communication in a product development team by making team members' thinking visible to others both inside and outside the team. When used as a substitute for traditional slideshow presentations, they streamline meetings and increase the ratio of useful discussion to reviews and updates. As a problem-solving tool, they help structure the team's approach, and as a decision-making tool, they provide the key stakeholders and decision-makers with the information needed to get good input and a decision that will stick.

There are three reasons why A3s are so effective. First, the format requires conciseness and focus. The author will not be able to fit every possible piece of information on the page and so the important information stands out. It is much less daunting to scan an A3 report prior to a meeting than it is to read a report or review a slide presentation. Second, A3 writers learn quickly that using pictures and other visuals increases the amount of information they can fit on a report. The side effect is that these visual models foster richer discussion than text descriptions. Finally, all of the important information stays in front during the discussion - unlike slide presentations where each slide covers the information from the previous slide.

These characteristics lead to richer discussion and faster decision-making. That leads to less time spent in meetings reviewing and revisiting decisions, and more time available to add customer value.

In my approach to A3 writing, there are only three requirements: each A3 report must include a title and theme statement that succinctly describe the A3's topic, the author's name and contact information, and a references section for citations. The author uses the rest of the page in any way that best conveys the message. i do have some templates available on my website in the NPD Resource Center but they are only a starting place.

Time-to-Market for Innovations

There is one measure of time-to-market that is critical for any product development organization: time-to-market for innovations. That is, how long does it take for a truly innovative feature that directly impacts customer value to become part of a product that a customer can buy?

Some of the things that we do in product development to speed time-to-market (platform-based development, standardized work for development and testing, partner co-development) can actually hurt this metric, by making it much harder for new technologies to make their way into the product stream.

There are three different ways to manage this risk:

• Develop advanced technologies off the schedule for new product development, and incorporate them into new products as they mature. This mitigates the risk that an innovative feature will need to be removed from a product late in the game to maintain schedule or simply because it's not ready for prime time.
  
• Provide a "waiver" process to selectively exempt products from platform requirements, so that platform-based products will have a little breathing room to incorporate innovations without putting the entire product family at risk.
  
• Use standardized work appropriately - which means that the people doing the work create the standards, continuously seek ways to improve them and recognize the situations where the standards make no sense. In those cases, provide a means for disregarding the standard if the team can create a strong business case for doing so.