Impedance in the Knowledge Flow

What things impede knowledge flow in your organization? Where are the places where knowledge flows - just not as quickly or as clearly as it could? Here are the top 5 sources of knowledge flow impedence I see in my travels. Which ones apply to you?

• High Noise - Low Content Communication Channels: Over-reliance on communication channels that tend to hide or distort information. These include audio-only conferences (especially those done late at night at the kitchen table to deal with time zone differences), slide sets with more than 1 slide for every 2 minutes of presentation, most email, memos and reports that are longer than two pages or anything that requires access to a system that is hard to navigate.


• Overloaded Resources: Don Rienertsen's Managing the Design Factory lays out a strong case demonstrating how overloaded resources slow down development. But did you realize that they also slow down the flow of knowledge? People juggling too many projects in too few hours will be driven to take shortcuts that stop the flow of knowledge. They will stop taking the time to talk to others working on similar problems to figure out how to share solutions, and they will resist requests to share their knowledge with others if it doesn't help them with their immediate to do lists.


• Artificial Organizational Barriers: knowledge-sharing works best in an organizational structure that is a balance of both strong functional and strong cross-functional teamwork. On the one extreme, departmental silos prevent knowledge from spreading to related functions. On the other extreme, product-centered teams don't share knowledge effectively across products.


• Lack of Common Engineering Tools: Knowledge gets stuck when one set of tools (product data management systems, for example) can't talk to other tools. This is one area where the benefits of standardizing on a common toolset is well worth the pain. Teams working on similar problems need access to each other's information in ways that can be easily shared.


• Complex Knowledge Management Tools So-called "knowledge management" tools often become write-only databases because it is too hard to store information in them, and then too hard to retrieve it. With new search technologies like Google Desktop, you don't need a specialized tool to manage knowledge. Simple, searchable file shares of electronic A3 reports may be all that you ever need.

As you can see, most of these barriers are structural - embedded in the organizational structure, culture and IT systems that support the organization. This list contains few ideas for quick wins. The companies that have strong flows of knowledge in their organizations have worked for it, relentlessly identifying and eliminating the barriers to knowledge flow.

What can you do? Individuals working on their own can greatly improve their knowledge sharing effectiveness by attacking #1 - using better communication channels for everything within their direct control.

If you lead a product development organization or work on a lean product development team tasked with improving knowledge flow, it would be worth your time to identify the specific impediments to knowledge flow within your organizations, and invest the time to fix them as part of your lean product development efforts.

A3 Reports: It's All About the Paper Size

I occasionally run into people who don't like the term "A3 Report" - they think it's an obscure title for a simple tool. An A3 report is a document written on either A3 (metric) or 11" x 17" (U.S.) paper - twice the size of letter paper - to capture the essential information about a problem under investigation or a piece of valuable knowledge. You can find examples of them here in my Resource Center.

I encounter a lot of people who want to call these things "knowledge briefs" or something similar. I'm normally fairly flexible about the language people use to describe their work. But I've been resisting this trend with my clients, for two reasons.

The first reason is that everybody else calls these things "A3 reports" - so if you want to find out how other people are using concise, visual reports to solve problems, you want to search on the term "A3 Report" to find the answers. For example, you'll find the excellent book released this year by Durward Sobek and Art Small called Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System.

However, that's not the only reason I resist. Answer this question: how long is a Knowledge Brief?

The only possible answer is "it depends on what you mean." However, an A3 report is - by definition - on A3 paper. If it's on letter paper, or it's two or five pages - it's not an A3 report.

The paper size drives the right behavior to foster rich discussion, true knowledge sharing and good decision-making: distill the problem to the essential information, keep all the essential information visible at all times and use visual models to improve the flow of knowledge. To describe your problem on a single sheet of paper, you have to think about what's essential, and you learn pretty quickly that it's easier to be concise when you use pictures and other kinds of visual models rather than text.

Occasionally, I'll run into a company that has difficulty with the paper size - maybe they don't have printers equipped to print that large, for example. However, the visual models on an "A4 Report" (letter sized or 8.5" x 11") have to be fairly small to fit, and the reports have to be distilled down to the point that essential information has to go on a separate sheet. If you print the missing information on the back of the "A4 report" you have just hidden essential information, since I can no longer see it all at once.

Rather than go that route, I would rather solve the mechanical problem of "how do I print on A3 paper?" The small expense of installing a few large format inkjet printers for A3 reports is far outweighed by the benefits of using a format that has been demonstrated to lead to faster, better decision-making.

Re-Reading Allen Ward

On a long plane flight yesterday, I spent some time re-reading Allen Ward's Lean Product and Process Development. I had first read the book in a blitz right after I got my hot little hands on a copy at the 2007 Lean Transformation Summit. It's been a reference book for me since.

This re-reading was prompted by my attempt to introduce some of this material into the introductory talk that I do about lean product development. That didn't go over so well. There are so many new concepts embedded in that book: the entrepreneurial system designer, trade-off curves, set-based concurrent engineering, development cadence, etc - that 45 minutes of speaking time isn't enough to scratch the surface of the material. There is a lot of dense information in that book, but it may be difficult for someone new to the field to figure out how to get a toehold on this new world of product development that Dr. Ward envisioned.

The answer to "This is great - now what?" is found in the foreward at the beginning of the book by John Shook and Durward Sobek, where they describe the LAMDA cycle of learning. The act of simply Looking at your product development process - not the forms and slidesets, but at the stuff you actually produce - is a good first step, followed naturally by Asking why? Why do we repeat the same mistakes? Why do we have design loopbacks late in development? Why was one product a hit and the next one a fizzle?

LAMDA didn't make it into this version of the book, which he wrote three years before his death - he hints at it, but the idea isn't yet fully formed. Later on, Ward and his clients recognized that LAMDA supplies the necessary foundation for lean product development. An organization's ability to effectively execute the other practices depends upon the quality of their LAMDA cycles.

LAMDA is the on-ramp for lean product development. It is easy for an individual to try on his or her own to get a taste of lean product development, and build the company-specific case for it, and it is the first thing that an organization needs to spread across development if they want their lean product development efforts to bear fruit.

String Quartet Uses Lean to Support Creativity

"Lean" has spread from the manufacturing floor into the accounting office, order fulfillment and occasionally even the strategy process. But a string quartet?!

According to Benjamin Wolff, Associate Professor of Music at Hofstra University and the member of a string quartet, lean principles help his ensemble and his students make the most of their rehearsal time, by improving the routine processes to free up more energy for the creative process. Professor Wolff gave an insightful presentation at this month's AME Regional Conference in San Diego.

Ben's presentation showed his quartet rehearse a specific piece for an upcoming recital. Without necessarily telling the group what he was doing, Ben began using lean principles to rethink the rehearsal process. For example, all four members of the quartet play string instruments that must be retuned at least once during the rehearsal. Ben has used lean thinking to reduce the amount of time it takes to tune the instruments, and to ensure that the tuning process produces a more consistent result each time.

The major takeaway from Ben's presentation was this: creativity thrives in an atmosphere of disciplined practice and routines. By using lean processes to standardize and improve the supporting processes (the microprocesses), the musicians have more time and energy to innovate where it counts: the musical interpretation.

LPPDE A Hit!

I spent last week at the Lean Product & Process Development Exchange, and it was wonderful! It exceeded my expectations by far. We ended up with around 100 enthusiastic and engaged attendees, give or take a few each day.

Monday was Workshop Day, with four workshops. The most popular was Jim Luckman's Value Stream Mapping for Product Development. That one was a bit crowded but very well-received. The workshop I conducted with Jamie Flinchbaugh, Leadership Skills for Lean Product Developers also had a nice group. This was the first time he and I had done this workshop, and we learned as much as the participants. We had an engaged group with lively discussion that took us where we needed to go. The two half-day workshops also filled up, and received good reviews.

Tuesday and Wednesday were the meat of the conference. The big surprise was the real-time debate between Ellen Domb, a TRIZ expert and Michael Kennedy, the knowledge-based development expert. Michael encourages his clients to understand the trade-offs inherent in product design, while TRIZ encourages developers to transcend trade-offs to find ideal results. The synergies between the two approaches became crystal-clear as the debate proceeded over the two days, and I am looking forward to seeing what the two of them come up with as they put their heads together.

The Open Exchange sessions on Wednesday also exceeded my expectations. We really didn't know what to expect. The participants nominated over thirty topics on Tuesday. Voting and combining narrowed those to eighteen topics for Wednesday afternoon, split between three sessions. Although our intention was to have small groups of ten or less, many topic groups became larger than that, and were resistant to splitting up. Instead, one group took over the hallway to get enough space for everyone, and another merged two circles into one. We had assigned a thought leader or presenter to each group to facilitate, and they did a good job of leading the discussion, whether the groups were a handful or much larger.

The topics included things like SBCE, Metrics, Global Product Development, SW Tools and Knowledge Creation and beyond. I participated in sessions on Synergies between Agile and Lean, Integration Events and SBCE. Many of the participants who planned to leave early were sorry to miss the experience. We will definitely do this again next year.

We also learned that many of the participants wanted more opportunities to learn about the basics of Lean Product Development. We will address that with a tutorial webinar series this fall, and with more targeted workshops next spring.

The week before the conference, the LPPDE Board approved the 2009 Lean Product and Process Development Exchange! We have already begun to look at locations and will announce the final dates by June 30, 2008.

I hope to see you there!

LAMDA is Fundamental

A client of mine helped remind me about how central LAMDA (Look-Ask-Model-Discuss-Act) is to lean product development. LAMDA is Allen Ward's expression of Plan-Do-Check-Act, which is itself an expression of the scientific method we were all taught in seventh grade science. It is the problem-solving tool that Taichi Ohno used to invent the Toyota Production System. If PCDA works for Toyota, then why do we use LAMDA for lean product development? Because Allen was teaching impatient Americans who couldn't wait to get to the Act step.

I was guilty of this myself. I would do a little bit of Planning, Do a little bit, spend a few quick minutes Checking and then run off to Act - if I bothered to do all the steps. More typically, we'd skip the Plan-Do-Check (we know what to do already and we know it's going to work), and jump straight to Act. Is it any wonder why casual implementations of lean tend to fade away?

Allen dug a little more deeply into the kinds of things that went into the Plan step to find out what was actually happening. He found Look: go to the source, get direct experience with the problem , then Ask: seek the root causes, look for reusable information. He found heavy uses of visual and physical Models to eliminate misunderstanding, improve communication and drive better decision-making by making a person's thought process visible to others. Then seemingly endless (to an American) rounds of Discussion to deepen understanding and build commitment before arriving at a decision. But the actions worked and the decisions stuck, saving enormous amounts of time and energy over implementing a solution that does not work, or revisiting a decision because it does not have everyone's commitment.

The LAMDA cycle is foundational to lean product development because product development is fundamentally about solving problems as effectively and rapidly as possible. The cycle creates the conditions necessary for deepening our personal technical knowledge and developing solutions that make the most of our organizational knowledge. It directly attacks the wastes of reinvention, unproductive meetings, organizational silos and product-centered development.0

For more information, check out my LAMDA knowledge brief.

Lean Product Development at PDMA

Two years ago, I heard a presentation on Lean Product Development at the PDMA conference, and it was all about Lean Manufacturing applied to product development. Today, I attended a panel with Michael Kennedy, Dantar Oosterwal of Sara Lee and Dan Shoenhair of Ping, alongside Sandy Munro and Mark Adkins. Dantar has been at the forefront of this work since he began working with Allen Ward when Dantar was with Harley Davidson.

Today, Dr. Ward's vision proved itself to be alive and growing. The only mention of Lean Manufacturing was a brief one, to emphasize that Lean Product Development was not Lean Manufacturing tools applied in product development. With that said, we moved on to more interesting topics, like how Ping increased R & D capacity and Sara Lee increased revenue from new products through their adaptations of the Toyota Product Development System. Sandy Munro provided his unique perspective on how pain creates breakthrough innovations and Mark Adkins shared his experience with moving a group from five phase gates to two, and in the process eliminating a lot of wasteful documentation in exchange for a leaner, faster PD process.

All of the speakers emphasized that the engineers were not a barrier to implementing lean product development - if it was implemented and communicated well. In fact, it had the opposite effect of motivating the engineers and making their jobs more enjoyable - while they got more done than ever before. This panel showed that Lean Product Development is more than just "flavor of the month" - this is one change that produces sustainable results.

How to Avoid a Slow Motion Train Wreck

Yesterday, one of the sponsors of the PDMA event (who shall go unnamed) sponsored a nice dinner for the attendees, and then provided the night's entertainment. By the time the entertainers went on, it was about 7:30 p.m. after a long day of slideshow-driven presentations. Many of the attendees (including myself) had already had at least two drinks. We were definitely in the mood to be entertained.

The sales team put together a series of amusing sketches showing various sorts of dysfunctional behavior in product development, like keeping team knowledge locked inside the senior engineers' heads, and virtual team members who try to work in the dark. These sketches produced lots of laughs and groans of recognition.

Unfortunately, the sketches were surrounded by a lot of obvious sales pitch. The ratio of time was about 3 parts sales pitch to one part fun. The audience responded by talking over the presentation or walking out. I left myself after about 2/3 of the presentation. I doubt many left with a good impression.

I felt a lot of sympathy for the guy running the show. He was probably blinded by the lights and his location would have made it difficult for him to hear the audience's reaction. He may also not have felt empowered to say, "OK. This isn't working. We need to do a redirect here."

What are the unintentional lessons this sponsor delivered on product development at the PDMA conference?

• Don't allow your enthusiasm for an idea to override your customer and market knowledge. Conference dinners are for rekindling old friendships and building new ones. We expect a sponsor to do a little pitching, but by 7 p.m., we've already seen enough slides.


• Establish early customer feedback mechanisms. One quick run-through with an attendee would have shown that this presentation would be perceived as irritating rather than valuable. During the talk itself, the presenter had moments when he could have received feedback from someone watching the audience reaction from backstage.


• Manage risk with contingency plans. Given the setting, poor audience reaction was a major risk. If the presenter had a Plan B, he would have known what to do.


• If things are obviously not working as planned, don't keep charging ahead with your plans! Even without a Plan B, the presenter could have just had a quick word with the skit people during the 2nd or 3rd video, and created a better plan in the moment. I would have given him a lot of credit for adapting on the fly

Google manages this risk with their incremental development process. How do you manage the risk of poor customer reaction in your own product development process?

Iterative Product Development to Enable Breakthroughs: NPD at Google

Today at the Product Development Management Association's Annual Conference, Marissa Mayer described Google's unique use of iterative product development to enable breakthrough products.

She described the difference between Google's approach to innovation, and the traditional "castle-building" approach. Castle-builders close the curtains, go dark for awhile and then release a produce when it is perfect (or nearly so). Google, on the other hand, will often release features very early, then rapidly iterate the product based on user input until it is perfect enough.

As a Web service, Google is uniquely positioned to make the most of this strategy. Ms. Mayer described Google's sophisticated system for tracking usage data to provide hard evidence to answer such questions as "Which user interface is more effective?" that help them identify and fix problems. They can set their servers to redirect only a small number of users to a test site for a new version, and when they want to roll to the next one, it is as simple as rolling code into their production environment, a process they have honed.

One criticism of such an approach is that it leads to only incremental innovation. Ms. Mayer showed how Google uses this to lower the hurdle for riskier, breakthrough products. If something doesn't work, they can just change it or kill it with little risk to the rest of their business. With a little creative thinking, other services companies can directly leverage the central principle to release imperfect products to small numbers of customers early and then perfect them with direct user experience input over time.

This is obviously much harder to do when a product consists of much more than lines of code on a server. However, creative use of rapid prototyping technologies may make it easier for us to get user feedback earlier in the process than we do now, which will make the development and launch processes go more smoothly.

How early do your customers start using your new products? How can you get them to do it earlier - maybe much earlier than you do now?

LPPDE: Dates, Location and Thought Leaders

I am so happy to announce the final dates and location for the 2008 Lean Product and Process Development Exchange!

Location: Denver, CO at the Grand Hyatt.

Dates: April 21 (workshops), April 22 - 23 (main conference)

Thought Leader Panel (besides me):

• Durward K. Sobek, professor at Montana State University and editor of Allen Ward's Lean Product and Process Development.


• Michael Kennedy, author of Product Development for the Lean Enterprise and co-founder of Targeted Convergence, Inc. We will (if all goes well) have a launch party for Michael's 2nd book during the conference!


• Mary Poppendieck, author of Lean Software Development.


• Jamie Flinchbaugh, co-author of The Hitchhiker's Guide to Lean and co-founder of the Lean Learning Center.


• Tricia Sutton, founder of LeanEx, a lean product development peer learning group in Chicago, IL and president of Sutton Enterprises, Inc.


• Ellen Domb, co-author of Simplified TRIZ and Beyond Strategic Vision, and founder of the PQR Group.


• Bo Oppenheim, professor at Loyola Marymount University and member of the Lean Aerospace Initiative.


• Jim Luckman, Lean Enterprise Institute instructor and consultant.

I have also begun to recruit an exciting set of success stories from lean product development pioneers. As I get confirmations, I will post updates on the site.

Our target date for opening registration is October 29, 2007 to coincide with the AME Annual Conference in Chicago that week. Our target base price is $1490 per attendee. With early registration, partner and team discounts, the lowest available target price is $940 per attendee. We will also offer an academic rate for full time students and professors in product development-related fields.

We will launch the official website the same day we launch registration.

I hope to see you in Denver!