Product Development Field Notes

My blog has moved! Redirecting...

You should be automatically redirected. If not, visit http://www.whittierconsulting.com/fieldnotes/ and update your bookmarks.

Thursday, June 14, 2007

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?

Labels:

3 Comments:

Anonymous Anonymous said...

I have found that A3 reports must be done by hand. Eventually you may, for your 'achiving' struture, produce them electronically (once the author has reached some determined level of competency). It is key to do them by hand because it is painful to erase and write over as your thought process becomes clearer (makes you learn quickly). As long as I can follow the flow of the A3 (some general standardization) I allow individuals to add extra 'boxes' if it helps clarify the problem / information (but it all must fit on one side of tabloid paper in a legible way). As the use expands into other functional areas I believe, as Katherine suggests, that more defined formats will present themselves out of necessity. I have seen Toyota A3s that are 'ugly' but the wealth of learning embedded in them is astonishing.

June 14, 2007 at 6:38 AM  
Blogger Katherine Radeka said...

Well, that works for people with good handwriting! I wouldn't subject someone to mine (well, maybe my husband for some of our household A3s, but then he's used to me). Surprisingly, I've found that PowerPoint(R) is one of the best tools for creating A3 reports: you can control the layout of graphics and text much better than Word(R), the simple drawing tools make it easy to create simple diagrams and the integration with Excel makes it easy to embed charts and graphs. I'm also surprised that you don't encourage people to erase and update as they learn more about their problem. Could you say more about that?

June 14, 2007 at 4:05 PM  
Anonymous Anonymous said...

With respect to your question about erasing and updating they have to do a lot of it as they learn about their specific problem (it becomes obvious that they have to change the A3 as they learn). What I have seen is that as folks become better at their own internal problem solving process' they need to erase and update less (more forward thinking). Producing a truly effective A3 will not happen on your first try of your first A3. It takes time, it will take many A3s before you are good but the effort is worth it (and I am not yet good at A3s).

Publisher(R) is the tool I think is best but not everyone has it. I find it much easier to use than PowerPoint(R) (it is more flexible) plus it imports just about every other MS Office(R) output. That being said, I still vote for doing A3s by hand (to start, at a minimum).

June 26, 2007 at 9:44 AM  

Post a Comment

<< Home