Thursday, September 14, 2006

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.

    Wednesday, September 13, 2006

    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.