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.
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.
• 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.
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.
About the author:
Ron Collett is founder and CEO of Numetrics Management Systems, Inc. (Cupertino, Calif.), which provides semiconductor and embedded systems companies with fact-based product-development planning software that lays the foundation for improved productivity.
Numetrics' fact-based planning solution can be applied to one project or numerous projects. The solution is independent of the number of projects. Likewise, it is being applied at both large and small companies across the industry. It solves the problem you identify by providing a reliable calculation of the complexity of the design -- which is expressed as the amount of effort the average team in the industry would spend on the project. If you expect that your team is going to be more productive (because they are "of the highest breed" as you say) then you can increase the input productivity and get an estimate based on that productivity assumption. You can also run a full range of alternative scenarios, trading off: anticipated productivity level vs. staffing available vs. schedule constraints vs. features/functionality.
Fact-based planning attacks that problem by getting an accurate estimate of the design complexity -- based on an industry index, which is a calculation of the amount of effort the average team in the industry would spend on that project given the schedule imposed. From there, the engineering manager can run alternative scenarios based on different estimates of anticipated team productivity. This gives a reliable estimate of best case, worst case, nominal, etc.
Great point. It's the "usual suspects" that cause schedule slip. Fundamentally, the reason is because there is a mismatch between the expected amount of effort that a design project will require and the complexity of the design itself. Getting a fact-based, quantitative estimate of the design's complexity and the anticipated productivity of the team enables reliable estimates. Better methodologies enable one to increase the estimate of productivity. Thanks for the comment.
Apologies for the delay in replying. The short answer to your question of how Numetrics help with the accuracy of the underlying estimates is that our estimation engines, which underpin our fact-base planning tools, are calibrated with a tremendous amount of industry data. This data enables us to build highly accurate models. The estimation engines have been applied somwhere around a thousand IC projects from dozens of semiconductor R&D organizations. For a lot more detail, please check out our web site: www.numetrics.com
From what it appears, fact-based planning tool from Numetrics focuses on a setup where dozens of projects run in parallel and have to be resourced adequately in order to reduce the possibility of a ripple crash effect. In my view, the product appears suitable for an extra-large corporate R&D team. However, much more prevalent and pressing problem industry-wide, as I observe, exists in planning and resourcing the R&D projects in the smallest of companies.
The start-ups creating their first product and the smallest of R&D teams in the growth markets appear never to complete projects in time and within budget. They operate on the absolute cutting edge technologies. Their projects are mainly first-timers. Their tools, not yet mature. Their engineers, generally are of the highest breed. And, their projects appear to fail miserably more often than not. This is a prevalent problem which has caused many a brilliant idea go down the flush-basin.
Digging into many failed start-ups in recent times, one can not help but notice many market launches undermined by the project scheduling and estimation mishaps. Semiconductor start-ups missing the tape-out deadlines by several months are not uncommon. With venture-capitalists increasingly making their due diligence procedures more and more strict, a method to schedule these small-scale yet big-impact projects in an adequate manner is needed. Can Numetrics deliver one such solution?
My experience has been that projects will be very difficult to estimate when they are in a new direction for a design team. A simple update to last years design is one thing but a design that attacks a new market or uses a new technology are very difficult to make esimates or plan for.
An example- a project I worked on took already productized designs from a large semi company and just had to 'retarget' it as IPCores. Verification was done and the designs were in products shipping in very high volume. How were we to estimate how long and what manpoer it would take to 'retarget'? We did the normal thing and spect as much time as management allowed to dig into the design, had a boatload of training fron the supplier and tried to come up with a rational schedule. We were just making a guess however since we didn't have much solid experience.
Management pressure to get something to market quickly was too strong to resist so you can guess our estimates were pushed to the 'sooner not later' side. How would fact-based planning help here?
Completely agree - it's all about the planning. What I tend to also hear in my interactions with customers is that the same 'schedule killer' issues keep popping up repeatedly. The key point here is that the same things keep happening - bad timing constraints that slip through undetected, metastability problems, power planning bugs etc. etc. These issues can only be addressed by better methodologies, which must go hand with appropriate staffing.
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.