TCP
Home | <Previous Issue | Next Issue> | Issue Archive | About TCP
I s s u e F i v e
March 22, 1999
c o n t e n t s / t h i s m o n t h :
1 > The Early Bird Gets the Worm...
2 > NPD On The Web: "Product Development
Network"
3 > Quants & Quals: The Role of
Information in NPD
4 > Top Ten New Product Realization Book
Titles
5 > MRT News
6 > Calendar of Events
SUBSCRIPTION INSTRUCTIONS
To begin or cancel your FREE subscription, please use the automated form on this page or send me an email - gregg@roundtable.com
Please send any feedback about this newsletter and its content to
gregg@roundtable.com
a r t i c l e - o n e :
THE EARLY BIRD GETS THE WORM,
BUT THE SECOND MOUSE GETS THE CHEESE
If you're a geek like me, you spend a lot of time reading articles and
books that talk about improving product development, manufacturing and overall business
management issues. Enlightening books such as "The Goal," "Lean
Thinking," "Developing Products in Half-the-Time," "The
Innovator's Dilemma" and "Managing the Design Factory," to
name just a few, have a lot of the same underlying common sense behind them. Upon further
reflection, they have driven me to reach what I think is the fundamental conclusion that
ties together this virtual think tank that sits on my bookshelf.
It's simply this:
Sometimes you can do something that appears very foolish, but is
actually very smart, and sometimes you can do something that appears very smart, but is
actually very foolish. Those who can improve their ability to distinguish between the two
have gained the wisdom I think we all desire.
You might modify this by changing the word "do" to the word
"believe", and it still rings true. Let's examine a few examples of what I mean,
and try to bridge the gap many find between applications in manufacturing and product
development:
The Dark Side of "Efficiency" and
"Maximum Utilization"
From The Goal and Lean Thinking, we learn that even a
machine that runs non-stop all the time making parts is not truly efficient, even though
that is typically how they are measured by those who keep score. But how efficient is a
warehouse (which you pay for) full of parts (which you bought materials to make) for
products no customer has ordered? "Aha," say many in the finance department,
"we count those as assets!" This is a classic situation where a point
optimization is heralded with no connection to system efficiency.
Similarly, as discussed in Developing Products in Half the Time
and Managing the Design Factory, people efficiency can be related to machine
efficiency. The same flawed assumptions about downtime of capital equipment can be related
to downtime in the engineering department. Just because a resource is idle is not
necessarily a wasteful situation.
Typically it is assumed that an engineer (or other function) between
tasks costs the company money in the form of unused labor hours, and is therefore
allocated to "filler" tasks or overloaded with multiple projects. However, which
of the following two people is best able to tackle a new priority or unanticipated
development issue? Is it the engineer with the full in-box or the guy who's been surfing
the Internet all day? Which one would anger the "suit" from Corporate who
decides to walk through the cube jungle that day on a whim? Think hard - you could debate
this one with managers for years.
To go further on this thread, Macintosh Evangelist Guy Kawasaki has a
new book coming out in which he extols the virtues of a limited business day. In his
experience, a company that keeps the doors locked before 8am and kicks everyone out at 6pm
GAINS productivity. Hogwash, you say? In this situation, says Kawasaki, you'll find that
with a limited workday (and, we assume, a responsible staff with a clear goal) that people
schedule their time more wisely, are less tolerant of distractions, focus better on their
work, and use meetings more efficiently. Sounds logical, right? I've read in other
credible places that the 60+ hour workweek is a fact of life for the engineer, and they
should find a different line of work if they complain about it. Which view is correct?
There is no question that the ingrained conventional wisdom that most
people follow has the best of intentions in mind. It is when this wisdom is not adequately
challenged, and just blindly accepted, that its original logic breaks down. As Eli
Goldratt once said, "Everyone's behavior is always correct. It is their operating
assumptions that may be flawed."
"Reader
Responses" to this article
* * *
a r t i c l e - t w o :
NPD ON THE WEB
"Product Development Network"
Link: http://www.pdn.com
Are you:
- a world class supplier looking for cost-effective global exposure?
- a world class contractor looking for a cost-effective global sourcing?
- looking for new ways to expand your network of business partners?
Then the "Product Development Network" may be for you. The
stated mission of this on-line service is to help companies find business partners. In the
December issue of TCP, we reviewed a site named Developages (www.developages.com), which
housed a database of suppliers for companies looking to outsource specific aspects or
entire cycles of product development. The 'PDN' seems similar to this, but with a few
differences.
First, they seem very European oriented, quite natural as they are
located in the Netherlands. Second, their website seems focused on very large companies
who have interest in global markets and need strategic partners to accomplish that larger
level of development effort, so this may be less appropriate for companies a lot smaller
than a Motorola or a Lucent. Like Developages, they have an on-line company profiles
database and search capabilities for members, but in addition are attempting to facilitate
community-building through events and electronic forums for discussing the nitty-gritty
details of development such as "adhesive bonding" and "precision sheet
metal supply chain management".
Know a website we should review? Send the url to gregg@roundtable.com
* * *
a r t i c l e - t h r e e :
QUANTS & QUALS: THE ROLE OF INFORMATION IN NPD
Guest article by Alex Cooper, President, Management Roundtable
Over the past couple of years, I have realized that more often than not,
the success of most product development efforts hinge on the effective use and management
of information. Since all information is not created equal, it is how information is
gathered, captured, communicated and interpreted that makes all the difference in product
development.
The sheer quantity of information involved in the development of new
products is staggering. There is information about customers and from customers, about
suppliers and from suppliers, there is information from competitors and information about
competitors. There is information about your products, and there is information about your
processes and capabilities. There is explicit information and there is tacit information.
How your organization deals with this volume of data is probably a reflection of the
effectiveness of your cross-functional product development process.
The problem is that the value of information varies. It varies with
time. You wouldn't pay a lot of money for yesterday's winning lottery number, but you
would pay considerably more to get the winning number before tonight's drawing. The value
of information also varies with interpretation. Some people (Quants) love to analyze
quantitative information, while others (Quals) would prefer to analyze qualitative
information. One likes numbers, the other likes words and contexts.
The Quants look for patterns in quantitative information to help draw
conclusions and make decisions. These decisions can range from how to optimize the
allocation of resources to manage all the projects in the pipeline to what market segments
they should target with their next product.
The Quals on the other hand, will look at information that is difficult
to quantify to make decisions. They may watch videotapes of customers interacting with
products in everyday life, or they may pick up on some key phrases in a customer interview
to help guide key product definition decisions.
Both of these approaches have merit, but the reality is that most
organizations need a balance between the Quants and the Quals. The unfortunate reality is
that while there may be conflict between the Quants and Quals, there is often conflict
within each camp. Recognizing the inherent conflict around the approach to and the
interpretation of information is the key to the effective management of information in the
product development context.
* * *
a r t i c l e - f o u r :
TOP TEN NEW "PRODUCT REALIZATION" BOOK TITLES:
...from the MRT home office in Lexington, Massachusetts,
10. Beyond Beyond Lean: Achieving
Organizational Anorexia
9. Theory of Complaints:
Eliminating Whiners (Because They're the Real Bottleneck)
8. Nine Sigma: Quality
Improvement For The Bored and Anally Retentive
7. The Procrastinator's Dilemma:
How Time-to-Market Pressure Can Cause the Slowest Firms to Fail
6. QFD for Dummies: The Ten
Minute Matrix and the Lean-To of Quality
5. Design of Spearmints: Finding
A Robust Flavor For Your Candy Products
4. The Un-Learning Organization:
The Art and Science of Strategically Repeating Mistakes
3. In Search of Accidents:
Innovative Ways to Eliminate Your Competition
2. Cover Your Ass! - The
Manager's Guide to Plausible Deniability
...and, finally, the No. 1 New Book on Product Realization:
1. Clinton on Market Development:
"I Did Not Have Inappropriate Customer Relationships With That Market Segment"
Thanks to Anthony Mills for this month's top ten list
submission.
Send your Top Ten List suggestions to gregg@roundtable.com
* * *
a r t i c l e - f i v e :
MRT NEWS
As Alex Cooper mentioned in his guest article above, information's role
in the value creating activities of product development are increasingly coming into
focus. To examine and share how leading companies are using information as a strategic
tool to forge customer relationships and thwart competitors, Management Roundtable is
pleased to announce a new conference to show how to get your organization's wealth of
existing information assets to start paying off:
"Accelerating New Product Development Through the
Strategic Use of Information" will be held June 7-8, 1999 in Cambridge,
Massachusetts. This exclusive conference features:
- Keynote presentation by Michael Cusumano, MIT Sloan School of Management
and author of "Microsoft Secrets" and "Competing on Internet Time: Lessons
from Netscape and its Battle with Microsoft"
- Case study presentations from Advanced Micro Devices, Fidelity
Interactive, Ericsson, Blue Cross/Blue Shield and others
- FREE BONUS REPORT: Every attendee will receive a
complimentary copy of the exclusive report from Nextera -- "Fueling Growth and
Innovation in the New Enterprise"
For more information: http://ManagementRoundtable.com/ANPD.html
* * *
U p c o m i n g M R T e v e n t s
"Product & Process Leadership Conference"
April 6-9, 1999 - Boston
http://ManagementRoundtable.com/PPLC-99.html
"Product Portfolio Management:
Balancing Resources with Opportunity"
May 10-12, 1999 - Cincinnati
http://ManagementRoundtable.com/PPM.html
"Developing Products in Half the Time"
w/Cycle-time reduction expert, Preston Smith
May 20-21, 1999 - Detroit
"Accelerating New Product Development
Through the Strategic Use of Information"
June 7-8, 1999 - Cambridge, MA
http://ManagementRoundtable.com/ANPD.html
* * *
A D M I N I S T R I V I A
The Critical Path is a free monthly e-mail newsletter
written by:
Gregg Tong, Director of Product Development
Management Roundtable, Inc., 1050 Waltham Street,
Suite 410, Lexington, MA U.S.A.
Tel: (781) 676-0606 Fax: (781) 676-1951
Gregg@roundtable.com
Please feel free to forward this publication to any friends or
associates you feel could benefit from its message. We welcome any suggestions, stories or
comments that will help us improve the value of this newsletter. Please contact me
directly with your input.
This newsletter and archived issues can be retrieved directly from our
website at the following url: http://ManagementRoundtable.com/Critical-Path-Index.html
SUBSCRIPTION INSTRUCTIONS
To begin or cancel your FREE subscription, please use the automated form on this page or send me an email - gregg@roundtable.com
For more information on Management Roundtable's events, publications,
and services: http://ManagementRoundtable.com
Copyright 1999 by Management Roundtable, Inc. All rights reserved.
# # #
TCP
Home | <Previous Issue | Next Issue> | Issue Archive | About TCP
Reader
Responses
Dear Critical Path:From one fellow geek to
another...
Birds/Worms - Mice/Cheese: I agree with you that sometimes
what appears to be a smart thing to do was really stupid and some of the ideas thought to
be stupid or of low affect turn out better than anticipated.
One thing I use to "test the waters" of new idea
soundness is a question. After we have tried something new I go to the person or persons
affected and ask: "Would you like to go back to the way it was?" Then after a
"Yes" or "No" answer I ask "Why?" This is sort of like
Toyota's "5 Why's" in reverse when a "Yes" response is given. You can
not only find out from the one(s) affected "Why" an idea didn't work but also
"Why" the idea worked.
The important point being from the point of view of
"the one(s) affected." Sometimes ideas work or fail for more reasons than what
the implementers had imagined. Asking this question has showed me that the gains from lean
manufacturing are far more reaching than what us implementers of lean can imagine.
Needless to say it takes some guts and a bridled tongue to
venture out on the floor and ask "Would you like to go back to the way it was?"
after a cell has been set-up. But the risk is worth the knowledge gain and it is also a
SURE way to find out if what you are encouraging to happen really helps the ones you hoped
you were helping.
TCP: Root-cause analysis is something I
think we all agree is worthwhile, but that few can accomplish accurately. To properly
identify the causes of problems and constraints requires both courage and
"truth-handling" ability. It takes courage to continually ask questions, and to
dig deeply enough while surfing uncomfortable situations with people who may think you are
seeking information to be used to invoke "blame and shame". Rarely will the
answers to the first 2 or even 3 questions reveal the truth (Toyota has FIVE
"why's" for a reason). But it also takes high self-esteem and "internal
objectivity" to keep your own biases from contaminating analyses.
I suggest that people practice the five or more
why's with themselves first. Pick a "belief" that you hold to be
"true", and go about figuring out why it is true and why you believe it. Be your
own devil's advocate and also come up with the available reasoning that someone with the
opposite belief may hold. Find your flawed assumptions. Be honest with yourself (very
difficult!). And lastly, don't be afraid to face a situation where you may have to change
your mind about what you believe. The earth may not be flat after all...
On down to the part of your article on the "full
in-boxer" vs the "net surfer..." The former owner of Hi-Stat once said to
me that when he has a task to be accomplished he always gives it to the busy person. He
went on to say that a busy person will find the time to do it.
Maybe the correct comparison is the appeal to complete a
task vs someone called upon to be creative. Completing a task make take creativity.
Creative time management for sure on the part of the "busy / full in-boxer"
person. But what about the "not busy/net surfer" person. Is this person more
creative because they are surfing the net? Whoooom.... Maybe! Maybe Not! Depends...
As for which one would anger the corporate cube stalker
(CCS). Who knows? I would guess that if the CCS knew his people he would judge what he
sees on the day of his stalk based on what he knows the cube sitter produces. If he sees a
non productive person surfing he'll react negatively. If he sees a non productive person
with a full in basket he'll more than likely react negatively. On the other hand a person
surfing with a good track record of task completions will probably generate curiosity on
the part of the CCS.
TCP: Let's just hope the CCS is not DPHB
(Dilbert's Pointy-Haired Boss ;- ).
In our case it is a known fact that those who accomplish
much get more tasks and those who are not known for their accomplishments are avoided when
it comes to new task assignments. This culture is not good either and we in supervision
are trying to change it. As for Kawasaki I would like to suggest you create an environment
that fosters self motivation within a focused environment and then open and close the
doors from 8:00am to 6:00pm. Within my group I have one engineer that works a lot of
overtime and basically the other 5 engineers go home at the bell. The one who works over
tends by his nature to never get out of this mode. The others, even though they work very
little overtime, seem to accomplish as much. I think if I made the one who works overtime
go home by 6:00pm he would find a way to get it done...(mother is the necessity of
invention).
Well in the immortal words of Forrest Gump, "That's
all I got to say about that..."
Bob Schroer
Wizard of Wow
Hi-Stat Manufacturing
TCP: Bob, again to take TOC out of the shop
floor, what you describe in your own resource allocation seems backwards from
"exploiting the constraint". If you underload the unproductive staff and
overload the productive staff, the "bottleneck" gets less work, not more in
their queue, and I have to assume the whole system suffers (please correct me if I'm
wrong). The problem here is that all things aren't equal with people as they seem to be
with machinery, balancing the load is much more tricky since output is less predictable.
Add the tricky dimension of distributing "priorities" and you've got quite a
juggling task. What you end up with is a situation that looks unfair to everybody. You say
you are looking to change that. I hope you can. What I'd love to see is an environment
with mixed levels of productivity that are arranged together to optimize the system while
keeping staff happy. Can it be done? I bet someone out there has it.
Kawasaki's recommendation obviously would have
trouble being implemented in the majority of today's workplaces, however, I do believe it
should be a goal for most of us. I think overworking is as much to blame for societal
decline as Jerry Springer and Marilyn Manson, it's just not as simple to accuse. --Gregg |
Return to MRT Homepage
© Copyright 1999 by Management
Roundtable, Inc. |
