Parallels and Dichotomies of IC design and Software Development

I have noted on many occasions that the development of a software project has many parallels to the efforts of an IC design project. Both have modularized activities that must be broken down from a big picture view, the system level and architectural work if you will. Smaller tasks must be defined and architected to match up with the high level requirements. If the lower level tasks come in and do not meet the high level interface requirements rework is necessary. Collaboration is an essential ingredient in both environments.

What I do find interesting with IC design teams is that there is far less adoption of formalized program management (PM) methods than I see in the software/IT product development world. In the IC design world there is more reliance on the technical design tools as the main ingredient of a projects success in lieu of a form of PM methodology. This seems to be taking place while the semiconductor business units are making reasonable investments in formalizing PM. Does anyone else see a similar dichotomy between these two product development philosophies? Any comments as to why this me be an accepted practice in IC Design?

Taming the Feature Creep WIldfire

Any IC design project will have many changes come to the table during the term from spec closure to tapeout. How those changes are handled is what separates a project that flows smoothly from one that is riddled with unexplained diversions, surprises and delays. Teams that do not drive their business towards a formal process that includes assessment and approval of feature changes will be left to defend unexplained delays on projects with limited evidence as to why things are behind. Either design makes "feature creep" a visible process that leaves a decision paper trail behind or the design team becomes identified as a team that displays poor design execution. It's that simple.

Read more about Taming the Feature Creep Wildfire

If that article was of interest you can sign-up for our monthly newsletter here to get similar articles related to driving excellence in IC design Team execution. See our Past Newsletters.

Online Collaboration Tools

There are a number of online collaboration tools out there today and I am curious if anyone has used them in IC design projects. If you have been using collaborative tools I would like to hear what you used, how you used it and how it improved your projects. Below is my list of web based collaboration tools that I am aware of.

http://www.basecamphq.com/
http://www.near-time.net/
http://huddle.net/
http://www.jointcontact.com/
http://www.mindquarry.com/
http://www.xplanner.org/
http://www.mindmeister.com/

Six Simple Rules of Managing IC Design

Here are six simple rules to consider when managing IC design projects:

1. Commit only after doing your homework. Be creative, be aggressive, keep your vision broad and commit only when you have a means to get there.
2. Keep a keen eye out for the unknown. It is always there, waiting to disrupt your plan.
3. Are things progressing as planned, or is a correction to the plan and/or deliverables in order?
4. Verbalized plans, instructions and decisions should never be considered communicating. Write it down to keep it crisp, concise, thorough and communicated.
5. Leave no room for ambiguity or interpretation in your requirements for success. Say what you need.
6. Due diligence on plans and schedules will reinforce predictability for your design project.

If you want to learn more about managing IC design teams check out the PDF download for a "Managing Excellence in Design Team Execution" seminar.