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.
Absolutely spot on Ron, I am sure every one of two engineers agree to this cause.
The problem is not just the PMs but goes all the way to the unlrealistic expectation set by the customer by his/her choices. I have seen people change their cell phones every 6 months for the next shiny gadget. The word Q takes a beating and as long as the world doesn't care much then it's alright, I guess.
And of course enviably not everyone can be Apple in that they want to do next.
A lot good points made based on experience and insight.
Is the conclusion;
"All major projects or programs, authorized by upper management, were based on ignorance or deception. Because. if upper management really new or understood the actual costs upfront, no major project or program would ever get started in the first place."
The lack of project predictability seems to cut across industries. i.e Calif high speed rail, Oakland Bay bridge, a room addition for a house, ... All unexpected costs.
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...
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.
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?
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!
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 .
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.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.