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.

Eliminating the "Status Quo" in Team Performance

We commonly all seek improved project execution, that is as long as it does not impact the way "I" do things. Let's be honest. We are selfish to a fault, have good size egos and are damn proud of our contribution to the cause, so why would we need to change? But, by the way there is something that “you” might try to do differently. It is human nature to protect how we individually do things and criticize how others perform their tasks.

If you generally agree with that last statement it should not be difficult to see why the natural operating point of a design team is to maintain the status quo while “wishing” things would be different. There is no fault or blame to be passed around; it’s just human nature for teams to settle at keeping things the same. I am not implying that change will not be possible. We must understand and address the natural team dynamics in order to move off of dead center and head in a direction where real change is not only possible, but enthusiastically embraced.

Below is a list of items that must be addressed to enable the teams migration away from the status quo in design team performance and towards a higher level of design execution.

Understanding the team dynamics (as identified above)

Improvement budget

Improvement resources

Allocation of time

Change leadership experience (Change Agent)

If management does not fully support these items at a minimum, the team will continually fail to meet improvement milestones. As a team leader, manager or stakeholder your mission must be to take charge of the above items, state your case, state your requirements, state your desired results and get them addressed or the teams performance will stay as is.

The harsh reality is that it is your choice to improve or not by first deciding if positive change is a goal or only a wish. If real quantifiable change is the goal then a detailed improvement plan and specific actions must be put in place. Without specific actions in place you are really only wishing for change by default and you can expect a continuing environment of non-productive grumbling about performance and the inability to improve.

An Unsettling Trend in Design Project Planning

When we discuss an IC design teams capabilities to execute on a given project how quickly does the conversation evolve into an EDA discussion? Everywhere we read about design bandwidth and quality the emphasis is on tools and flows. There is little doubt that EDA capabilities are a significant contributor to a team’s productivity. The risk I see is that an unrealistic dependence on EDA can allow it to be considered as a design projects fundamental reason for failure, masking the need to find root cause and implement process changes.

Where does management, or more precisely the detailed planning of design team execution fall in today’s product development organizations? The planning I am refereeing to is not only the technology type activities and decisions; it must include the organizational interfaces and deliverable expectations beyond that of pure engineering. The “what”, “where” and “how” details if you will. An unsettling trend in organizations today is that non-architectural planning aspects of a design project fall upon canned EDA flows and program management, primarily driven by the need to maximize design bandwidth for engineering activities.

The danger in this tendency is that the EDA scope does not encompass the entire design process that must be addressed and program management does not typically have the knowledge for in depth detailed design planning. A planning gap results, creating a surprise during design execution further leading to a diversion from the plan. Organizations are far less hesitant to send a design engineer off to training related to a specific tool than they are to a class dealing with design planning strategies, thus perpetuating the disparity in planning expertise within design.

If a design project fails to meet its objectives the blame can’t blindly be tossed on EDA or program management. We must face the stark reality that a failed project was not planned and managed for success. If we want design project execution to be predictable and meet the mark we must invest in the teams abilities and skills for planning and managing their projects. Every member of design must possess abilities to enable him or her to properly scope, track and deliver their contribution to the project.