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

Sign in to Reply

markgrizz

1/25/2011 12:18 PM EST

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

Sign in to Reply

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

Sign in to Reply

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

Sign in to Reply

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”.

Sign in to Reply

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

Related posts:

1. The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...
2. Death of the SoC Rumors of the SoC’s impending death have been popping...
3. 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.

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.

It’s a common refrain, and I heard it this week at the IEEE VLSI Test Symposium in Santa Cruz: Moore’s Law is increasingly difficult to obey. We see evidence of this perception everywhere:

• Manufacturing costs are soaring: A fab that cost $2.5 billion to construction at 90 nm now costs $6 billion at the 22 nm node. So companies are selling off their fabs and losing what was once a huge competitive differentiation for them. Their primary differentiation is increasing their product-development capability.
• System-on-Chip (SOC) development costs run anywhere from $50 million to $100 million per project. A dwindling number of markets can support the ROI that type of investment demands.

This increasing risk has significantly cooled VC investment in our industry. In 2000, venture capitalists invested nearly $4 billion in semiconductor companies; last year, it was $771 million.

This means that to be successful in 2010 and beyond, semiconductor companies must “do Moore” with less. That requires a focus on product-development capability. How do you transform your product-development organization into a world-class team?

Here are some best practices:

• Start with an integrated framework of product-development capabilities. We, with our partners, the global operational-strategy consulting firm PRTM, counsel such a framework to improve product and cycle-time excellence. It’s remarkable how few companies have this kind of framework, but, implemented correctly, it translates into a capability to improve your overall maturity. And the more mature your product-development maturity, the faster you’ll see revenue growth.
• Optimize your R&D footprint. No one builds an SoC at a single site any more. An integrated approach to R&D management is key to taking advantage of synergies and scaling opportunities.
• Extend your enterprise: The cost of development is so high, it’s no longer possible to develop everything in house. Establishing relationships with other companies and with universities is becoming essential.

In an era of doing more with less, these best practices can help semiconductor companies “do Moore” with less, widen their competitive differentiation and increase revenues and profits.

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.

By Steven Gary

What keeps people in our industry up at night? If you joined us at the DVCon Industry Leaders panel, moderated by engineer and blogger JL Gray (Cool Verification blog), you heard at least four things:

• We’re struggling to manage the growing complexity
• New tools and IP reuse are not sufficient
• Training next-generation engineers is lacking
• Metrics are needed

Distilling all four, at least to me, yielded a single, fundamental question: How do we as an industry get more productive? Is it the right high-level language? The hot new verification methodology?

Our panel (L-R) John Goodenough, Victor Melamed, Sheela Pillia, Steven Gary, and Jim Crocker (Photo by Joe Hupcey, Cadence Design Systems)

John Goodenough, Worldwide Director Design Technology, ARM, (far left in photo) answered the question with a question:

“How many designers do I have to deploy, train and how do I build this?”

Goodenough said asking about methodology is the wrong question. Asking about workflow is the right question because that’s what affects cost and schedule.

He noted that at ARM, “We’ve stopped talking about interoperability, and we’re now talking about enablement.”

So how does the adoption of new technologies and methods affect your project? How do you figure that out? I noted that engineers are conservative by nature but must push to reach the next level.  After adopting new tools and methodologies, they need a way to quantify how that affects productivity or adds risk to their development schedules.

John said:

“You can’t fix anything you can’t measure, so you have to measure it. It’s hard to measure things; it’s hard to measure intangible things, but you have to take a crack at it.”

Once you begin to measure things, you start to start to see the true workload costs. For example, the industry generally has very high expectations that design reuse will improve productivity simply because those blocks don’t have to be designed from scratch. Yet we’ve measured that and found that below a certain level of design data reuse on an IP block (around 50 percent), the savings from reuse rapidly approach zero. At very low levels, it can cost more to reuse an ip block than to design one from scratch. (We blogged about this paradox last fall: The Design Reuse Paradox).

In the end, it was clear that design and verification today is an enormously complex challenge—from fellow panelist Sheela Pillai’s task at AMD driving complex mixed-signal IP development or Victor Melamed at Ambarella trying to help his colleagues figure out the most effective high-level design language to choose or Jim Crocker from Paradigm Works grappling with engineering training. Quantifying those challenges is the first step toward predictable project outcomes and boosting the industry’s productivity—and getting a good night’s sleep.

P.S. To read more about the panel, please check out Cadence blogger Richard Goering’s post, another interesting perspective that’s definitely worth your time.

No related posts.

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

“The complexity of what we have to deliver on exceeds our abilities as experts partly because the volume of knowledge has exceeded what training can possible provide an expert.”

By Ron Collett

That’s how Atul Gawande, author of “The Checklist Manifesto,” sets up the problem during a podcast interview with Harvard IdeaCast. Gawande is a surgeon and a staff writer for The New Yorker magazine who looks at our ability to be productive in complex situations. His interest, of course, is improving surgical outcomes.
There are, he says, 6,000 drugs and 4,000 medical procedures and increasingly specialized doctors and nurses. We’ve all read stories where surgical implements get left behind in the patient’s body.

I was fascinated by how relevant this is to semiconductor and embedded design. Teams of varying sizes are pulled together on a regular basis—digital specialists, memory specialists, analog designers, software engineers. They’re asked to build increasingly complex systems, with tighter market opportunities, and, like surgery, they find it nearly impossible to plan for the unexpected.

Process, not check marks

Gawande’s checklist approach isn’t about ticking off boxes per se. In the operating room, Gawande devised a two-minute checklist that builds in pauses during surgery to make sure that tasks have been accomplished, that blood is still on hand, and so forth. Perhaps most astonishingly, before the first incision is made, the team takes time to introduce each other by name, so everyone knows everyone else and their expertise and the goal of the operation.

He cites a study done by Geoffrey Smart, who studied decision making among venture capitalists. He compared outcomes of those VCs who, in choosing a entrepreneur, went with their gut (the “art critics”) and those who employed a checklist approach in their selection process (the “airline captains”).

Those who used the checklist approach had far fewer regrets about their selection of managers, and their investments had higher returns.

But the vast majority of VCs are “art critics,” relying on their instincts and experience, rather than the more successful approach.

In system design, many managers rely on their instincts at the beginning of product development to assess how much staff they’ll need and how long the project will take. Clearly something’s wrong because more than 80 percent of semiconductor projects slip schedule.

Learning from the past

It doesn’t have to be this way. Gawande points out that some in the investment banking community rigorously study past investments to understand where failed investments went awry. Sometimes that education leads to adding a check for their next investment checklist: “read all foot notes in the prospectus,” for example.

Successful system-design teams, whether in name or spirit, use similar approaches, and they start with benchmarking themselves against the industry or their own past efforts to understand how to approach their latest product development.

As Gawande implies, it’s often the simplest approaches—and, I’d add, approaches based on facts rather than instinct—that work most effectively.

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.

In December, we were honored to participate in a Design & Reuse panel in Grenoble, France, titled “IP Reuse vs. IP Leverage: What’s the difference and what are the issues?”

Andrea Fortunato, our European director of professional services, represented us and gave an overview of the particular challenges that design reuse brings. He blogged about it right after the panel (Design Reuse: It’s Harder Than it Looks).

Our friends at D&R have just posted an audio Webinar of that panel. It’s definitely worth a listen if you’re designing with cores and trying to take advantage of reusability.

Have you had design reuse challenges recently? If so, feel free to comment on this post to let us know what they were and how you overcame them. Improving productivity in the semiconductor industry is a communal effort!

Related posts:

1. 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.