"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?
Ronald Collett is president and CEO of Numetrics, which provides fact-based project planning and benchmarking software that improves IC development productivity and schedule predictability.
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).
Instead of a ratio it can be defined more as a percentile . The formula will be :Productivity=
(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.
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.
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).
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
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.
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 ?
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.