GGI Legacy Site

We have a new look. Please see our new home page.


GGI RapidNews R&D Product Development eZine: Volume 2, Issue 7- September 6, 2001
GGI RapidNews is published monthly


You are cordially invited to an Open House at our new office in Needham, Massachusetts at 1346 South Street on Friday September 7, 2001 from 3:00 until 8:00 PM. We will serve light refreshments. You are welcome to bring your spouse or significant other. Please let us know the number in your party RSVP by calling Jon Gilmore at (781) 444-5400 #202 or e-mailing Jon at Directions to GGI may be found at In short, find Route 135 off Route 128 and head west towards Needham. At the first light, take a left onto South Street. GGI is #1346, about 4 miles down South Street just before you cross the Charles River.


Calendar of Conferences & Seminars: We are greatly invested in maintaining a comprehensive up-to-date Calendar Gateway on our website for your use. It is perhaps the most comprehensive listing of events in North America. If you want to know what your choices are, this is the place to go. Listings are categorized into nine topical areas, including product development, software/Internet development, metrics, project management, marketing and sales and the like. Point your browser to .

Grammar & Punctuation: This Gateway should assist all those who spend more time than they might like fracturing the English language. Consisting of links to Internet-based dictionaries, thesauruses, punctuation, grammar, quips & quotes and toast sites, this gateway offers everything from punctuation lessons for the verbally-handicapped to ice-breakers for toastmasters. Have a look at

Technology Providers: GGI continues to build gateways listing suppliers of products and services of all types. We have now created a resource that is starting to be competitive with the Thomas Register, MMNI, and other similar websites. GGI's Technology Provider Gateways are focused on the needs of product developers, in contrast to other sites that are perhaps more focused on product manufacturers. We have grouped our listings into three areas which collectively may be found at

  • Software
  • Hardware - Electrical/Electronic
  • Hardware - Mechanical

The new software Gateways posted this month span several functions and/or industries.

CAD/CAM/Shop Control
Statistical Process Control
Sales Management
Imaging Data and Visualization Technology


2000 Metrics Survey: Free downloadable copies of the 2000 R&D Metrics Survey Description and/or Survey Questionnaire are available in our Market Research Reading Room at You will also find free downloadable files for GGI's 1998 Product Development Metrics Survey. The 1998 and most 2000 Metrics Survey results are available for purchase at

A reader wrote to suggest metric survey information reported in last month's RapidNews was not clear. He suggested we make clear the differences between the one- and two-step product selection processes since "the basic idea is really critical to NPD."

In One-Step Selection Processes the "deciding management team" reviews the product/project proposal a single time and makes a yes/no decision. In Two-Step Selection Processes, a product/project proposal is reviewed two times. Typically in Two-Step, a rough concept is reviewed at the first review. The product definition and project planning phase is then executed. The second review focuses on the detailed product definition and project plan. Kittens may be drowned at any review, or allowed to grow up and become cats. In addition to other benefits, Two-Step Processes can save many resources by drowning the ugliest kittens at the first review before significant resources have been invested. This frees up capacity so more "good projects" can completed.

GGI surveyed One-Step vs. Two-Step Product Selection Processes using two methods. First, we grouped all the projects that each individual company reported into a total number of projects for companies using One-Step and then did the same single total number of projects for companies using Two-Step. We then calculated the "approval rate" for each group. This approach could be called the "Aggregated Project View." Second, we calculated the approval rate for each company using One-Step and averaged the results across companies. We then did the same for companies using Two-Step. This approach could be called the "Average Company View." The first bullet below describes the Aggregated Project View. The second bullet describes the Average Company View.

  • When all survey respondent "One-Step" projects were totaled, 59% were approved. When all "Two-Step" projects were totaled, the "net yield" across the two decision points" was also 59%. Therefore, the "net yield" of the "Two-Step" was the same as the "yield" of the "One-Step" for the Aggregated Project View. This lead us to conclude that the "Industry Rate At Which R&D Projects Are Adopted For Development Is 59%."
  • Companies with traditional "One-Step Product Selection Processes" approved 64% of all products/projects proposed. Respondent companies with "Two-Step Product Selection Processes" approved 62% of products/projects at the first product selection decision point (milestone), and 67% of all remaining products/projects at the second product selection decision point. Therefore, the "net yield" across the "Two-Step Process" was 42% (.62 x .67). This lead us to conclude that Two-Step processes result in about 33% less projects being approved ((64-42)/64). It is well known that R&D organizations are loaded 50% to 100% over their capacity. The Two-Step process seems to result in significantly better capacity management, along with several other benefits.

Our next R&D Metrics Survey will be conducted early in 2002. If you would like to participate at that time, please send an e-mail to expressing your interest. One of the goals of the 2002 survey will be to determine product success rates for companies using One-Step vs. Two-Step Product Selection Processes.


Japanese Goal To Improve Innovation:
"It wasn't that long ago that we were all reading books and business journal articles about why Japan was working science and technology so much more handily than the rest of us. Japanese technology was flooding the world and other economies suffered. Now Japan isn't doing so well--it's economy is down and it is agonizing over why Japanese scientists don't win Nobel Prizes (Japanese scientists have won six in the last 50 years; US scientists have won 44 in the last 10). What, the Japanese wonder, are we doing wrong?

As US technologists did a generation or two ago, they are coming up with answers.

"Rice farming," says Hideki Shirakawa, one of the country's few Nobel laureates (chemistry, 2000), who now spends more time heading a new national commission to re-energize Japanese science.

Rice cultivation requires a lot of water, he explains, and water must be shared evenly by everyone. Planting rice also requires teams of people walking from row to row, at the same speed. This, he thinks, has made suppression of individual innovation a national characteristic.

Other Japanese see more direct failings. Excessive government control over research funding and education have lead to a generalized tendency for seeking incremental advancement of knowledge rather than bold experimentation. Faculties are still awash in Confucian ideals of age-grade promotion and piety toward seniors.

Still more to the point, disillusioned scientists say the country's research community has never fully embraced peer review and criticism. In the West, this leads to the kind of interplay that leads to more creative work.

Japanese science critics say there is a lack of competition and critical evaluation in Japan. Promotions don't depend on the size of one's contribution but on years of service. Scientists would rather be friendly than debate.

So what's a few Nobel prizes as long as you keep turning out Walkmans, Sony Play Stations, and electronic gadgets galore? The Japanese worry: Plenty. Mired in recurrent recessions for 11 years, the Japanese suspect that the underperformance of the world's second richest economy in science carries a steep cost. It costs in issues ranging from fighting malaria and AIDS to understanding global warming. It costs in being part of what's going on.

Not able to shake the national character, Japan has increased research spending dramatically from the early 1990s. Focus has been on the shoddy state of the country's university labs. Goal is to break out of the scientific ghetto of applied research. Japan now spends half as much on scientific research as the United States and more than twice as much as Germany, its closest rival in the West. In 1995, 9% of the articles in scientific and technical journals were by Japanese authors.

But Japanese scientists still tend to pick easy projects, building on things that are already known, so they can expect results quickly. And this gets back to the lack of true peer review, which gets back to national culture. You still don't want to speak openly in criticism of someone else's work."

Written by: Charles Joslin, Senior Analyst, Technical Insights, Frost & Sullivan, 90 West St., New York, NY 10006-0103. Phone: 212-652-2750. Fax: 212-619-0831., Copyright 2001, Frost & Sullivan, New York, NY 10006


IQPC - Best Practices In Web-Enabled Collaborative Product Design: In addition to delivering the keynote address for this August conference, Brad Goldense also spoke on the subject of "Designing An R&D Website For Competitive Advantage." This presentation caught the attention of many attendees who were more focused on building collaborative group-think features into their R&D websites. Brad cited an Arthur D. Little study that showed product developers spend a great deal of their working time alone. He suggested companies were investing the majority of their R&D website resources in areas where product developers were spending significantly less time. This phenomenon was partly due, Brad suggested, to the inordinate influence technology suppliers have on corporate spending policies, and the lack of in-house IS understanding about the exigencies of the engineering and technical development functions. IS professionals can more easily understand collaboration and project management than the needs of engineering and R&D. This phenomenon is also due to corporate misunderstanding about how product developers spend their time. Therefore, too much money is now being spent in areas where little corporate return will be realized.

Management Roundtable - 6th Annual Metrics Conference: The two conference Keynote Speakers are Mssrs. Donald Reinertsen and Robert Cooper. They will discuss "Using Metrics to Compete for Scarce Resources" and "Maximizing the Value of Your New Product Portfolio."

Mr. Reinertsen will discuss how many companies think of metrics primarily as a control tool, a tool for ensuring that projects conform to requirements, budgets and schedules. However, certain metrics play another role in a world where resources are constrained. By communicating project economics to management they can aid management in allocating its scarce financial resources. When developers fail to use metrics in this way they are at a great disadvantage when competing for scarce resources.

Mr Cooper will discuss how two ingredients must be in place to maximize the value of your development portfolio. The first is data integrity. The second key is applying the right tools, metrics and scorecards to gauge the value of your projects and portfolio. In his talk, Dr. Cooper outlines various methods to maximize the value of your development portfolio, and provides proven metrics for gauging the value of each development project. An effective scorecard for use in portfolio review or gate decisions sessions is highlighted. And techniques for rating and ranking projects to yield project priorities - a prioritized or rank-ordered list of active projects - are described.


Collaboration: It is occasionally worth reminding ourselves just how difficult the product development concurrency processes which we frequently discuss are where the "rubber meets the road." Why do R&D functions so often find concepts like teamwork and collaboration more difficult to manage "on the ground" than tasks like engineering design? Isn't it because "collaboration management" is largely about managing people to a shared objective, and aren't people often very difficult to manage? People have highly individualistic personalities, vastly different skill sets, often conflicting objectives and, in R&D at least, spend much of their time working alone, rather than teamed. A skill not practiced... Small wonder collaboration proves difficult.

At last June's Society of Concurrent Product Development (SCPD) conference, I listened closely to two presentations on "people management," which I differentiate from task management. J. Douglas Field, VP of Product Development at DEKA Research and Development Corporation and Jeffrey Davis, Chairman and CEO of MAGE, LLC spoke respectively about "Engineering From the Right Side of the Brain" and "The Economic Value of Emotional Intelligence." Douglas emphasized DEKA's special environment for technological innovation, while Jeffrey spoke about emotional intelligence (EQ) as more important to company profits than either subject matter expertise or rational intelligence (IQ). These presenters made their people points differently, but both said essentially the same thing: you can't get company innovation and profits without a collaborative environment. And you can't get a collaborative environment without good people function. And you can't get good people function without emotional intelligence, i.e., people skills. You didn't need a Ph.D. in syllogistic logic to understand that these presenters thought people management skills and innovation/profits were interrelated.

The following July, The Management Roundtable's (MRT's) Product Development Best Practices Report carried information on an industry poll they conducted which "...found that culture was the most frequently cited obstacle to effectively implementing collaboration technologies." Only "10% of respondents reported seamless electronic data-sharing between their firms and suppliers and customers." One might reasonably ask that if collaboration isn't working well with people why would it work any better with software? Might engineers have a predisposition for technology solutions? Could NPD/R&D engineers self-select, like hammers in search of nails, for technology fixes instead of focusing on other means to understand and more effectively respond to competitive marketplace pressures? Does the cultural collaborative obstacle, to which the above poll refers, sound a little like Pogo's lament: "we have seen the enemy, and he is us?".

RapidNews is an e-mail publication from Goldense Group, Inc (GGI). Its subject matter includes survey findings, company news, book reviews, key industry conferences and R&D information of interest to clients and associates. Please send communications to rn(at) Thank you.