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.

Successful Multi-Site Collaboration

When you hear the term “collaboration” in reference to IC design what comes to mind? Is it multiple physical design locations working on the same project? Or is it the ability of a design team to work well together, or maybe a combination of both? The dictionary definition of collaboration is “to work jointly with others, especially in an intellectual endeavor”.

The definition is fairly generic and says nothing about physical location(s), excellence, approach, predictability, synchronization, expected results or that the others even agree on a common strategy. However, in chip design these items are essential components of successful project collaboration. Some organizations are successful building true collaborative teams and some are not.

If you believe there is an ideal software product(s) that will make multi-site collaborative design projects a blazing success, you are missing a fundamental concept about collaboration. Successful design collaboration is about managing people. The primary emphasis must be placed on maximizing individual contribution, or your efforts will be certain to produce disappointing results. Management complexity increases greatly when the collaborative effort spans multiple countries, further amplifying the necessity of superior people management skills to bind the team as a single entity. There are two key components to a successful collaborative project; team unity and a solid, effective and broad communication strategy.


Team Unity
Team unity begins with an altering of the entire teams mind set from one of “us and them” to “we”. This is the primary hurdle and it will be the largest challenge. Without addressing this major barrier to true collaborative efforts, your projects will be filled with fault finding, limited information sharing, lack of trust and an attitude of protecting “my” knowledge. Evolving the team towards a unified front starts with a change in the way you make reference to the collaborative team. The foremost step towards team unity is by only referring to the team as “we” and the avoidance of singling out a team subset by functional or physical boundaries. Secondly, include the broad collaborative team in any verbal or written discussions related to planning, strategies, decisions, risk mitigation, meetings or summaries. Focus on these two points and you will find that implementation is simple, change is gradual and results are profound.

Communication
In any quality collaborative team the communication dynamics are well defined and effectively utilized. A rigorous system and/or process must be in place to ensure that the entire team understands objectives, deliverable requirements and timeline expectations. If anything on the project changes, a technical obstacle comes up or requirements are modified the team must flawlessly be involved. An environment that depends on hallway discussions to manage a project will quickly diminish the effectiveness of any collaborative effort. A reliance on one on one verbal communications excludes parties that may have a vested interest in the topic. Small group discussions also fails to keep the team properly synchronized and erodes the team unity. Keeping an emphasis on information flow and sharing will provide a simple path towards genuine collaboration.