Ravelry: A Knowledge Supermarket for Knitters

If you are wondering what a fully fleshed out Knowledge Supermarket looks like, find someone in your life who knits and head on over to Ravelry: http://www.ravelry.com This began as a social networking site for knitters, but it has become the best example of a public Knowledge Supermarket that I've seen.

(If you don't have any knitters in your life, I pity you - there's nothing more cozy than handknit cashmere socks - but you can create your own account so that you can poke around - and learn to knit your own socks).

Knitting is a technical craft with hundreds of years' worth of accumulated knowledge about stitch patterns, garment construction, fibers and yarns, and repeatable methods for producing intricate colorwork and texture.

Ravelry's developers have grouped all of this knowledge into the categories that will make this knowledge easy to reuse, provided a powerful search engine and data structures that support knowledge creation and reuse. A simple editing process keeps it all accurate. Meanwhile, the community has populated the libraries and made this a hub of links that bring the entire Internet's accumulation of knowledge available to Ravelry's knitters.

Here is one use case to show how powerful this is:

I find an interesting kind of yarn that I've never seen before, and want to know what I can do with it. On Ravelry, chances are that someone else found the yarn first and put in all the information that's important to me as a knitter - things like how many meters there are per ball of it, and how well it wears - and other knitters have linked their projects they made with this yarn. Ravelry makes some pattern suggestions for me, and I select one. If this is a free pattern, I just download it as a PDF and if not, I purchase it right online first.

If I have my iPhone with me, I can do all of this right in the yarn shop so that I can purchase the right amount of yarn and other supplies for the project, without having to make extra trips.

Now I create a project page that links to all of Ravelry's information about the yarn and the pattern, including the mistakes in the printed version of the pattern and how others have corrected them. I can post pictures of my WIP and my finished garment, then add my own comments about the yarn and pattern to share with the next person who uses them.

Meanwhile, if I encounter a new technique in the pattern, a search by the name of the technique pulls up blog posts, online discussions, photographs and even YouTube videos that demonstrate it for me.

There is no need to reinvent anything in a craft that's been perfected over hundreds of years, and having all that knowledge at our fingertips frees up our creativity for exploring how to use these techniques in new ways.

In my next post, I'll share one amazing project that was only possible because this site's libraries and online community pulls all this knowledge together in one place.

In the meantime, imagine if you had something like this for your key product knowledge inside your company? What would you be able to do that you can't do now?

Guest Post on Contrarian Consulting: Lean Solo

I wrote a guest article last week for Alan Weiss's Contrarian Consulting blog: Lean Solo: Five Reasons Why the Best Solo Consultants Are Inherently Lean.

If you've ever doubted that lean ideas can scale down to a small organization, you should read this article.

Continuous Flow Consulting: Leverage Technology for Just In Time Consulting

This is the fifth post in a series about moving towards a continuous flow model for providing outside assistance to companies that want to become leaner.

Principle #3 of Continuous Flow Consulting is: "Spend less time in face to face meetings, and do much more over the phone and over the Internet, using the richest media available, on shorter time cycles."

In Lean Manufacturing, one of the big wastes is transportation: the need to ferry raw materials, parts and subassemblies between different parts of a plant to get things done.

In consulting, travel is a huge source of non-value-added time. It costs the consultant hours of productive time, and it directly costs the client money. That doesn't mean that all travel is bad - it does mean that we need to ask ourselves if the travel is worth it.

There are some things that can only be done face to face. In fact, I've blogged before about the unintended side effects of blanket travel restrictions when they occur at critical points in the product development process, and the same thing is true in a consulting engagement.

However, so often we assume that most of the work that we do has to be face to face: that if we're not on the client site, we're not adding maximum value. I would argue the opposite: we can provide more value to more clients if we develop flexible models that blend face-to-face work with continuous access to just-in-time remote coaching.

For example, I cannot be physically in Helsinki, Singapore, Pennsylvania and California on the same day. I can (with some creative scheduling, a good headset and an Internet connection) conduct coaching calls with people in all of these places on the same day. In fact, I can be on-site in California and also give my Finnish, Singaporean, and Philadelphia clients just what they need, when they need it (ironically, this is easier when I'm traveling than when I'm at home).

The technology available today makes this so easy that I don't know why everyone doesn't do it. We can't cover as much in a coaching call as we can in a full day meeting, but it's quality, not quantity that counts. If that call occurs at the right point in time, with just-in-time knowledge sharing, it can have a much greater impact on the success of the project. I'm a lot more likely to hit that moment if I'm talking with my clients on short time cycles.

We used to believe that we needed face-to-face meetings to develop trust - but I'm not sure that was ever as true as it seemed. While face-to-face meetings build relationships between relative strangers, we are more likely to sustain a relationship with a person we talk with by phone once a week than we are with someone that we only see once a month.

Continuous Flow Consulting: Cut Batch Sizes

This is the fourth post in a series about moving towards a continuous flow model for providing outside assistance to companies that want to become leaner.

What is the "batch size" of a consulting engagement?

I've done 1:1 coaching and I've done large training events. I've even done some events that were so large they had multiple locations connected with video.

Here, as in most places, conventional wisdom says that it's better for both the consultant and the client for these events to be as large as possible: less work to reach the same number of people, everyone hears the same message at the same time, the organization as a whole gets to "kick off" their lean journey at once.

Like most conventional wisdom about batch sizes, these assumptions are wrong.

Large scale events are good at transferring explicit information efficiently. However, as I said in my last post, that's the easy stuff. The hard stuff comes in the day to day slog of making different choices. They are fantastic for rallying the troops, but the inspiration is hard to sustain in the face of the realities on the battlefield.

For that, one needs people on the front lines - leading, managing and mentoring as needed to help people make the right decisions in the moment, ideally cutting batch sizes for knowledge transfer down to one.

What is the role for a consultant in this?

First, I must make it easy for people to get explicit information just-in-time. The Lean Development Resource Center is my start in this direction: every one of my clients receives premium access to the site. Eventually, this will give them access to all the knowledge that I externalize (by writing down my tacit knowledge, making it explicit). They can get it 24-7, on their own, as they need it.

Second, I need to work more collaboratively with the client to bring them into the knowledge transfer process. In the best lean organizations that I've seen, managers lead the trainings rather than professional trainers. My strength is in the content and in the instructional design that helps ensure that the workshop can deliver on the learning objectives, and I can leverage that more effectively by training the managers and then letting them train their people.

The "see one, do one, teach one" model from medical school works well in this context, and helps a large company grow its skills exponentially. A3 Thinking, after all, is not brain surgery.

Although I have more experience with lean, they have more experience with their people When I let go of control and allow them to leverage that into small group experiences, the value of the team interaction and demonstrated leadership makes up for the rough delivery.

Finally, I need to focus my scarce resources to actively teach, support, model and reinforce the kinds of mentoring skills that facilitate that one to one knowledge transfer.

Continuous Flow Lean Consulting: The Trusted Advisor

This is the third post in a series about moving towards a continuous flow model for providing outside assistance to companies that want to become leaner.

In my last post, I posited a series of principles of continuous flow consulting. Here's #1: Become trusted mentors and advisors, not trainers or analysts.

To understand the role of the trusted advisor vs. the role of a trainer, one needs to know the difference between tacit knowledge and explicit knowledge. Explicit knowledge is written down: training materials, reports, statistics. Tacit knowledge is all the stuff that we gain through hands on experience. One can read everything that's been written about how to climb a mountain, but to master mountaineering, one has to climb mountains, preferably under the tutelage of an experienced climb leader. There's no substitute.

Training is great at delivering explicit knowledge - things like "What is a kanban system?" and "What does PDCA stand for?" Analysis is terrific at making meaning out of explicit data, such as analyzing control charts for improvement opportunities. Event-driven lean is mostly about transferring explicit knowledge about specific tools.

These events are not as good for helping organizations as they adapt lean principles to their own organizations: constructing a kanban system or using PDCA on a daily basis outside of the classroom. There is a tremendous amount of tacit knowledge involved in learning how to use lean principles where they can do the most good, and in building a lean culture of systematic problem-solvers.

Training is still important in the early days of a lean transformation, when there is a tremendous amount of explicit knowledge to transfer, and when workshop exercises can begin the process of building that direct experience that leads to a lean culture. As the newly minted lean company masters the basics, we run out of explicit material pretty quickly, and the need for mentoring quickly takes over.

A mentor guides the mentee through hands-on experiences that go to the source, helps them see the current situation more clearly by asking good questions, and provides advice that is rooted in experience. It is the way we transfer tacit knowledge.

We can only mentor effectively in the context of an on-going relationship that involves more than a visit once a month. We have to be engaged with each other at the moment when the mentee has a need or the mentor has an opportunity to deepen understanding. That takes trust and some time, but less time than holding events that make changes that have no sticking power.

The mastery of tacit knowledge with the help of a trusted advisor is the difference between having a kanban system or a knowledge supermarket and being a lean organization.

Continuous Flow in Lean Consulting Part 2

In Part 1 of this post, I outlined the problem that I observe: the way we conduct lean consulting reinforces an event-oriented view of lean that leaves a lot of value on the table.

My personal mission is to create the freedom to innovate, by eliminating all the stuff that gets in the way.

In most PD organizations, there is a lot of stuff in the way: big stuff, like rigid phase gate processes, and small stuff, like difficulties retrieving essential information on a daily basis. It all clogs up the flow of innovation.

It takes daily, continuous effort to get all that stuff out of the way. We humans are masters at grooving the things we do every day, even when those things directly impede the flow of our work. It takes effort to change, even when there is immediate benefit. One training event or one goal setting session is not going to create change.

I've never been satisfied with an event-driven model of consulting, and I've attempted to fix it by providing unlimited access via phone and email for all of my clients as a part of every engagement. As a result, at least my clients never feel like they're on a meter with me.

Still, I think that doesn't go far enough. The business model of consulting, as long as it's based upon face to face meetings, trainings and events, is not continuous or just-in-time enough to be as effective as it can be during a lean transformation.

So how do we make consulting services more continuous? Here are six principles for continuous flow consulting:

1. Become trusted mentors and advisors, not trainers or analysts.



2. Cut the "batch size" for trainings and other learning experiences.



3. Spend less time in face to face meetings, and do much more over the phone and over the Internet, using the richest media available, on shorter time cycles.



4. Provide multiple ways to connect, and lower the barriers to connection.



5. Provide ways for clients to pull your knowledge when they need it, rather than on a time schedule that's dependent upon the consultant's availability.



6. Bring clients together to form communities so that they can provide support for each other around their common goals.

Just this week, I took a major step towards building my own continuous flow consulting model.

I launched a Knowledge Supermarket around lean product development. It's called the Lean Development Resource Center, and it's available here: www.leantechnologydevelopment.com

The site will give my clients and other lean product development practitioners the ability to pull knowledge from me when they need it. I have a wealth of materials in my personal library from seven years of lean product development consulting and fifteen years of product development work that does no one any good if it's on my hard drive and in my head.

It's an experiment and as such, I don't know exactly where it's going to end up, but I think this type of thing is a step towards being available for our clients when they need us, and not just when we get on a plane to see them.

Continuous Flow in Lean Consulting, Part 1

In a lean organization, people at all levels of the organization continually engage in systematic problem-solving so that the company and its people eliminate waste and deliver more value ever day.

This is the Holy Grail of lean thinking - the true source of differentiation between the companies that get great results with lean and the ones that get good results initially but find that they can't sustain their gains. It is a universal and continuous flow of innovation that tackles problems from massive to tiny in a spiral of exponentially increasing value creation.

As lean consultants, our job is to support organizations as they develop this internal capacity. I'm beginning to wonder whether or not the way that we tend to do this is as effective as it could be.

Kaizens, mapping sessions, trainings, etc. are all events. As such, they are discontinuous, limited in the number of people engaged, and conducted mainly on the mid-sized problems that lend themselves to this format. Often, they focus on implementing best practices from other lean companies like 5S, kanbans or set-based concurrent engineering, rather than allowing the workers (machinists, engineers, doctors, executives) solve their problems using their own ingenuity.

We don't want to reinvent solutions, and the tools of lean have a demonstrated track record of delivering performance improvements, but the companies who just implement the tools without instilling systematic problem-solving leave so much value on the table. Yet as consultants, we model exactly the kinds of behavior that lead to unsustainable or shallow tool-driven lean programs that generate only limited value.

Our clients need to develop sustainable, continuous flows of systematic problem-solving to maximize their potential. Yet without living with a client for some time, we need to support them.

There must be a better way. In Part 2 of this post, I'll explore some ways to get more continuous flow into our lean consulting work.

In the meantime, I encourage you to check out my two new web class offerings, Lean Product Development Basics and Lean Thinking for the Front End of Product Development.

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.

Lunch with Ken Kreafle of Toyota

I had lunch today with Ken Kreafle, General Manager of Vehicle Production Engineering for Toyota North America, while I was in Northern Kentucky this week. It was a great way to cap off the Association for Manufacturing Excellence’s annual conference.

He defined lean as, among other things, “workers improving their work within their teams.” In other words, lean is not something that someone can do from the outside. Those of us who support lean from the outside can only support the people on the inside as they improve the process.

He strives to remind people that it took sixty years for Toyota to get to the place where it is today (and it’s not perfect by any means). All the “stuff” - 4/5/6S, kanbans, work cells, etc, etc emerged from a process and a culture of relentlessly attacking problems so that they get solved permanently. We can improve our operations and product development by modeling our practices after the tools, but that’s only the tip of the iceberg.

It’s much easier to emulate specific tools and practices than it is to truly empower workers to improve their own work - to give them the tools, set the expectations, manage and reward them so that they come in every day willing and able to solve problems so that the problems don’t come back.

We have it a little easier in product development - after all, we come in to work every day prepared to solve customer problems, and figure out how to meet customer needs more effectively with the next products than we do with our current products.

Still, how many of us have problems that crop up over and over again - always at a time when we don’t have time to do anything more than place another bandaid over them? How many of us stumble at the same places in development over and over because there’s never any time to fix the problems permanently? How many of us spend a lot of energy innovating in areas like checkpoint meetings that add nothing to customer value, sucking time and energy away from the things that drive revenue growth and profitability?

What would we be capable of doing if we rigorously attacked those problems so that we could move on to better problems?

The Future of Publishing: Print on Demand

I spent the weekend at BEA, networking and doing research for my new book.

On Sunday, I spent quite a bit of time visiting Lightning Source to learn about their printing model. They are the print-on-demand subsidiary of Ingram, the largest book distribution company. If you buy books from Amazon or barnesandnoble.com, your book passed through Ingram on its way to you.

Lightning Source operates plants that have digital presses capable of doing short runs (<1000 copies) at a reasonable price, down to single copies. They service everyone from the major publishers to university presses to self-published authors, helping them all produce only the copies that customers want to buy. Oxford University Press has put its entire backlist (books from earlier years) on Lightning Source, making it possible for them to keep many more books in print than they could when they had to have large print runs.

There are thousands upon thousands of new books released every year, and under the old model, few of them made money. The long print runs required to get the per-unit cost down to a reasonable level created a high barrier to entry and a ton of non-value-added waste, in its most visible forms: books printed and then pulped without ever leaving the publisher’s warehouse, books shipped to the retailer to support a major push, and then shipped back unsold, a huge remainders market for the ones that didn’t sell.

That is a lot of trees and a lot of oil being saved.

For the major publishers, this may not lower their costs all that much - marketing, editing and design still consume a lot of money and energy. An author will still need to produce a book that will justify that investment. But it does lower their risk and give them the ability to maintain much larger backlists, since the electronic files associated with them are essentially free. It replaces one of the most rigid parts of the publishing process with a flow that is much more adaptable: they can print a small number of copies, and if the book takes off like a rocket, they can make more.

That’s good news for everyone, except maybe the pulping plants.