Numetrics » Project Planning

The Elephant in the Corner

Ron Collett — Tue, 31 Jan 2012 07:42:46 +0000

Why do so many IC design teams commit to development schedules they know are not possible to meet? I ask this question because it’s such a common occurrence in the semiconductor industry. (Don’t read this article if you never miss schedules.)

Schedule misses are so common as to be an epidemic. It’s as if unrealistic project plans are part of the DNA of the chip industry.

Design teams are loath to complain too much about pie-in-the-sky plans. That’s because they gain little by raising red flags, even though they end up shouldering much of the blame when projects miss schedule. Moreover, complaints are often met with resistance by some of the organization’s stakeholders. It’s just better to play along with the charade, as it increases the likelihood their project plans will get funded.

Once published, such fanciful schedules and resource plans become officially sanctioned propaganda. Just about everybody knows their nonsense, but nobody dares to talk about those big elephants sitting in the corner. At least not until it becomes apparent that the tapeout date will slip—often by months. When it becomes clear that a particular project will badly miss schedule, the organization can collectively and plausibly deny it had any clue that the schedule was unrealistic.

So who’s part of this conspiracy? The genesis is usually in the engineering organization but quickly works its way to marketing and senior management. It starts in engineering because project managers know that submitting resource plans requesting significantly more engineers than management will approve can be career-limiting. Mid-level managers don’t get promoted for saying they can “do more with more.” Yet, in order to finish projects within the time defined by marketing and customers, project managers know full well that additional resources are critical. I’ve personally seen myriad SoC projects staffed with only half the engineers they actually need to finish on time.

Does the conspiracy really start with engineering? I think not. More likely it starts with the leadership of the organization—albeit perhaps tacitly. Of course nobody could ever admit to fostering a culture of self-deception, even if unintentional. Likewise, there will never be acknowledgment, tacit or otherwise, of business strategies whose unintended consequence starves projects of resources—even though it’s obvious projects demand more engineering resources to cope with skyrocketing complexity and ever-tightening market windows. I can’t blame management for trying to keep the lid on spending—it’s business. But failure to make the hard decisions about aligning the product portfolio to match resource capacity is fair game for criticism.

Of course somewhere in this mess sits the unfortunate customer. He’s not savvy to the conspiracy—he never sees the elephant in the corner. He gets a glimpse only when it shows up sitting on his conference room table in the form of the chip vendor’s mea culpa. Of course during this meeting, the vendor parades out the usual specious suspects that caused the delay, but everyone knows what really happened: A gross mismatch between resources, design complexity and schedule constraint. The consequence of the mismatch was an assumption of development productivity that far exceeded what the design team could realistically achieve. Semiconductor companies should get their R&D houses in order, as customers are increasingly on the hunt for elephants.

Originally published: http://www.eetimes.com/electronics-blogs/pop-blog/4235164/The-elephant-in-the-corner

RichMo

1/24/2012 1:05 PM EST

I worked for a major semiconductor company for over 14 years. It seems like at least once a year I would get an urgent summons to a scheduling meeting. In order to meet the customer requirement, they had worked the schedule backwards and determined that my tapeout group would have to work over the Christmas holidays. These meetings would usually be held in June or July so I quickly learned just to say “No problem! If you get your design done on time, I will have a team working.” I never had to fulfill my commitment, because the “elephant” was alive and well!

RCollett

1/25/2012 1:49 PM EST

And who says Christmas doesn’t come in July! Thanks for the comment. Ron

zeeglen

1/24/2012 3:54 PM EST

Right you are, Ron. I remember a manager who told me outright when I said we would need more time that he had to fit the project within the time and monetary budget or it would never get approved. Schedule slip was the usual result, mostly due to unrealistically short development time dreams.

Some upper managers could not comprehend that if it takes a cow nine months to produce a calf, one cannot take nine cows and expect the calf in one month. Yes, the math works, but practical development matters rule.

RCollett

1/25/2012 1:50 PM EST

Having facts data, especially industry data, is the best way to convince skeptics. Thanks for the comment. Ron

tb1

1/24/2012 5:59 PM EST

I actually once worked for a manager who had very accurate schedules, and we actually met every schedule for board and system delivery. I still have a hard time believing it, since I had never seen this behavior before or since.

Unfortunately, the software team was managed more conventionally, and the hardware team was always driving them crazy by delivering hardware on time when they weren’t ready for it.

RCollett

1/25/2012 1:51 PM EST

Maybe that happens more in the systems domain than in semiconductor? Ron

jackOfManyTrades

1/25/2012 3:34 AM EST

When I was an IC designer, I soon learned that the best time to book a holiday (vacation) was around the tapeout date. That way, there was zero chance of the holiday coinciding with the actual tapeout.

RCollett

1/25/2012 1:52 PM EST

Too funny! Ron

any1

1/25/2012 9:30 AM EST

In my experience this deception often starts in marketing. They complain that because engineering is not doing its job fast enough the company is not competitive with its peers and so can’t get enough business to make its sales goals. So then management tells marketing that they can promise better lead times to get those orders and then tells engineering that they have to meet whatever schedule that marketing needs to get the business whether they have the resources to do so or not.

R0ckstar

1/25/2012 6:39 PM EST

That’s basically it. Schedules are generally DICTATED, not requested. A true schedule would be an exercise in impartial forecasting, guessing when some other design team of which you have no stake – will finish. but for many reasons, most of which have already been mentioned, scheduling a project that you have a personal stake in is inherently problematic. If you really want to know how long a project will take, ask the other department, or start a betting pool then watch what the odds tell you. I guarantee it will be dead on every time!

AMSURF

1/25/2012 5:22 PM EST

My favorite excuse for the unrealistic schedule is from the Sales or Marketing person who says, “if we don’t deliver it by this date we will lose the socket and be out of the product’s lifecycle!” My response, “let the race to failure begin!”

zeeglen

1/25/2012 6:45 PM EST

Yup!

Marketing: “Company X is making a fortune with this. We gotta have something similar in six months or we will miss the Market Window.”

Engineering response: “Company X has had a whole year to develop this. We need the same. Why the heck didn’t you guys ask for this six months ago?”

skal_jp

1/25/2012 7:35 PM EST

I remember an argument with my manager:
- We need to tapeout in 1 week
- Sorry, with the machine power and license number we have, I need 2 weeks for running all the backannotation simulation
- Can’t do it in 1 week?
- Nope.
- Then only run part of the sim!

Sim results? There was one pattern with a glitch. Of course in respect this Muphry’s law the glitch was on a pattern I ran after tapeout.

zeeglen

1/25/2012 9:02 PM EST

So who got blamed for not running the whole test?

never mind – I can guess

t.alex

1/26/2012 10:21 AM EST

The customer might be the source of all these in some cases.

RCollett

1/26/2012 3:14 PM EST

No doubt that customers frequently request/demand an accelerated schedule, which is natural — they’re reacting to the changing competitive forces they themselves are facing. Such requests/demands trigger a chain reaction within the chip supplier’s organization — marketing, engineering, program mgmt., senior mgmt., etc. must respond — and the common response is naturally “yes, we can do it.” That’s not surprising either. Everybody wants/needs to please their customers. However, what often happens is that difficult decisions are avoided. Instead, the organization pretends that somehow ten pounds will fit into a five-pound bag. RC

Frank Eory

1/26/2012 5:06 PM EST

In my personal experience, this situation has actually improved a lot over the years. Yes, marketing still dictates a market window that must be hit, and the scheduling works backwards from there — from end of qual, to system validation, to first prototypes, fab cycle time, tapeout, verification time, design time, and to product definition and spec writing before design even gets started.

When that back-to-front scheduling process reveals that design has a negative or unrealistically small positive number of weeks or months to do their job, then the number of choices are very few. If a re-evaluation of the lifetime revenue based on a later market entry still makes business sense, proceed with a new schedule that has the later date. If the resourcing was intentionally lean, add headcount to appropriately resource the project and/or re-define the feature set & scope if a lesser product can still satisfy a segment of the market by meeting the market window.

If none of those business tests pass, then the right answer is to kill the project and put your engineering resources on a different project where you have better odds of making money. Sales will complain that “we’re going to lose that socket,” but the reality is that you have already lost that socket before you even started the project…because you waited too long to start.

RCollett

1/26/2012 5:29 PM EST

Frank, what you describe of course is a rationale approach to a challenging situation. However, my observation — based on the Numetrics customers, which is fairly substantial — is that the situation is actually getting worse. It’s because the enormous competition in the semiconductor industry. We need look only at the industry’s M&A activity during the past few years, as well as the companies forced out of business (e.g. the latest being Trident, which recently filed for bankruptcy). The greater the competition, the greater the need for best-in-class management.

prabhakar_deosthali

1/27/2012 6:01 AM EST

The main reason why schedules are dictated and not requested is that the management thinks that the engineering is always adding a lot of cushion to the timelines to be able to work in a relaxed manner.Mnay of the engineering guys actually do it so that after the squeezing out by the management they get the REAL schedule .

RCollett

1/27/2012 12:57 PM EST

Prabhakar,

So you’re saying that in your experience the engineering organization frequently pads the schedule (timeline)?

Charlie_Edmondson

1/27/2012 3:30 PM EST

There is another side to this problem. A few years ago I was on a project (systems, in this case) where I was the chief hardware designer. My manager was an expert on schedules and budgets, a wiz at anticipating senior managements requests, and an all around good guy. Our hardware team was always on time, on budget, and had a lot of fun.

The SOFTWARE side, unfortunately, was run by a PHB who was always promising things he couldn’t deliver, was way over budget, always behind on the schedule, and continually complaining he didn’t have enough resources, money, people or time.

When the phase of the project I was working on came to a close, the company laid off the entire hardware design team, and spent the next year ‘persuading’ the hardware manager to quit. Why? Because he had OBVIOUSLY been featherbedding his budgets and schedules, and not driving his people hard enough. They promoted the software manager… again!

peinal

1/27/2012 3:34 PM EST

If you think this only occurs in semiconductor design, you’re sadly mistaken. I’ve worked designing HW and SW in military/aero, telecomm, and govt and they all have the same elephant in the room. I once refused to sign a proposal that the govt. required for the preparers. I refused because my initial conservative estimate of 10K hrs was cut to 4K hours on a project that would’ve been 3x more complex than the last one we did (which took 6K hrs). See what I mean?

zeeglen

2/1/2012 6:36 PM EST

A way around this is to multiply your conservative estimate by four times, then when the bean counters divide by four you get the time you really need.

Unfortunately the bean counters eventually catch on to this, so you must multiply your next estimate by 8, next by 16…

WKetel

1/27/2012 8:15 PM EST

My observation has been that sales or marketing will promise anything to get the order, and then engineering and production are blamed when delivery does not happen as promised. This was in the industrial equipment realm, not chip design. Once, a salesman with integrity told us that he would really like the order, but he could not make that delivery. He told us what he could make. Another company claimed no problem with the delivery date, and then wound up being several days later than the supplier that we did not go with. Worse yet, the transducers cost more and were not quite as good. Their catalog got a big red “DO NOT USE” note at that point. I seldom forget a betrayal, and I do take it personally.

Death of the SoC Rumors of the SoC’s impending death have been popping...
In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...
The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...

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

The Politics of Productivity

Ron Collett — Wed, 30 Mar 2011 22:22:25 +0000

Politics and productivity seem to go hand-in-hand in semiconductor R&D organizations. Perhaps it’s natural. No manager or project team wants the low productivity Scarlet Letter. So it’s hardly surprising that ostensibly poor performers use politics to avoid scrutiny.

But are these so-called low productivity projects really poor performers? In fact, many are not. Quite the opposite in fact—they often have high productivity (although insufficient throughput) but are mistakenly pigeonholed because their crime was a missed schedule. Moreover, schedule overrun usually is not due to low productivity.

Instead, it usually stems from an unrealistic project plan—one in which the allocated staffing is not commensurate with the chip’s design complexity, project schedule constraints, and project uncertainties such as spec stability, new mfg. process, EDA tools, etc.

In my experience, unrealistic plans trace their roots to the organization’s executive ranks. Senior management promotes a culture of over-commitment in which R&D takes on significantly more projects than it realistically can handle. The consequence is obvious and ubiquitous: most projects in the portfolio are resource-starved.

It’s an all-too-familiar story: Projects are inadequately resourced, whereupon they miss schedule, senior management thinks the culprit was low productivity, the team runs for cover. Sound familiar? Of course, executive management has no proof to support its (often unspoken but implied) “lousy team” hypothesis, but likewise the team has few facts and little data to defend itself. Who wins that battle? As the story repeats, the organization gets steeped in the art of productivity politics, including subterfuge, avoidance of scrutiny and measurement, and internecine feuds that stems from finger-pointing.

The great irony is that measuring productivity preempts much of its politics. That’s because measurement gives project managers the data they need to prove projects are woefully understaffed and is the root cause of schedule slip, not poor productivity. When managers argue cases using facts and data, they can do so persuasively, often receiving additional resources for their trouble—at least enough to give them a fighting chance to finish within tight schedule targets. They rarely get all the resources they need, forcing them to boost productivity by ten percent or even more. But they’re motivated to go the extra mile—doesn’t management want that?

Executives win when they make wise staffing decisions—they get dramatically improved on-time schedule performance. Likewise, measuring productivity ensures R&D performance improves at a competitive rate. It also yields the facts and data to ensure future projects get staffed (reasonably) properly, and this preempts or at least mitigates the politics of productivity.

Originally published at http://www.eetimes.com/electronics-blogs/other/4214604/The-politics-of-productivity

No related posts.

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

R&D Predictability: The Path to Profitability

Ron Collett — Wed, 26 Jan 2011 19:32:32 +0000

Poor schedule predictability of IC development projects is the Achilles heel of semiconductor companies. It manifests itself as high schedule slip and is among the most important R&D metrics, measuring how well project schedules reflect reality. Most don’t.

Companies traditionally view schedule slip not as a result of faulty project plans, but rather as a consequence of unforeseeable perturbations occurring during the development process. The picture is incomplete and inaccurate. Slip must also be viewed through the project planning lens, because many events labeled as unforeseeable can be fully contemplated in the project plan with proper modeling. The payoff is big—reliable plans, which is the path to profitability.

Predictability and schedule slip are two sides of the same coin. Schedule predictability measures schedule overrun by comparing a project’s original planned duration to its actual duration, expressing the difference as a percentage of the original. The original planned schedule is the first one formally defined and officially disseminated.

What qualifies as low versus high slip in the semiconductor industry? Low is 10 percent or less. High is more than 25 percent.

Poor schedule predictability is an insidious problem that eats away at a company’s competitiveness, especially when it becomes fully baked into the organization’s culture as a tolerated practice. At that point, it’s just a matter of time before the company or business line disintegrates. Today many semiconductor organizations are taking action to vanquish slip. Those ignoring it do so at their peril. I doubt they’ll be around five years from now.

Excuses abound during post mortem assessments of projects that slip schedule. Naturally, the usual culprits are speciously defended as wholly unforeseeable. They include spec changes, EDA tool and library problems, IP and software delays, personnel issues, etc. But what project doesn’t encounter some or perhaps all of these and more? It’s disingenuous to expect that any particular project will escape the stochastic nature of chip development, so therefore it must be built into the plan—without the use of schedule buffers at every turn.

I reject the notion that IC projects are predictably unpredictable. I can point to myriad organizations that have excellent predictability. These groups deploy best practices and tools that use facts and data to ensure project plans fully contemplate the stochastic nature of IC development and “unforeseeable” events.

Originally published at: http://www.eetimes.com/electronics-blogs/r-d-roi/4212477/R-D-predictability–The-path-to-profitability

Comments

Dan Patterson

1/25/2011 9:46 AM EST

Great article. CPM schedules are inherently challenging as the forecasting tool of choice for development type projects. Due to the high degree of uncertainty and iterative work/re-work, traditional CPM Gantt chart type forecasting rarely gives an accurate picture – hence the frequent perception that the project finished late – i would suggest that instead, we simply didn’t plan accurately enough. Worse, given projects teams are aware of this shortcoming, the original ‘plan on the wall’ simply becomes a static picture that doesn’t reflect the latest updates, changes and impacts due to risk. An alternate approach is to create a risk-adjusted schedule using a combination of a CPM schedule (e.g. MS Project) combined with a project’s risk register and model the impact of the latter on the former using Monte Carlo analysis. Not only does this approach give more realistic forecasts, it is also a means of getting team buy-in into the agreed upon plan. I agree with the author that these projects are indeed predictable; we simply need to do a better job of including the non-deterministic work/outcomes in the original plan/schedule. More thoughts on this at http://goo.gl/KQTuz

markgrizz

1/25/2011 12:18 PM EST

You’ve stated the obvious, this reads like an advertisement.

RCollett

1/25/2011 9:37 PM EST

@Markgrizz,

It is definitely obvious — but remarkably, a great many semiconductor organizations don’t understand it. As for an advertisement, you are again correct — it is an advertisement to think differently about schedule predictability.

Rgds,

Ron

RCollett

1/25/2011 9:56 PM EST

@new2coding,

Well stated — it is all about company culture. Politics and project planning often go hand-in-hand, because the project planning phase is when funding decisions are made. It is almost axiomatic that money begets politics. In my experience, the most effective and efficient way to cut through politics is with facts/data, which incidentally has a tremendously positive impact on culture. Once established, a fact/data-driven culture can persist for a long time, which is a key ingredient for sustaining competitive advantage.

Thanks for the comment.

Ron

Robotics Developer

1/25/2011 11:44 PM EST

An interesting article, I have worked in the semi industry for more than 15 years and never found a schedule realistic. Too often the designers presented a real schedule to the management and it was tweaked to meet some arbitrary set of deadlines. This is oftentimes the real cause of “schedule slip” it is non-realistic schedules being adopted as real. Specs do change, resources do disappear, software has issues these are not unexpected and should be accounted for but as I stated the real schedule does not meet the management’s target dates. Until that is addressed, development will always be “late”.

RCollett

1/28/2011 7:53 PM EST

Robotics Developer,

Management thrives on data — it makes decision-making so much easier, because it takes some of the risk out of the equation. Hard facts and data are therefore a powerful tool for persuading management that a project’s schedule is wholly unrealistic. The data must unequivocally show that even if the team acheived best-in-class productivity, the schedule is still not achievable because the staffing allocated to the project is not communsurate with the design’s complexity and the schedule constraint.

When presented with this, management has little choice but to reduce the scope of the project, relax the schedule constraint, add more resources and/or reblance the project portfolio (i.e. reduce the number of projects).

Thanks for the comment.

Ron

The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...
Death of the SoC Rumors of the SoC’s impending death have been popping...
The Elephant in the Corner Why do so many IC design teams commit to development...

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

Facts and Data vs Heuristics and Hope

Numetrics — Sat, 20 Nov 2010 13:01:20 +0000

During the next five years, a great many semiconductor companies will be faced with an increasing number of underperforming business units. Chances are they’ll be selling or spinning them off. Some chip companies, large and small, will disappear altogether. Why?

Persistently missed product development schedules—poor schedule predictability—is the culprit and bane of semiconductor companies. It is a pervasive problem in an industry whose R&D stakes are now excruciatingly high. Typical SoC development costs, for example, range from $50 million to $100 million (from design concept to release-to-production). With a target return of 5X to 10X and a narrow market window, a mere three-month slip can dramatically reduce revenue and profitability. No surprise.

Projects miss schedule when management underestimates or fails to acknowledge the time and resources the R&D organization needs to develop complex ICs. Absence of a reliable estimation process is the crux of the problem. Curiously, many semiconductor executives have been blind to the issue, and yet it is the key failure mechanism of their businesses because it goes to the heart of their product development engine. Go figure.

Accurately calculating design difficulty—the prerequisite to reliably estimating resources and schedules—demands quantitative methods that measure the intrinsic difficulty of designing an ICs logic, circuitry, packaging, etc. However, it must also take into account the sizable stochastic footprint of chip development.

Some executives fail to recognize the stochastic aspect of IC development has a far greater impact than ever before—a consequence of soaring development costs, inexorable competition and the limited size of each market opportunity. Resource and schedule planning therefore demands a stochastic model, which contemplates events that projects routinely encounter. Examples include spec changes, EDA tool issues, IP quality, project management, organizational issues, etc. It’s not exceptionally hard to model the development process, but it does require a good deal of industry data.

Project and program managers typically rely on experience and intuition to create project plans. Not a bad start, but the approach is light on facts and data and heavy on heuristics and hope. IC development has both a deterministic and stochastic component, and they are inextricably intertwined. Most project plans contemplate only the deterministic aspect of complexity, which is why they are flawed from the start. Not addressing the “stochastic problem” will almost certainly translate into reduced shareholder value and lost jobs.

Originally published at: http://www.eetimes.com/electronics-blogs/other/4210716/Facts-and-data-versus-heuristics-and-hope-

Comments

iniewski

11/19/2010 6:45 PM EST

Ronald, you write “Projects miss schedule when management underestimates or fails to acknowledge the time and resources the R&D organization needs to develop complex ICs” but my experience on many IC projects has been that all projects miss schedule because they are designed to do so! As one executive explained to me, “if I make a realistic schedule we will be late to market by one year, but if I shorten it unrealistically we might be only 6 months late”…has anyone worked on an IC design project that met teh deadline and was on budget??? Kris

RCollett

11/29/2010 6:54 PM EST

Kris,

My observation is that giving a team an unrealistic schedule is usually counter-productive b/c it is a demotivator. Far better is to give a team a very aggressive — but achievable — schedule. When I say “very aggressive,” I mean a schedule that assumes the development team’s prodcutivity will be best-in-class. In other words, in order to achieve the target schedule, the team must perform at or near best-in-class. The result (based on tracking this phenomenon on hundreds of projects across the industry) is that the productivity of those teams are far above norm — and the projects are are on schedule (slip is less than 10%) and come in within tolerable budget margins.

Thanks for your comment.

Rgds,

Ron

Robotics Developer

11/20/2010 9:35 PM EST

I could only dream to be on ANY project that was on time, on budget, and up to full performance. I (when I was young and naive) would give realistic schedule estimates to my boss; he would double or triple it and give it the the VP; the VP would talk with marketing and come back with a schedule that was 75 to 80% of my original one. There is always pressure to shorten the proposed schedules either by the boss or higher ups. What usually happens is the engineering staff gets hammered and is blamed for the slipping schedules. NO-ONE remembers the original schedule, its just a fact. Until companies realize that the designs will take just so much time / resources and make the appropriate trade-offs UPFRONT they are bound to lose market share or fail. I might suggest a sliding schedule analysis that provides the cost verses time to market trade-offs balancing shorter/more costly development with earlier/more profitable releases. Anyone know a company doing this?

RCollett

11/29/2010 6:44 PM EST

@Robotics Developer,

There are definitely companies making appropriate up-front tradeoffs — Intel for example. Here is an abstract of a paper presented by Intel at an industry conference held earlier this year devoted to project planning strategies:

“Effective planning for complex design projects requires understanding the tradeoffs between resources, complexity, schedule, and risk. Resource decisions are based on a particular project’s priorities, which may impact team productivity [because team size might need to be increased to hit target schedules, and increased team size will reduce productivity -- but increase throughput], and hence are important to comprehend in any systematic approach to benchmarking or planning. An empierial model for silicon design is built from available data: both from internal and external sources. This mdoel can be used to understand reslationships between team size and productivity, complexity and duration, risk and performance to schedule. Use of the model to predict organizational limits for complexity is discussed along with how key trends like reuse and modularity are unavoidable responses to current trends. This model is used throughout Intel to help make silicon design resourcing decisions . . . .”

In light of the above, perhaps it’s not surprising that Intel’s financial performance continues to be exceptionally strong.

Rgds,

Ron

iniewski

11/29/2010 7:40 PM EST

thank you Ron, agreed…pls pass the info on to executives

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

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

How Complex is Your Chip Design?

Numetrics — Thu, 11 Nov 2010 11:10:12 +0000

When planning new IC design projects, such as SoCs or complex analog or RF chips, R&D organizations that have a firm grasp on the complexity of implementing the design wield a powerful competitive advantage. Complexity is a measure of engineering difficulty and provides the foundation for reliably estimating engineering resource requirements and development cycle time for projects, which is the essence of good project planning. Can anyone disagree that consistently reliable project plans, which means projects finish on-time and within budget, translate to higher revenue and profits? But how does one get an accurate, quantitative calculation of design complexity?

One approach (that I know works) uses “industry standard effort” as the proxy for complexity. Industry standard effort is a calculation of the amount of effort the average design team in the semiconductor industry would expend on the particular design project and is based on the design’s technical specifications and characteristics. An empirically calibrated model must perform the calculation—not a theoretical model. Technical characteristics include parameters such as process technology and geometry, number of metal layers, power, circuit types such as AMS, RF, logic and memory, transistor counts, processor cores and block functions, clocking schemes and frequencies, amount of reuse, and many others. A number of top semiconductor companies use this methodology. Intel, for example, recently presented a paper entitled “Empirical Model for Organizational Dynamics” that references this approach.

Developing a reliable complexity estimation model demands extensive project data mining of the relationships between chip design parameters and the amount of engineering effort associated with implementing them. I know this firsthand, having spent over ten years working in the field. The lynchpin is having a rich database of industry projects and a mathematical model that can be readily calibrated with the industry data.

With a reliable calculation of standard effort, R&D organizations can compare the relative complexities of different designs, a very useful project planning capability. Taking it one step further, R&D managers can use the calculated complexity to determine the productivity of a finished project. It’s the ratio of Industry Standard Effort to Actual Effort Expended. Measuring the productivity on a handful of finished projects provides a baseline and starting point for reliably estimating the productivity on future projects.

Why is all this useful? In short, combining complexity and productivity modeling yields a fact-based approach to generating accurate and precise staffing requirements for IC projects, and this translates to on-time delivery and business success.

Originally published at: http://www.eetimes.com/electronics-blogs/other/4210492/How-complex-is-your-chip-design-

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.

The Ripple Effect

Ron Collett — Thu, 12 Aug 2010 15:00:23 +0000

As a senior product-development manager, you’ve no doubt seen the ripple effect: Your project is humming along and it’s time to add engineers on a crucial part of the design. But wait! The engineers you need are tied up on another project whose schedule has slipped, and they can’t be moved over to yours. What’s worse is when the manager on that project is not sure when they’ll be free.

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.

The Importance of Capital Efficiency

Numetrics — Wed, 27 Jan 2010 17:05:51 +0000

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.

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.

Design Reuse: It’s Harder Than it Looks

Numetrics — Thu, 03 Dec 2009 22:15:07 +0000

By Andrea Fortunato

How best can we leverage IP in an era of relentlessly increasing design complexity? That was the question on the table at this week’s IP-ESC 2009 conference here in Grenoble. I was honored to sit on a panel with Jasper Design Automation CEO Kathryn Kranen and Olivier Haller, who manages the design verification team in the Functional Verification Group at STMicroelectronics.

Our CEO, Ron Collett, described the IP situation in a post last week as the design reuse paradox, in that re-using IP is harder than it looks. In fact, there are dangerous consequences for any project leaders who think it’ll be a cakewalk.

During the panel this week, I made the point that most teams underestimate the complexity that the reused IP— adapting a particular block to a new context or adding particular features and then validating it—will add to their project.

This miscalculation is particularly dangerous for derivative designs, whereby the reuse level of their blocks is expected to be significantly high. Executive management loves derivative designs because they’re operating under the assumption that most of the work has already been done on the original design and the derivatives will be easier and deliver higher margin.

Truth and Consequences

But the reality is teams use ever-more IP blocks (including complete functions and sub-systems) on a chip. Underestimating the complexity at the block level is compounded at the chip level, and this creates unrealistic performance expectations from the development teams.

What happens?

• The project schedule slips

• Team members have to be pulled from other on-going projects to bring the project to closure, throwing the predictability of schedule in those other projects into doubt.

What are the consequences?

• The overall market window is reduced and peak time window for product introduction is reduced

• Development cost increases, exploding the project’s initial budget. ROI window is reduced

• Both time to market and ROI are affected!

The ripple effect of underestimating the effort needed to develop, integrate and validate the IP is far-reaching: The resource disruptions delay key projects because resources already involved on other developments are pulled in to salvage one development. The ripples turn into waves that slam the schedule and cause budget over-runs for the whole the project pipeline.

Remediation

There are two major ways to address this situation.

First, fact-based planning at the project’s outset helps avoid this turmoil. By measuring and quantifying project complexity and schedule risk, team leaders can see the gap that might result between their initial effort assumptions and the effort they’ll actually need based on the data. This helps them make fact-backed what-if staffing simulations and create aggressive—yet achievable—schedules.

Second, pick your design battles carefully. Analyzing projects in our extensive industry database, we see that best-in-class design teams show a lower amount of reuse than the average of their segment. This means that those best-in-class projects re-use IP where it is most appropriate to do so—for example in standard functions that don’t bring value add and real differentiation to the final product. But, best-in-class companies leverage their own innovation and fully engage their engineering resources in situations where the performances of specific functions are the key differentiating factors from the competition.

In the end, the key challenge for an IP user is :”Keep the ROI in the Product Development!”

(Andrea Fortunato is director of professional services for Numetrics, based in Grenoble).

The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...

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

Productivity, Predictability and other Burning Questions

Numetrics — Wed, 04 Nov 2009 21:43:39 +0000

By Alex Silbey

(Summary: We inevitably get questions about Numetrics’ technology after webinars or live event presentations, and we’d like to share some of them in the spirit of helping you understand more about our products and solutions. Here are answers to several recent questions in the virtual mail bag).

Q: How do you define productivity?

A: We calculate complexity of the project and we divide the complexity units by total number of person weeks required to get that product out to volume production. That quotient gives you the productivity number. The typical range is 500 on the low end for a large team to 3000 for a small team.

There’s another measure, which is throughput, and throughput is complexity units per week. That’s a measure of normalized cycle team. Productivity is efficiency of the team and higher number is better.

Q: I’ve heard that in some sectors productivity decreases as team size increases. Is this true in semiconductor product development?

A: It’s a universal effect across pretty much any activity that has to do with building things. When you build larger teams, each person is doing a smaller and smaller slice of the overall work. More work has to be split apart and then put back together. Bigger teams equal more meetings and more management required. It’s universal and it’s inevitable. With the Numetrics approach, you can minimize this effect—decreasing productivity curve is flatter than it would otherwise be.

Q: It’s impossible to predict in a design project how many times customer requirements will change, when your EDA tools go buggy or if a key contributor leaves the team. So how do you quantify schedule risk with so many unpredictable variables?

A: The simple answer is our tools don’t predict things. You have a draw a line between statistical analysis and a crystal ball.

What Numetrics’ tools do is take your inputs of design parameters and measure them against the history of more than 1,500 design projects over eight generations of technology evolution (here’s a link to a demo of our tools). Using the data from those hundreds and hundreds of designs, this builds in realistic effort required to deal with those issues. It’s a way of contingency planning.

Think of it like yield modeling. You know that on each wafer a certain number of dice will fall out. Yield modeling doesn’t tell you which particle is going to hit which die and where. But they give you an accurate assessment of how your design will yield. Numetrics is like a yield model for project plans. It’s saying there’s a certain probability that if you’re going to try to achieve these targets, given what you’ve input you’re going to fail.

It allows you to make a quantitative assessments. It’s a probability model. It’s not a crystal ball.

Q: How does the complexity calculation model handle predictions for newer nodes, such as 45 and 32nm?

A: Numetrics’ IC Industry Database has collected information for eight technology generations. The technology shifts from one generation to another have been observed before. And what we’ve observed is that early users of technology nodes face considerably more complexity than later users of the same node, once the models and such are more stable. The equation has calibrated this effect which repeats from generation to generation. We’ve been able to model what the effect of the extra technology of a new node will be on a new design.

Q: Can your tools get data from existing sources or do I have to input it manually?

A: We’re dealing with milestones, staffing information and complexity information. Typically this information is copy-pasted from existing sources or customers are using XML import to get data into our tools.

(Alex is Numetrics’ director of professional services).

The Politics of Productivity Politics and productivity seem to go hand-in-hand in semiconductor...

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

Why Most Semiconductor Design Projects Slip Schedule

Numetrics — Mon, 19 Oct 2009 19:45:39 +0000

(Summary: More than 80 percent of semiconductor projects slip schedule, but we can change this costly reality by introducing a fact-based planning methodology into semiconductor product-development organizations).

By Ron Collett

The increase in semiconductor design complexity never slows. This reality always reinforces itself when I look at the agenda of a given week’s technology event. This week’s headliner is ARM Techcon3 in Santa Clara.

Here’s a sampling of the presentations:

“How Software and Hardware Can Cooperate To Manage Power Consumption in ARM-based Systems”
“Fireside Chat: Enabling Internet Eveywhere and Advancing Next-Generation Designs”
“Energy Efficient Design at 65nm – What Really Works!”

And the list goes on—challenging design issues at complex technology nodes everywhere you look. It’s little wonder then that most semiconductor design projects slip schedule (see chart).

Old habits in a mature industry die hard. Engineers have built products in more or less the same way for 40 years, and they’ve had tremendous market success. So why change? Engineering intuition always seems to work, and a bottom-up approach to project staffing is the way we’ve always done things. No reason to change, right?

Wrong.

Projects slip for a number of reasons:

We’re human. Who can predict when or if a spec change might occur or the flu takes out a few key engineers for a week?
We often lack the context to make fact-based decisions for dizzingly complex designs. For example, if you’ve spread a design over three locations in different time zones, using a newly-acquired team designing to a new process, you’re trying to extrapolate the effect of those factors based on your experience. But you probably have never experienced those factors before because each design is different.
Projects are late often because they are under-scoped. The schedule for the new project is based largely on the post-mortem of the last project, with the conclusion that none of the things that went wrong last time will be allowed to go wrong this time (and no other major new challenges will be allowed to creep in!).

Typical bottom-up reactions to managing such complexity tend to fall into two categories:

Boost staff to hit schedule. This generally creates either a low-productivity, low-throughput situation or a high-throughput, low-productivity environment. Teams might hit schedule but will blow out the budget.
Leverage a small, skilled team of engineers and drive it hard. This can marshal costs and improve decision-making, but a small team can produce only so much in a given period of time, even if it’s highly productive. Too much pressure to hit an unrealistic schedule also kills morale.

Sharp engineering managers can achieve best in class and cut or eliminate schedule slip by adopting a top-down approach that complements their traditional bottom-up planning. The top-down methodology uses:

Quantified estimates of the chip’s complexity
The team’s productivity
A model of the rate at which effort will be expended on the project.

With the proper infrastructure in place, schedule estimates can be generated within just a few hours. At this point you can benchmark against your own experience or against the industry’s experience and make fact-based what-if tradeoffs to boost your schedule predictability and design ROI.

More than 80 percent of semiconductor projects slip schedule. But we can change this reality. You wouldn’t expect this from your foundry, would you? Your foundry partner gives you a precise estimate of yield on your chip based on its models and its vast experiences with similar projects. You should expect the same predictability from your product-development organization.

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.