Skedsheet Blog

Where we talk about the product, calendars, organization, and business

How not to schedule semiconductor chip development

leave a comment »


In my previous life, I worked as a chip designer.  Building chips (ASICs in my case – application specific integrated circuits) is a lot like writing software, but much less forgiving – each time you want to write new code (the chip) it costs a million dollars, and if you make a critical mistake you lose it all.

In that business, the people who succeed are the ones who can plot out all of the critical milestones, anticipate the possible problems, make a schedule that’s realistic so that employees are motivated.  Oh yeah, and as you do it you’re constantly fighting the urge to change direction, add features, and fight the competition.

And that doesn’t even guarantee that you’re building the right thing.  Because building a new chip from scratch takes a year or more and technology changes so quickly (Moore’s Law) making a new integrated circuit is an incredibly risky venture.  It’s always tense, but the worst I’ve seen went something like this…

  1. Write a functional specification of the design.
  2. Ask engineers and project lead to estimate development schedules based on the spec.
  3. Double the estimate + add 10% to make sure that it’s reasonable.  The engineers already did this, but they were probably optimistic.
  4. Draw out a detailed plan, showing critical paths, staffing, and milestones.  Microsoft project works pretty well.
  5. Attend a business/product meeting to review, get staff and funding.
  6. Get extra features added to specification, and remove 50% of time allocated to project.
  7. Re-iterate that you can’t cut corners on development or testing without huge consequences.
  8. Start project with new, unrealistic schedule.
  9. Get a special bonus pool to as an incentive for employees to meet unachievable milestones.
  10. Have your staff to work to the point that several burn out and quit, putting development further behind.
  11. Hire junior engineers to replace headcount quickly.
  12. Have your project lead quit.  Find another who can be bullied into releasing untested designs.
  13. Wait a month for prototypes while testing finds critical mistakes that can’t be fixed in firmware.
  14. Start working another revision of the design.  Spend more time on testing, but not quite enough.
  15. Release 2nd design.
  16. Wait again…uncover many minor bugs that can be fixed with firmware, and some that can’t.
  17. 3rd design.
  18. Yay, it works!  Only over budget by 200% and 1 month later than original schedule by engineers.

Even with the best technology available, scheduling and planning depend on making good choices, having managers who understand what’s going on, and giving authority to the same people who have responsibility for the consequences.


Written by Harry Hollander

February 25, 2009 at 6:41 am

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: