 |
| Freedom
from Surprises Newsletter Managing for Excellence in IC Design Teams May, 2007 - Vol 1, Issue 3
|
| In This Issue |
| Role of Coomunication |
| Is Communication an Issue? |
| Impoving Communications |
| Quick Links |
| Hi
Jeff, |
| Welcome
to our Excellence in managing IC design teams monthly newsletter.
This
edition topic is focused on the role of design team communication and
techniques to ensure each team member is properly synchronized on their
objectives . Benefits of proper communication include improvement to
your projects predictability as well as minimizing development time.
Excellence in communication must consider management to/from the design
team, within members of the design team and to/from the remaining
product development team (product engineering, test, project
management, quality etc.). You are receiving this edition as a free sample to familiarize you with the content value of our monthly format. See the closing for a special subscription offer. |
| Role of
Team Communication |
 Communication
is
the conduit by which all expectations are conveyed. Deliverable as
well as receivable expectations must be equally balanced to support an
effective information conduit. Enhancing communications of the design
team is an area where design productivity improvements results will be
relatively simple to realize. Note the diagram to the left. Think of
design as the movement of information from one individual to the next;
each person enriches the value of the information and passes it on.
Having a solid communication strategy in place will ensure the
"successful transfer" of that essential information between individuals
on a team.It's a simple task to determine if communications is a problem for your team. Review the the conversational phrase segments below: "I Thought", "When
did", "That was not"
Didn't we", "Who was", "How come" "Who did", "Why didn't", "Why did" "Who said", "As I recall" Are your team meetings peppered with discussion that begins like this? If this is common conversation within your team, there are communications issues to be managed and your project schedule will undoubtedly have an element of unpredictability. When team exchange is strewn with comments such as this I fully expect the members to be surprised by the deliverables they receive from others; and those surprises will cost your project. Assuming communication issues like this will repair themselves will leave your team frustrated, your schedules unpredictable and your quality lacking. You must take action to resolve the interaction disconnects your team is experiencing. Please read on for tips on improving your team communications. Note: I use the term "team" to define the total product development team. This is not only designer-to-designer interaction; it includes design to test, product engineering, project management, quality and so on. |
| Does
your Team Suffer from Communication Issues? |
 If
you are not convinced that communication is a problem for your team try
this simple exercise. Go around to each designer and ask him or her
what the tapeout/fracture date is for the project they are working on.
Are you surprised at the results? This is a major milestone, probably
one of the biggest and I will assume you found that majority of the
team was not synchronized on this key expectation. If it's a team size
of 1-3 you may have passed this test. For a team size greater than 3
the odds of everyone knowing this significant milestone diminish
greatly.Next, try this test. Pick a few designers at random and ask them if they know the simulation voltage and temperature ranges they should be using. If they don't know the answer but can reference a document that has the correct answer, they will have passed, assuming that everyone identifies the same reference document. Oh yes, and that reference document can't be the engineering requirements document since that has operational values only and will not account for production & package margins i.e. design validation targets. This information was a bit more complex to answer than the tapeout date and its consequences are more toward quality than schedule. Digging a little deeper let's explore deliverables. How do the task deliverables and receivables match up? When a designer passes a design back to the design lead for chip level integration is there any rework that needs to be done to make it fit with the rest of the design? Common problem areas include signal naming issues, reference library problems, test mode implementation, simulation coverage and symbol problems to name a few. If deliverable rework is a routine part of projects it is safe to say there is a communication disconnect between task deliverables and receivables. Step back and take a simple overview at how design work flows for your projects. Are things flowing smoothly, with minimal back stepping and rework? If so, your project level communications are in good shape. If not, read on for ideas for improving your team communications. |
| Implementing
Changes
to Improve Communications |
| For
starters, relying solely on design tools for inter-team member
communication is a sure way to have communication disconnects. I have
not yet observed a design tool flow that embraces the delivery of all
the necessary information to ensure solid synchronization between each
member of the team. There must be more! Post Milestones Try posting a "few" key dates on a wall somewhere conspicuous and in a form that can be read from across the room. It can't be too busy or it's will loose it's advantage. Worst case is the full project plan; best case is the tapeout date. This is so simple yet goes along way towards aligning the team on their key deliverable to the business. Best Practices This is the team operational plan: what they will do, how they will do it and what they will deliver, in detail. Don't just write something up and say this is how we are going to work together. Write something up to kick off discussion, review it with the team, modify it and agree to it. Documentation is not the solution! Properly developing, reviewing and receiving buy-in to team operations is the solution. Documentation is the closure of the process, not the process it self. Build Schedules in a Group Setting As you go through the schedule building for the project it is important that the entire team is involved. Build a project framework and then pull the team together to discuss task timing, get task buy-in by each owner, identify all the tasks and make sure the task predecessors are correct. Schedules are the project flow, not just a bunch of dates. The team must be in sync on the flow, the tasks, the deliverables as well as the timing. Proper use of the scheduling activity will provide an essential ingredient for a predictable, smooth flowing project. Change Management And the final consideration of improved communications is the management of clarity around changes of scope on the project. The team must be absolutely crisp about the requirements of what they are to produce. When a potential change comes to the project team they must be crisply informed as to the status. I suggest a working list of all changes with an estimate of time, size impact, spec status and approval for each item. Review this list with a steering committee for the project, a management team who can formally approve/disapprove of the change. There must be no ambiguity as to the status of a requested change. |
Sincerely,
|
| Jeff Jorvig Jorvig Consulting, Inc. |