Complete Survey and Get a Chance to Win 5 Hours of Virtual Design Manager

Completion of this survey will allow your entry into a drawing to receive free 5 hours of our Virtual Design Manager Service. The information you provide will help us better position our services to meet the needs of New Product Development teams. Please respond by the end of 2007 to be entered into the drawing. Be sure to follow the instructions at the end of the survey to enter the drawing!

Off to the Survey

The Essence of Collaborative Teams

Let's begin with a definition for collaboration. Taken right out of the dictionary the word collaborate means "to work with another person or group in order to achieve something". It's a simple explanation and looks suspiciously like the definition of a team that is working towards a common goal. Something we are doing every day, assuming we are clear about the common goal(s).

It's a matter of degree in the success of collaboration that is more of interest. Collaboration appears to be much more utilized in reference to development teams spread out across the globe. I find it interesting that collaboration and multiple physical location design teams have equivalent meaning. Don't we collaborate over cubicle walls? I contend that the very same requirements for collaboration exist for teams in the same building as those that are 10 time zones apart. We tend to deceive ourselves that we will collaborate to a higher degree if a team shares the same space. The hypothesis is better collaboration through collocation.

Do you believe collaboration can only be improved by collocating the team? A positive response tends to indicate a trust in an osmosis type process to convey project information, requirements, deliverable expectations and plans among the team members. To clarify further, an assumption that collocation would be a fix confirms that the team is lacking in skills to formally communicate expectations and requirements of each other. Team member discussion as noted on the slide to left exemplifies collaborative inefficiencies. Team meetings that are peppered with conversations such as these should send up a warning flag that there are communication challenges impacting the teams ability to effectively collaborate.

Hint: Collaboration and communication are one in the same. You can't do one without the other. Registering a high reading on the collaboration meter means a high read on the communications meter. If verbal, one on one, on the fly communication is the dominant mode of operation, I would expect a failing grade in the area of collaboration. Focus on formal, crisp, clear and concise visual communication and collaboration will be a breeze. Given that the meaning of collaboration is "to work with another person or group in order to achieve something" it makes sense that everyone must have the proper forum/environment to participate in the definition of "achieving something" and defining what it takes to get there.

Roadmap to Superior Design Execution

Design Process Improvement Overview
Both the Business Process Improvement and the Business Process Reengineering tend to focus on the business and it's interfaces into the other sub-processes, rarely getting into much detail on the design team processes and their interfaces. For significant improvements to be identified and realized within design, a focused effort must be completed specifically for product design that includes the interfaces into and out of product design.

There are two phases to design process improvements. The first is the assessment phase to learn, discover, understand and align the team to the current process. The second phase activities are to identify required process changes to meet the end objectives, as defined during the assessment phase. Depending on the magnitude of objectives the process is either targeting incremental improvements or a full reengineering effort, which clears the slate and starts from scratch. The diagram below represents the flow for both phases of design process renewal. Design Process Improvement (DPI) provides incremental improvements while Design Process Reengineering (DPR) is a major overhaul of how the design team operates.

To read full article follow this link.

Finding what we Don't Know

I came across the following phrase years ago and it always stuck with me as being the core concept in an organization that is focused on continuous improvement. "Those that know, know they know. Those that don't know, don't know they don't know." In essence, if we are not looking then we are assuming that we already understand where the challenges are in our product design process. If we are not on a vigilant and unending quest to find what we don't know, then we are headed for stagnation in improvements to our project execution.

For your reference here's a link to a service that is the beginning of finding what is unknown.

Is your Design Process as Good as it Gets?

In many organizations a team is aware of some problems in execution, however they are not deemed a significant disruption and there is a sense that the issues are at an acceptable level. When this is the attitude of the team I would not expect much in the way of improvements. The team has essentially stagnated in their productivity and has become comfortable with the status quo. Reasons for accepting current status range from not having time to elicit change to not having the motivation to improve.

I am aware of one highly successful semiconductor company that makes project kickoff a point of process renewal for each and every project. The team gets trained together, renews their process and best practices together, maps out their plans together and only then do they start the project. This is an excellent exhibit of continuous improvement in action. That organization knows that they do not know what they need to know and believes there is always improvements to be found. It's the culture.

There are three possibilities for your organizations position on the continuous improvement spectrum. Either you are OK with your project execution flow as it is today, you would like to see improvements in specific areas or you believe there are improvements to be found that include known issues and as well as challenge areas you may not be aware of. Where you fall on that continuum will directly impact the emphasis placed on improving.

A belief that it's as good as it gets or that you know everything you need to know about your process breeds a plateau in productivity and very limited improvements should be expected. Try shaking things up and continuously look for what you don't know and you can expect an environment of constant, incremental improvements. Excellence will be the product of an unremitting focus on improvement. Are you wishing for improvements or planning and taking action for improvements?

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.

The Basics of Design Delays

Why does a project end up late? In my experience it comes down to the possibilities outlined below. In reality there is evidence of a touch of all of these on just about any project. Some projects weigh in heavier on some than others.

• Uncontrolled scope expansion (feature creep).
• Ineffective task planning detail.
  
• Disconnects between task deliverable and receivable expectations.
• Undefined or under-defined tasks or information requirements.
• Lack of effective risk mitigation strategies.

Any project delay I have seen can be attributed to one or more of these project deficiencies. Do you believe that it is this simple? This is all stuff that can be easily minimized. Why isn't it being done? Not enough time. I here this all the time and it amazes me how frequently this reason is used. There is always time to do it again but there is never time to do it right. Are you ready to take a stand for the right way to do design? I would like to here if you have been successful in doing this and the project results you have achieved by doing so.

Schedule vs. Quality

Many times through the life of a project we are forced to make a decision where we cut corners and add risk to quality or stand firm and say "It's just going to be later than we wanted". These decision are never easy and the pressures to take the fast route are usually pretty intense. When I am faced with a decision such as this it is important for me to step back and scope it from a time to production standpoint, not from a time to tapeout position.

Making a decision based on a near term milestone, such as tapeout can be very deceiving. If the decision to trim a step in the interest of meeting a tapeout adds significant risk to the ability of sampling first silicon, you are really deciding on the possibility of adding another spin in the time to production. This can easily add 2-3 months to the production schedule.

How do you handle these schedule vs. quality decisions and has has it worked or failed for you?

The Role of Documentation in Design

I find the role of documentation to be a critical step in the product design cycle. It should be integrated throughout the entire design process to guide the team from early concept trade-offs through silicon validation. It is not "extra work" but part of a crisp planning and execution path to keep the team aligned on expectations.

How do you view the role and benefits of documentation for your design projects? What types of documentation have helped your success?

The Elephant in the Room: Negative Perceptions

The first step towards managing team member perceptions is to get them out in the open to where they can be seen. Thanks to one of my readers for making the cartoon at the left available to me. Obviously, the designer in this cartoon feels totally unsupported by management. Is this situation real or only a perception? The reality is that it doesn’t matter because perceptions are an individual’s reality. Ignore their realities and you have no chance of improving the dynamics of your team.

Finding the negative perceptions is not that difficult, you just need to be listening and paying attention to what’s going on around you. Team members will typically complain about others, talk about “them” and in many cases display a competitive nature with other members. Warning signs such as these must be managed to some level of resolution or your team will be riddled with pessimism about openly working with each other.

Many organizations choose to write off the negative perceptions within the team as a fact of doing business. From my perspective this is a choice to maintain the status quo on project execution. No amount of pressure on the team, financial incentives or sacrificial employee terminations will overcome well-ingrained negative perceptions. The negativity must be minimized and it is management’s duty to do so.

How does your organization relate to the cartoon above? Are you thinking that the design team is a bunch of slackers that must be whipped into a higher level of productivity? Or do you see yourself as part of the problem for not facilitating what is needed for the team’s success? If you have been unsuccessful in improving design productivity and predictability to your satisfaction, it may well be time for a radically different approach by looking at mitigating unchecked negativity.