“We must increase our IC development productivity!” is the persistent invocation from semiconductor industry executives, and it’s getting louder by the day.  It’s not surprising. Yet when I ask the question, “What do you mean by productivity?,”  executives and R&D managers often give vague answers.  Few seem to have a firm grasp of the definition, other than saying “we need to finish projects on schedule, reduce development cycle times and use fewer engineers.” As a characterization of the benefits of boosting productivity, it’s not a bad start.  

It reminds me of U.S. Supreme Court Justice Potter Stewart’s comment in a landmark First Amendment case in which he described the challenge of defining pornography: “Pornography is hard to define, but I know it when I see it.”  Maybe semiconductor executives are saying the same thing: “Increased productivity is hard to define, but I know it when I see it.” Justice Stewart subsequently recanted, concluding that pornography can be indeed defined. So too can productivity.

As a starting point, consider the U.S. Department of Commerce (DoC)’s definition of manufacturing productivity:  “Output divided by Labor-input.”  Output is the difference between the widget’s selling price and the cost of materials comprising it. Labor-input is the effort expended on manufacturing it (in person-hours). The dimensions of manufacturing productivity are therefore:  Dollars per person-hour.

We can use a similar approach to quantify IC development productivity:  Output/Labor-input.  However, Output must be a calculation of the design’s complexity as opposed to value-add. That’s because complexity is a measure of the development team’s output.  For the moment, let’s assume we can calculate it—a challenge, but one that’s definitely achievable.

Labor-input, the denominator, is the total effort the IC development team spends on the project from start to finish. The start milestone is “begin concept definition.”  The finish milestone is release-to-volume production. Consistent accounting from one project to the next is a must. Also, it’s more reliable to use full-time equivalents (FTE’s) instead of counting person-hours, where one person working full-time for a week is a an FTE, or a “person-week.”  

Adapting the DoC’s mfg. productivity definition to IC development productivity yields a productivity metric whose dimensions are:  Total IC development effort expended divided into the chip’s design complexity (i.e. “Complexity/Effort”).  The key question of course is how to accurately calculate design complexity?

Comments

Mark Wehrmeister

10/29/2010 5:38 PM EDT

Design complexity is less important than the value to the customer. Presumably, a more complex design will have greater value to the customer and fetch a higher initial price. Instead of trying to measure design complexity, use the market price for the result of that design as a proxy in the calculation of productivity.

Sign in to Reply

RCollett

10/30/2010 6:05 PM EDT

Mark,

No doubt that value to the customer is the most important metric in business. And using a product’s revenue (or profit) as a measure of Output is very useful. However, in most cases it yields an incomplete picture because revenue is the result of the Output of the entire enterprise, not just the R&D organization. For example, high revenue could be the result of powerful marketing and sales, as opposed to superior engineering. This actually is very common — a strong sales/mktg. organization masks a weak R&D organization. Likewise, the revenue for a particular product line might be very low because of poor mktg/sales, but the productivity of the R&D organization could be very high. Thanks for your comment. Ron

Sign in to Reply

Luis Sanchez

10/29/2010 10:25 PM EDT

On schedule, within budget and less engineers.
That’s simple isn’t it?
But… we engineers like numbers so an equation is required for IC productivity.
To measure complexity… I bet there ought to be some efforts being done already trying to measure that. In some top rated university in the US.

Sign in to Reply

RCollett

10/30/2010 6:13 PM EDT

Luis,

One approach is to use a model that calculates the amount of effort the average development team in the particular industry segment would expend on that project. Then compare that effort value with the amount that your team actually spent. If you spent less, then you were more productive. If you spent more, then you were less productive. Since this isn’t a forum for commercials, I’ll direct you to www.numetrics.com where there is further info on this. Thanks for your comment. Ron

Sign in to Reply

Frank Eory

10/29/2010 10:34 PM EDT

This reminds me of stupid management metrics like “lines of code per hour” for software engineers and “gates per hour” for hardware engineers. It also reminds me of an old Dilbert cartoon in which managment was paying bonuses for verification engineers to discover bugs — which quickly lead to collaboration between design & verificaton and a cartoon panel in which one of Dilbert’s colleagues was coding a minivan worth of bugs!

Sign in to Reply

RCollett

10/30/2010 6:16 PM EDT

Frank,

I completely agree with you — “lines of code” and “gates” or transistors, etc. are wholly inaccurate measures of output, and to use them invites misleading results and misguided behaviors. Thanks for your comment. Ron

Sign in to Reply

zeeglen

4/25/2011 8:38 PM EDT

Tell your managers to tally “capacitors per hour”. Use 0.001uf instead of 0.01 and 0.1…

Sign in to Reply

zeeglen

4/25/2011 8:41 PM EDT

Yeah, I know, meaningless when applied to silicon design. But the managers don’t know that.

Sign in to Reply

Himanshu_Gupta

10/30/2010 7:32 AM EDT

attention grabbing title Ron! productivity is easier to define in manufacturing units as one need to simply check the end results but during research and development, i do not think the productivity is as simple. One way to check productivity can be through the return on investment as everything is about money in the end.

Sign in to Reply

RCollett

10/30/2010 6:30 PM EDT

Himansuhu,

Definitely want to use revenue (and profit) generated from the product — to calculate the return on R&D. However, what if you have a really poor sales & mktg. and very productive R&D organization? If revenue is low, it appears that the return on R&D is low. Although financial measures that use revenue and profit can be very valuable, they can give a distorted picture. Metrics that, to the greatest extent possible, directly reflect the output of a particular organization provide the most insight when analyzing a business. Thanks for your comment. Ron

Sign in to Reply

yalanand

10/31/2010 2:11 PM EDT

True RCollett, I agree with you that financial measures are very deceptive while measuring productivity.

I have specifict question for you.Since I belong to service based company I want to know how do you measure the productivity for service based companies ?

Sign in to Reply

RCollett

11/1/2010 2:56 AM EDT

Yalanand,

For a particular service engagement:

(Total dollars billed for the Service – Total fully-burdened cost of delivery of that Service)/(Total person-hours expended on that engagement)

The numerator is the your firm’s value-add. The denominator of course is the effort expended to deliver that value-add to the client.

Thanks for the comment.

Ron

Sign in to Reply

phoenixdave

10/31/2010 3:58 PM EDT

@yalanand:If your are based on a hourly service rate, your billable hours (within the established budget) would be a start.

Sign in to Reply

iniewski

11/1/2010 12:36 PM EDT

Rob,I think we agree that the final value of IC (or any other product) is determined by a customer (market). We also agree that this is has to do with Sales & Marketing effort to the same extent as R&D. Trying to separate R&D from that total is tough, if not impossible. What if my team designs very complicated, sophisticated product in half the time, a product that nobody wants! Is that R&D productivity? Kris

Sign in to Reply

RCollett

11/2/2010 11:25 AM EDT

Kris,

If your R&D organization uses half the effort that another organization would expend to design an equivalent product, then your organization’s productivity is twice as high. If as you say, nobody wants to purchase the product, that’s the fault of marketing and perhaps other parts of the enterprise, and it is wholly unrelated to the development productivity of the R&D organization (unless the R&D organization had exceptionally heavy influence on the product definition or other marketing-related tasks).

Rgds,

Ron

Sign in to Reply

prabhakar_deosthali

3/7/2011 5:39 AM EST

Like someone has commented, to be able to measure productivity of a person or a team we must be able to measure or estimate correctly the amount of work done. We must also be able to measure the complexity of the work done and then add appropriate weight-age to the amount based upon the complexity. The same number of lines of code written for an offline application is less complex than those written for a time critial real time application with a tight memory budget. If such metrics are evolved then only we can truly measure the productivity for a given development project team.

Sign in to Reply

RCollett

4/25/2011 7:42 PM EDT

Prabhaker,

You are correct. Our customers use an empirical model we developed. It calcuates the amount of effort the average team in the industry would spend on that project. It’s quite accurate — coefficient of determination (R-squared) is over 0.9 (i.e. Predicted Effort vs. Actual Effort). For more information, you can go to the blog entitled “How Complex is Your Design,” which ran on 11/5/10, or alternatively, you can find a lot more information on our website (www.numetrics.com).

Rgds,

Ron

Sign in to Reply

ATUL SRIVASTAVA

3/7/2011 7:53 AM EST

Instead of a ratio it can be defined more as a percentile . The formula will be roductivity=
(Current project data/ What is the last best data you have for similar project ) X 100
Data can be internal or from the industry sources and you generally factor for any differences due to complexity , geography etc .
This has been practically used by some companies .In one company certain groups are star performers and others are expected to reach upto start groups productivity level .In that case the productivity of star performer team is 100 percentile. This approach is quite practical.

Sign in to Reply

Originally Published at: http://www.eetimes.com/electronics-blogs/other/4210257/Productivity-and-pornography#

Related posts:

1. In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...
2. The Elephant in the Corner Why do so many IC design teams commit to development...
3. Death of the SoC Rumors of the SoC’s impending death have been popping...

Related posts brought to you by Yet Another Related Posts Plugin.

You’re frustrated and suddenly stalled on the freeway and what happens in larger organizations is chillingly clear: a chain-reaction crash that creates incredible chaos across the R&D group.

Missing Schedule

Part of the reason so many semiconductor projects miss schedule is that staffing levels are not aligned with the level of complexity that the design team needs to undertake. This is solvable problem.

Fact-based planning provides the team with data for decision-making—ensuring that projects are staffed properly to meet the demands of the design’s complexity. Estimates of design complexity, project-staffing requirements and development cycle time are generated using empirically calibrated models. This is the heart of Fact-based planning, which is used by top semiconductor companies across the industry.

Fact-based planning

• Eases the traditional tension between groups within the enterprise that struggle to communicate in different languages by guiding discussions and strategy with facts and data.
• Enables predictable revenue streams because it yields accurate schedule estimates, therefore there are no surprise shortfalls in revenue or margins.
• Leads to predictable schedules, which is crucial in an era when time to market is more important than ever, and companies can’t afford to miss the market upturn.
• Doesn’t replace bottom-up, detailed planning but complements it.

Boosting Productivity

Fact-based planning is essential to an important productivity boosting best practice: seeing the project execution pipeline clearly and managing it centrally. This best practice—and the tooling behind it—rolls up all project plans to generate a picture that shows the total resources consumed by all project plans. With this bird’s-eye view of all project plans, engineering managers can observe where there are shortfalls and over-subscriptions role by role, month by month. This becomes an essential tool for managing the pipeline.

This isn’t an airbag that protects you in a chain reaction crash. This is a radar system that prevents the crash in the first place and gets everyone to their destinations safely.

Originally published in EETimes http://www.eetimes.com/discussion/other/4205031/The-ripple-effect

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

From the business perspective of a semiconductor company, Numetrics’ solutions are about making substantial improvements in chip development productivity and schedule predictability. But just what is productivity, and how do you first characterize it and then improve it? What’s the outcome?

Productivity drives development throughput in your R&D organization – the higher the productivity, the greater the throughput. And throughput is a measure of how much product the engineering organization churns out during a given period of time.

There are three ways to boost R&D throughput:

• Add headcount
• Increase work-hours per week
• Raise utilization and productivity

The first two have downside: Raising R&D headcount increases cost, and more hours lead to workforce burnout and high turnover.

The only viable long-term strategies for sustaining high throughput are to increase engineering utilization and productivity.

Utilization

Increasing R&D utilization—the percentage of the engineering workforce’s effort spent on revenue-generating activities—is among the quickest and most effective ways to boost throughput. That’s because it essentially increases R&D resources without incurring additional cost.

Organizations struggling with low utilization find their engineers spend more than half their time on non-revenue-generating activities, such as sales, customer support, and product support – all of which should be handled by different groups. In large companies, that means millions of dollars a year are being squandered.

Engineering organizations in best-in-class companies, however, spend 73 percent of their engineering time on activities that generate revenue and create persistent value. By shrinking the amount of time engineers spend on projects that get cancelled, non-core research, myriad internal initiatives, and so forth, companies can significantly raise their utilization rates and, in the process, reduce R&D spending and/or develop new revenue-generating products.

Productivity

 Productivity – the second factor driving throughput – is the amount of engineering output per unit of labor expended to create that output. Productivity is a function of efficiency. Only by improving efficiency will productivity rise. Analysis of R&D efficiency compares the effort a particular set of engineering tasks should consume to what they actually consume. Reducing the effort needed to complete a set of tasks raises efficiency, which increases productivity, and this gives rise to higher throughput.

Boosting productivity requires a reliable measurement system–one yielding accurate baselines and fair comparisons. Additionally, a robust measurement system paves the way for managers to determine the absolute minimum staffing projects need to finish on time. At that point, the projects are “optimally understaffed,” which means the projects can be staffed to levels that assume the teams will meet an improved productivity level.

And there’s where best-in-class companies are pushing the productivity envelope.

Originally published in EE Times http://www.eetimes.com/discussion/other/4201131/How-productive-is-your-R-D-organization-

Related posts:

1. Optimal Team Sizes for Chip Projects What’s the optimal team size for a given IC...

Related posts brought to you by Yet Another Related Posts Plugin.

At the application-segment level, Patrick Moorhead, marketing vice president with AMD, joked:

“I’ve been hearing that the desktop market is dying for the past 15 years.”

He made that quip after holding up the “4th screen” examples he had brought with him: an iPad and a Sony eBook reader. “Only 5-10% of consumers back up their data, so a fixed device will always be in the home,” Moorhead said.

I agree. While I like the professional security that a proliferation of leading-edge microprocessors brings, I am burdened by the yearly upgrade rotation I am now on to keep current the six-plus PCs in my home. All of us in the semiconductor industry have been through multiple iterations of the tablet device, some of them from Apple. As was often said by the panel, “it’s not an either-or these days.”

Fellow panelist Naveed Sherwani, CEO of Open-Silicon, Inc., added “the new form factor will succeed if it is useful.” So, panelists agreed that the iPad is not a desktop (or even laptop) killer. The question is: Will the average consumer add yet another device to the list of electronic gadgets we carry around each day?

The panel shifted to the technology level and wrestled with an intriguing question: Will ARM replace x86 in the desktop or will x86 replace ARM in the SoC market? While some in the audience checked email on their smartphones, Sandeep Shah, director of marketing and applications at Marvell Semiconductor, Inc., and Sherwani tackled the question.

Shah argued that an “ARM architecture licensee can bring together the best of both worlds.” (This is a very interesting perspective in light of Apple’s recent purchase of Intrinsity, which worked with Samsung to develop the ARM Cortex-based A4 processor.)

Shifting processor sands

Sherwani was quick to add that while there really hasn’t been an attempt by x86 to take over SoC design, that doesn’t mean an attempt isn’t brewing:

“In the next three years or so, things will get more competitive and more intense, when x86 is available for SoC development.”

Then it was time to move on to another much-discussed technology challenge, low power design. The panel members pulled out their different battery-powered devices and rattled off the actual vs. published battery life. “What we really need is more disclosure, a ‘truth-in-battery-life’ from silicon providers,” Moorhead said.

Shah, who probably lives power issues on a daily basis, talked about how the different Blackberry models used different chips from Marvell to get different power performance in the system. Marvell focuses on both system-level and gate-level approaches to power management. Sherwani wrapped things up from a design perspective saying “we have just scratched the surface on lower power design.” Maybe what we need is a Moore’s Law for low power design – something that will challenge engineers to do things that today are viewed as impossible.

All in all, the GSA luncheon was a great opportunity to re-connect with fellow semiconductor engineers. We exchanged cards with the same cell phone numbers, but with new company names, new titles, and new addresses. We talked about how tough things have been but how happy we are to be traveling less and spending more time with our families.

It felt like the calm before the innovation storm. I don’t know about you, but I’m here and getting ready for it.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Sometimes the simple questions are the most vexing. That hit me this week while participating in a DesignCon panel in Santa Clara, moderated by EDN Executive Editor Ron Wilson.

The title seemed easy enough: “Getting to Design Quality Closure Without Compromising Productivity.”

But really, what IS quality? How do we define it?

My fellow panelist, Camille Kokozaki, president of Design Rivers, quipped “It’s like pornography: you know it when you see it.”

Piyush Sancheti, senior director of business development at Atrenta, came close:

“Quality is meeting the design objectives you have: whether it’s area, power, timing functionality, or, in a broader sense, customer expectations. Productivity is getting there.”

Sancheti then added:

“Being able to measure it (productivity) with tools like Numetrics is important because you want to hit your objectives as fast and effectively as possible.”

Not surprisingly, our panel wrestled with one of the big issues in design quality today: verification. It deeply affects design quality and productivity. Sancheti noted that for some teams, 70 percent of the entire design development is spent on verification.

What I see first hand from customers is they struggle to understand how verification affects their productivity. Some program managers I talk to say:

“I understand the scope of logic design and physical implementation. Verification is an unknown for me. If I give the verification team another two months, they’ll take it, but how do I know that we’re better off?”

So, I think we’re seeing that verification needs to come up with some sort of model of completion so people can move on. And that’s not easy. Our data shows that some companies toggle up the tape-outs as part of a larger verification strategy, but that can hurt overall productivity.

How we fix verification is a broader issue. Do we lean on formal methods at the architectural level as opposed to time- and engineering-consuming test vectors?

For now, our role is to help teams quantify their design effort, properly staff their projects, and understand where they stand with respect to the industry’s best teams. From there they can make fact-based decisions to drive productivity improvements.

That’s our contribution to the broader challenges of verification and design quality, but as we all know, it takes a village (and many future industry panels) to come up with the solution.

(Jeff is Numetrics’ director of professional services and product marketing).

Bright lights in a dimly lit DesignCon room: (L-R) Camille Kokozaki, Design Rivers; Piyush Sancheti, Atrenta; Jeff Eversmann, Numetrics; Michel Tabusse, Satin IP

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

By Ron Collett

The latest venture capital investment figures are out from PricewaterhouseCoopers’ MoneyTree and the National Venture Capital Association (NVCA). They’re not pretty.

VCs spent just $17.7 billion on 2,795 deals last year. That’s down 36 percent from $27.9 billion in 2008, and it represents the lowest dollar amount and number of investments since 1997.

The chart I pulled together above, based on that data, shows the quarterly VC investment trends for semiconductor companies in just the past three years. Not an encouraging trend line. Total VC investment last year in our industry was $771 million, compared with a peak of $3.4 billion in 2000. What a difference a decade makes.

This realignment of dollars has brought about new expectations from investors and from semiconductor vendors.

Speaking to The Wall Street Journal last week, Bob Ackerman, a venture capitalist at Allegis Capital in Palo Alto, said:

We’re preoccupied by capital efficiency.

Those two words, “capital efficiency,” speak directly to the semiconductor industry’s challenge. This focus on capital efficiency is why semiconductor vendors should be increasingly preoccupied with boosting engineering productivity to get the most from their R&D budget. Lacking an internal fab for differentiation in the fabless era, companies are looking for new ways to gain competitive advantage, and they’re training their sights on their R&D organizations.

The industry’s best-in-class semiconductor IDMs in fact have jumped on this imperative, especially as many of them have shed the last of their owned fabs and now need to compete with fabless companies.

But it works the other way too: Long-time fabless players suddenly find big new competitors that have shed their fabs. They too are looking to boost product-development productivity to stay one step ahead of their new competition.

It’s clear the days of big-time investment are a thing of the past. Today, good companies are those with innovative product ideas; great companies are those that also drive highly productive R&D organizations to get those products completed on predictable schedules and to market ahead of the competition to realize higher returns.

Related posts:

1. End of the Free Ride According to Pagemill Partners, a well-known Silicon Valley venture capital...

Related posts brought to you by Yet Another Related Posts Plugin.

(Summary: As the recession’s pain recedes, semiconductor companies have an excellent opportunity to take advantage of the economic crisis to drive productivity improvements throughout their R&D organization.)

The line “never let a serious crisis go to waste” was made famous a year ago by White House chief of Staff Rahm Emanuel, who was speaking to business leaders. For the semiconductor industry emerging from a sharp recession, now is the time to capitalize on the motivation implicit in Emanuel’s quotation.

Consider, first off, the proven benefits that companies get when they take advantage of a recession. A Bain & Company study found that:

• Twice as many companies move from laggards to leaders during a downturn than they do during good times.
• The majority of those companies that take steps to make that move sustained their gains long after business came back.

For those that don’t, the numbers are discouraging:

• One-third of banks and two-fifths of big American industrial companies fell from the first quartile of their industries in the recession of 2001-02, according to a McKinsey study referenced in The Economist.

There’s plenty of advice for companies willing to take advantage of a business slump. Dave Jones and Pierre Loewe, writing on ChiefExecutive.net, advise managers to re-assess “unarticulated” customer needs and redraw their industry ecosystems.

I’d amplify another of their key points: buttress your core competency. Today’s semiconductor industry is a different place than it was before the recession. The search for differentiation in core competencies needs to be focused at product development. This is crucial for fabless companies that don’t have their own manufacturing to create differentiation. But it’s also important for formerly “fabbed” companies making the transition to fabless.

Out with the old?

Some semiconductor companies emerging from this recession will be tempted to apply old templates to new designs. With understandable caution about hiring more engineers in the short-term, the tendency will be to do more with less—to demand more products faster with fewer engineers.

What will happen?

Unrealistic schedules and budget overshoot, for one thing. For another, the urge to crank out more products to take advantage of resuscitated demand will lead to portfolio-management problems.

It doesn’t have to be this way. Productivity improvements and best practices are commonplace in manufacturing; there’s no reason they can’t be employed in R&D. It would be a shame to waste a golden opportunity to exploit this moment in history, and, to finish Emanuel’s quotation, to take the “opportunity to do things you think you could not do before.”

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.