Building a Better Mousetrap at AME

Durward Sobek, Michael Kennedy and I conducted a workshop on lean product development at last week's Association for Manufacturing Excellence conference.

The workshop uses the Mousetrap® game as a product development challenge: can you build a better mousetrap? Here is the "before" picture (Mousetrap 1.0):



The purpose of this workshop is to help people gain more comfort using rapid learning cycles as part of the product development process. The teams develop Mousetrap 2.0, 3.0 and 4.0 in iterative development cycles, use LAMDA to investigate their ideas and A3 reports to document their findings.

The groups are all part of one development team competing for a customer order against a competitor who has set a high bar for performance.





This time, all four teams could only catch 7 mice in five minutes, using three people with the original set up. The "winning" solution, which included ideas from all four teams, caught 23 mice in 5 minutes with only one person, a 10X improvement in mice caught per minute per person.

By sharing the best ideas among the entire group, we end up with at least one solution that will work among the four teams, demonstrating the value of set-based design when the team has a high degree of technical risk and a lot riding on the outcome.

The group used rapid prototyping tools (scissors, masking tape, construction paper) to quickly design and test their ideas in ten minute development cycles, followed by five minute trials.

Special thanks goes to Jamie Flinchbaugh and the Lean Learning Center who originally developed this simulation, and helped me adapt it to product development.

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.

More on A3 Templates

There are a few circumstances where a standard A3 template is a helpful thing. If an A3 Status Report will replace a standard project management report, a standard template helps ensure that project teams include the right information in the update. If a management team requests an A3 report to help them make decisions, the managers should decide upon the information they need, and how it is formatted. If an A3 will replace some kind of document needed to request services, the service providers will need to have input into the format of the A3.

However, these circumstances are not the norm. Most of the A3s in an effective knowledge-sharing organization will need to be written in a form that is flexible enough to accommodate the author's information-sharing needs, including the visual models that make this such a powerful communication tool. If most of the A3s in an organization follow a standard template, either the organization is not using them widely enough or they are over-constraining the form.

These templates should still be designed so that the information customer's need for standard information is balanced against the information producer's need to be concise, clear and focused. There may be standard boxes in standard locations, and then areas that are more flexible.

Even these standard A3s don't have to be pretty. The process should still encourage the author to review work early and often with anyone who can provide useful feedback. That will help the downstream information customers receive the best possible information in the form that works best for them.

A3 Reports Don't Have To Be Pretty

I'm at a client site this week, delivering a series of "First Steps with Lean Product Development" workshops for engineers. This workshop provides a basic introduction to the concepts of Lean Product Development and then does a deep dive into the LAMDA cycle and A3 reports. Each participant writes an A3 report over the course of the day.

In the workshops, participants use blank sheets of 11 x 17 paper and pencils to create their first A3 reports. I never write A3 reports in this manner, and I don't expect anyone to make more than one this way. However, I have found that both my client companies and the course participants benefit from one guided experience with a blank page.

Doing it this way counteracts two of the major tendencies that new A3 adopters tend to have which diminish their potential benefit: They want to create / use a template, and they want to fill it all out before they show it to anyone.

First, A3 is just a paper size. There are some good reasons for using 11 x 17 or A3 paper to produce a concise report. It has a good amount of space but one can see the entire page at a glance. It is large enough for good visual models but small enough to force conciseness and focus. It hangs nicely on walls and fits well into standard binders. Letter sized paper (8.5" x 11" in the U.S.) is just too small while anything larger would be cumbersome. But nothing about the paper size dictates the format. A "good" A3 report contains the information needed to help the author accomplish the purpose - and nothing extra.

The contents of the report can - and should - be at the entire discretion of the author. When I teach these reports, I emphasize that only three things are really required: a title, the author's name and contact information, and a one-sentence summary of the problem so that I can quickly decide whether or not I need to read the entire thing. I have expressly forbid some clients from creating any sort of A3 "template" for at least six months after they begin using them, because I know that if they did create a template, all the A3s would look exactly the same, and the format would become just another report that someone has to fill out, rather than a working problem-solving tool.

Over time, the visual models, tables, lay-outs and structures that work well tend to become more prevalent, and experiments that fail die out. The organization develops a look-and-feel for the reports that matches their use inside the organization. There may eventually be standard templates for some things, like status reports but probably only loose guidelines for others. Peer feedback with some coaching and mentoring from senior team members accomplish the rest.

The other problem with templates is that people want to fill them out completely and perfectly before showing them to anyone, especially managers. But A3 reports work best when they are working documents and when the author begins to get feedback almost from the moment he or she puts the title on the page. "How do you see this problem?" is a good question to ask at this point. Hand sketches, scribbled edits and notes are all fair game and empty boxes tend to solicit both better feedback and buy-in from the reviewer.

How are you using A3 reports in your organization? How much diversity do you have in the format and appearance of these reports? When do you begin showing them around and how perfect do they need to be before they make their public debut?

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.