Wikis in Plain English

Hat tip to Tricia Sutton. . .

I've been exploring Wikis as virtual alternatives to notebooks of A3 reports and team Visual Planning Walls. They seem to offer a much more flexible alternative to Sharepoint® sites for displaying team information. Some versions I've seen even make it easy to embed pictures and videos.

Here is a great video that explains Wikis in ways that even the most non-technical can understand:



How could your team use something like this, even in its simplest form, to stem the tide of email and avoid the waste of reinvention?

PDMA Visions Article: What is Lean about Product Development?

I have a new article out in PDMA Visions, the member magazine for the Product Development Management Association. This article surveys the landscape of lean product development. I co-authored the article with Tricia Sutton, who will also co-chair the Lean Product and Process Development Conference with me for next year.

The article includes a chart comparing different approaches to product development, including their proponents. The concept for this has its origins in my 2005 Road Trip, where I interviewed people across America and summarized my findings in the Lean Product Development Road Trip Report.

As you can imagine, Tricia and I had some long and hard discussions about whom to include in the right hand column, when it came time to name names. Not every prominent name is on the list and I'm sure I will have to field some disagreement from a few of the ones who are. Not that I mind. I'll use any excuse to have a discussion that may deepen my understanding.

What do you think about the different schools within lean product development? Which ones have you drawn from in your own lean journey?

One Good Use of Product Development Standardization

I spoke to a gentleman yesterday who worked in a corporate office charged with aligning the various engineering teams within a large company that had grown by acquiring a couple of dozen smaller companies, all producing similar products. The company hopes to realize synergies by developing comprehensive solutions that draw products from multiple subsidiaries. However, most of the companies were founded by entrepreneurs, had home-grown processes at best, and could barely communicate about the basics of product development, much less actually collaborate on a new product.

This is an example where a high level, lean stage gate process makes a lot of sense. It's nearly impossible to avoid the waste of reinvention in such a setting. A standardized, high level framework for product development helps by creating a common vocabulary and structure. When I call and say that I'm working towards my first proto tooling release and could use a little of your expertise from the product you just released, you know what I mean.

The risk is that such a process will lead to bureaucracy. In a large company, the temptation is strong to add in everyone's pet action item and report, causing the lifecycle to eventually collaspe under its own weight. However, it seems that this company has avoided such pitfalls.

The teams have the ability to improvise within this framework to create a product development process that balances the needs of the corporate parent with the needs of the specific product's customer. They are not overburdened with proscribed administrative reports and checklists to complete. Teams are not arbitrarily required to batch their work until after they pass a specific milestone, causing reinvention and time-to-market to increase.

How does your standard product development process balance structure and flexibility?

2008 Lean Product & Process Development Conference a Go!!

Today, the Lean Enterprise Institute agreed to sponsor our Lean Product and Process Development conference in 2008! This was the final piece needed before we could make a "go" decision.

This conference will reflect Dr. Allen Ward's vision for Lean Product Development, as represented best in the Lean Product and Process Development book that just came out this year. Our intention is to have a two day conference filled with practitioner presentations, plus a set of pre-conference workshops from some of our thought leaders. You can get a lot of the theory out of books or from websites like mine. But where else will you be able to hear from some of the pioneering companies out there that have been using this stuff to get results like faster time-to-market, lower product costs, more new products and more profits from new product development?

I will co-chair the conference with Tricia Sutton of Sutton Enterprises. We've also been in contact with a terrific roster of speakers including Rich Gildersleeve of djOrtho, who won PDMA's Innovator of the Year award in 2005 for their lean product development efforts. Durward Sobek has of course already provided some unofficial guidance.

We will base the conference on the same model as the Lean Accounting Summit, with a panel of thought leaders guiding us as we finalize the agenda. But first we need to nail down location and dates (and take care of some administrivia to set up an infrastructure).

Watch this space for more news as things evolve!

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?

Blogging for PDMA

I have joined the blogging team for the Product Development Management Association! Here is their blog: PDMA Blog. I will write original posts for them, and I will cross-post every third or fourth post from this blog - particularly the ones that are more focused on product development than lean.

Other bloggers on the site post on NPD best practices, innovation and creativty, product strategy and execution. Most of us are involved in our local PDMA chapters in some way, so there are posts about local chapter activities and live-blogging of the PDMA national conference from a variety of perspectives.

I would encourage you to check out PDMA, especially if there is a local chapter in your area. It is a great way to connect with other product developers.

Oregon PDMA/PMF Conference Part 3: Space is Always Open

In the afternoon, the conference had an Open Space session where the attendees "design their own conference." Diana Larsen of Futureworks Consulting got us going with a description of the process and the ground rules, while we sat in one giant circle.

People nominated themselves to be session hosts, simply by writing a topic on a piece of paper, choosing one of two times and a location then posting it on the "Marketplace" bulletin board. Then we chose the topics we most wanted to discuss. "Butterflies" chose to work by themselves rather than join groups, but Diana claimed that butterflies would tend to cluster and I did see that happen. "Bumblebees" buzzed from session to session, pollinating one session with ideas from another.

For the first time, I participated in a lively discussion on "Cultural Change for Collaboration" where we talked about the importance of getting senior leaders to behave collaboratively themselves to foster collaboration in the rest of the organization. To do that, we need to make sure that people understand the relationships between collaboration and decision-making, which can take many forms.

I was a bit of a bumblebee in the second session, drifting between topics like Cultural Issues in Global Collaboration, How to Get Anti-social Engineers to Collaborate, and Collaborating with the "Man on the Mountain." This final topic was an interesting lesson in collaboration, because the people drawn to it talked for at least twenty minutes before I observed that we all had a different picture of the "Man on the Mountain" - who he was and why he was up there.

I"ve organized conferences and I'm a bit of a control freak so I wasn't sure how Open Space would work. But the topics were interesting, the session hosts and participants brought their passion into the room and the discussions were interesting and fruitful - much more so than an endless series of passive slideshows.

Oregon PDMA/PMF Conference Part 2: You Think You Have Customers?

In the morning, I attended a break-out session on Collaboration in Innovation by Bryan Jobes of Boeing's Commercial Airplanes Division. He was a senior manager for the new Boeing 787 Dreamliner.

Here's the thing that struck me: commercial aircraft designers have to balance trade-offs for a range of customers and end users from passengers, pilots, flight attendants, ground crew, airport infrastructure managers, passenger experience managers (or whatever they call those people who decide that those in Coach don't need much legroom), capacity managers, bean counters, etc. plus a worldwide network of regulatory agencies. That they can do this and deliver an innovative aircraft in a reasonable (for the industry) timeframe seems like quite an accomplishment.

Collaboration is a given in this environment, and he provided a nice example of how Marketing, Product and Technology roadmaps work together to provide direction for a team making literally thousands of trade-off decisions.

Oregon PDMA/PMF Conference Part 1: Best Slideshow Ever

I'm at the Oregon Product Development Management Association and Program Management Forum joint conference today.

The keynote speaker was Sam Lawrence of Jive Software, speaking on Collaboration 2.0. He had a great but not very deep message about how today, it's all about Web 2.0 - it's all about collaboration, people, openness, participation. As a keynote presentation, it was perfect - broad in scope and entertaining in tone. While he didn't offer any new insights, he did set up the deep dives in the break-out sessions very well.

I was most impressed with his use of presentation software (PowerPoint® is the most popular but I'm not certain that was the one he used). Most people use these things to present bullet list after bullet list, perhaps punctuated with a complex diagram. He used it completely differently. Most of his slides consisted of one word or phrase with an accompanying image, delivered alongside a rapidfire monologue. The slides provided a bit of an ironic twist to his words sometimes - think Steven Colbert's The Word. Most often, they punctuated his main points like exclamation marks.

I still have the usual problem with slidesets - I cannot remember much of their content. But with this presentation style and the purpose of his talk, that did not matter quite so much.

Benchmark Report Shows Results from Lean Product Development

The Aberdeen Research Group just published a report benchmarking companies that use Lean Product Development. This report is available to anyone willing to provide some basic information to Aberdeen through an on-line form.

Their research shows that best-in-class companies who use Lean Product Development achieve 25% faster time-to-market, achieve cost targets more frequently than average and claim that they now spend 69% of their time on value-added activities vs. 45% for the average companies.

There are some interesting details in the numbers. For example, 69% of "best-in-class" - at least 20% better than average - and 53% of "laggards" - at least 30% worse than average - use Value Stream Mapping. However, 70% of best-in-class use tools and techniques to support knowledge-based engineering vs. only 30% of the laggards.

Unfortunately, Aberdeen's recommendations do not follow their own data. Based on their results, I would expect to see strong endorsements of knowledge-based engineering, product portfolio management, set-based design and a strong metrics program. Instead, they offer the usual bromides of "reduce waste" and "streamline processes." More dangerously, they recommend reducing variability and validating designs early - both of which run counter to knowledge-based engineering and set-based design.

However, if you need to provide hard data to support your efforts to get Lean Product Development underway in your organization, print out the report for them, highlight the practices that you intend to use on Page 9 and cross out the recommendations on pages 12 - 15.