Lean Manufacturing needs Lean Design - Embedded.com

Lean Manufacturing needs Lean Design


The principles of Lean Manufacturing have revolutionized the way companies implement their manufacturing procedures. Companies that used to have large warehouses full of raw materials stockpiled have moved to a just-in-time process whereby raw materials go straight from the loading dock to the line and out the back door as product in the minimum possible time.

Thus supply chain integration has become a critical competitive advantage. Other companies, realizing that their core competencies lie elsewhere, have gotten out of the manufacturing business completely. Instead, they rely on contract manufacturers to provide them with product.

Unfortunately, many products being built in a Lean Manufacturing environment are still designed with procedures that date back decades.

Complement Lean Manufacturing with Lean Design

If companies are to prosper in this manufacturing environment they must find a Lean Design process that complements Lean Manufacturing and allows them to get innovative new products to market in the shortest possible time at the lowest possible price. Lean Design has many parallels with Lean Manufacturing, and it can have a massive impact on how quickly products can be brought to market.

In this context, it is important to realize that design processes and procedures that evolved during the Wintel-based PC era of one dominant hardware platform, and one dominant software platform are no longer appropriate nor practical.

The future of electronics is much more likely to resemble the automobile industry, where SUVs, sports cars, trucks and sedans all coexist and thrive in the marketplace. Much time and ink is wasted talking about who is “winning” the PDA war but the simple fact is that both the Palm and Windows operating systems will continue to exist and thrive. In addition, there will probably be several new viable operating systems emerging in the next few years. One device that “does it all” may come to pass, but only as one of many alternatives.

The histories of the Palm Pilot and the iPaq illustrate my point:

The Palm Pilot was a huge success, while the Newton and Momenta units failed. Nobody was able to forecast the eventual huge success of the Palm. The developers got the product close enough to what the customer wanted, viral marketing kicked in and the product validated an entire market segment.

The same can be said for the success of the Compaq iPaq handheld. WinCE (Pocket PC) machines failed one right after another until Compaq came up with a product the customer found acceptable. No amount of market research could foretell the success of this product and the failure of others that appear so similar.

Unfortunately, the design environments at most companies today are so cumbersome that it takes far too long to get product into the hands of the customers in the current fast-evolving market. Why not design products that may not be perfect, but are “good enough” and place them in customers’ hands as quickly as possible, and then use customer feedback to refine the product for greater customer acceptance?

But instead, most design teams are still structured as if they were designing mainframe computers when they should be structured like the music recording companies. Record companies don’t expect songs, or even groups, to last for a long time. Hence they’re like sharks – always moving. Companies who want to continue to exist must adopt a similar mindset. If they don’t, they’ll resemble a record company with a bunch of great disco groups in their portfolio and will have about an equally good chance of surviving.

Some rules for achieving a Lean Design

There are many ways to streamline the design process. Here are a few techniques that have been shown to work well:

Treat every project like a VC start up – A traditional VC-backed start up usually goes through several funding rounds before it becomes self-sustaining. Each round is typically funded for a specific purpose and the deliverables are measurable.

If a team knows that they only have a given amount of money in the “bank” they will stay focused. The funding for the next round should be treated just like a VC would; if you don’t meet your goals with a given amount of funding, you should have a good reason why not and be able to convince the company to fund your next round.

Keep the team small – Each additional person added to the team greatly increases the number of interactions that occur between team members. Only add team members when there is a clearly defined task for them to do and using one of the existing team members would decrease the team’s efficiency.

Don’t make it if you can buy it – Most companies develop the majority of the their new technology internally. Others will pick up outside technology on a sporadic basis. A few, like Cisco, build a large percentage of their Intellectual Property base via acquisition. In general, Cisco has been successful with this approach but others have failed. Still the concept is interesting; let the VCs and entrepreneurs plant the seeds, nurture them, weed the garden and fight off the pests. Then when the flowers bloom (if they do), buy the flowers that you like.

The company wins, the VCs win and the entrepreneurs win. Another benefit is that an acquisition can reduce time to market. Having a product to sell today is usually much more useful than having the same thing a year from now. Is it possible to acquire just the product, not the company? In a similar fashion, acquire bits of technology instead of developing it yourself. For example, there is no reason to build your own operating system when there are so many good alternatives on the market at attractive prices.

Developers must know the customer – My first job out of grad school was in an IBM development lab. We were building one of the first point-of-sale systems. One day I wasn’t real busy since I was waiting for others to get me things I needed. My boss noticed and asked me why I was idle. I explained why I wasn’t that busy, and he suggested I get out of the office for the rest of the day and hang around a grocery store and watch the clerks, watch the customers. Figure out how a grocery store worked. Where did stuff come in? How did power and any other required utilities get to the check out station?

Such an approach was a complete eye opener for me and taught me more about what I was doing that any college course ever did. He was completely right, of course. There was no way that we were going to come up with a truly outstanding system if we didn’t completely understand the customer, and we weren’t going to learn all that chained to our desks in a cube farm in South San Jose!

Benevolent dictators work best – Groups seem to work best when they are run like Singapore – there is a benevolent dictator at the top who makes sure that people keep marching in the desired direction. History provides us with some great development leaders who inspired passion in their team members but still kept a firm hand on the tiller. Examples include Dave Packard at HP, Kelly Johnson at the Lockheed Skunk Works, Linus Torvalds with the Linux project and Herb Kelleher at Southwest Airlines.

Version 1.0 is special – Version 1.0 is the first exposure the customer has to the product and the first generator of external cash flow. It is the first chance the development team has to get feedback from real customers. Thus it is vital that Version 1.0 be placed in the customers hands as quickly as possible, and that is done by not including any features that are not absolutely critical. Examine each feature; if the product clearly could not be sold without this feature, then it goes in. Otherwise, omit it.

Have a clearly defined set of features in the next release – This is really a corollary to the above point. The features that will be in the next release should be well defined. Developers often get bored with implementing that which is necessary and drift off into implementing the features that are of most interest to them, but it is highly inefficient and costly to work on features that are not in the next release.

“Feature creep” is a very common cause of slipped schedules. It always seems so easy to add a simple feature that will only take a day to implement. Then it turns out to take longer than a day to implement, impacts some other feature in an unforeseen way, makes the product less stable, and people become unsure of exactly what features are in the next release.

Be prepared for “small” successes – Not even Barry Bonds hits a home run each time he goes to the plate. An article in the September 2001 issue of WIRED noted, “American notebook manufacturers won’t release a new model without assurances that they’ll sell at least 250,000 units worldwide, but Japanese OEMs are far more experimental. For Sony, Fujitsu, Hitachi, Toshiba, Sharp, Casio and NEC, 25,000 is a niche big enough to support a new form factor.” Guess who’s probably going to win over the long term.

Eat your young – Someone is going to kill your current hot selling product. Is it going to be you or your competition? Record companies assume that hits are short lived and so should you. Long term successes are a pleasant surprise but they are not the norm. It’s only a matter of time before someone bests your current model. Make sure it’s you.

Michael R. Corder is an independent software consultant based in Santa Cruz, Ca. Involved in software development for over three decades, he served as CEO of Extenex Corp., a venture backed startup which designed a portable, personal video device using embedded Linux. He can be contacted at mike.corder@micor-research.com

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.