Six Obstacles to Design Team Victory
|
|
Freedom from
Project Surprises Newsletter - Issue #34
|
February 2008 |
|
|
|
|
As
a team aren't we always giving projects our best shot,
with the best information and practices we know at the current time? I
have
never observed a team that is not giving it their best, most displaying
a great passion in completing projects. So why are some teams
more productive than others? Why are some design teams achieving their
commitments to the business and others are not? The answer to that
question is found in the practices of the team. There's no magic or
luck here, it
just comes down to how the team approaches a project.
This newsletter is dedicated to all those teams
that are consistently burning the midnight oil and still coming up
short on
production delivery to the business. Teams where passion for success
did not
produce the victory their efforts so richly deserved.
Jeff Jorvig, NPD Process Consultant
|
|
JCI News
- We
are now servicing the IT and Electronics industries in addition to the
semiconductor industry. Watch for some great information on managing
software projects that is directly applicable to IC design!
- Check out our quick
start
product instant downloads.
- Looking for a quick read on your development roadblocks? Check out
our Quick Discovery Survey.
- Note 17% savings coupon below for our flagship
workshop titled "Managing Excellence in Design Team Execution".
|
Design Team Best Same Practices
Design team practices are the "how" of a team's path to production
release of a product; key emphasis on production
release.
Creating product samples has never been a cash machine for the business
that a design team supports. A project objective must always be
revenue; as a result our vision must always be on production release
along with costs that meet the business case. Focus on anything less
and any decisions, plans, scope or product requirements will be
crippled from the beginning; culminating in an unplanned spin costing
several months and lost revenue, just when production was within reach.
OK,
off my soap box now and back to practices. Practices are typically
called Best Practices because we want the "how" to be our absolute
best. Of far more importance than being "best" is that they are the
same. Everyone on the team does the same things, delivers the same
items in the same format, captures the design the same way, uses the
same verification strategies and so on. If the "same practices" are
done well, no work will ever need to be redone. That's the litmus test
for your practices. If the team is being surprised and reworking
deliverables for a given project, they were not doing things the same.
The degree of surprises is an excellent measurement of the quality and
communication of your practices.
 So
what needs to be done the same? I guarantee most of the practices
problems will be related to the specific deliverable out of a task. If
there is a surprise on a project it is because a given task deliverable
was not in sync with downstream expectations. The concept of Same
Practices means alignment of all of the project deliverables to a
consistent and agreed format, content and location. For a list of some
common practices note the visual to the right.
If everyone is to
deliver to a common practice the team needs to know what they are and
they must have participated in the practices development or you have
failed at the starting gate. Think Knowledge Management (KM) as the
means for aligning your team to Same Practices. There is a plethora of
suppliers out there that can make this easy for you. Wiki's, web
collaboration tools, web project management tools and so on. If you
want a list of suppliers send me an email and I will send you the links
I have. One interesting point about surprises is that you may never
know they happened. The engineers generally just take what they get and
make it right while quietly slipping behind on their task. Implement
Same Practices or endure a continuing rash of surprises that will
quietly steal away the timeline to product revenue. |
Six
Obstacles to Design Team Victory
Here's
my list of items that are sure to ruin a victory for a design teams
project, even with a harrowing effort by the team. These are the
biggies and if you conquer them, your team is sure to enjoy repeat
project victories.
- Lack of Best
(Same)
Practices - Enough said on this subject from the previous
section.
- Lack of Scope
Control -
Things change and they always will. The big question is "are you in
control of when something is changing or even if something might be
changing?" Keep a watchful eye on your internal team also. Things come
up on a project and are declared a no-brainer thus grandfathered in
with minimal fanfare, if any at all. I have yet to see a no-brainer
change that does not end up causing some problem downstream due to lack
of proper assessment and communication. On a project, a change is never
free!
- Lack of
Requirements Closure Management -
Requirements closure can take longer than the design project itself and
I have seen this happen more than once! Project execution may get
kicked off early due to a sense of urgency, allowing the team to go
down a dead end, return and then go down another path or two wasting
precious time. If you want that project in the shortest amount of time
you need an early focus on the requirements, not on getting your
designers busy. Capturing schematics, doing layout and running
simulations feels like progress but it's only real progress if it is
not redone later.
- Lack of Design
Breakdown Requirements -
The chip level requirements must be broken down into engineering
requirements at the sub-block level. The design is a system that must
formally spawn the lower level block requirements. Lower level
engineering requirements include electricals, functional, verification
and test plans/modes. Design Guides work well as
the engineering information containers for the lower level requirements
breakdown.
- Lack of a Plan
-
Statements such as "it will take us about 6 months", or "we need it in
6 months" do not constitute a plan and it will never work for you. Plan
out how you will get there, what are the risks and their mitigation
strategies, what each of the tasks are and who is going to do what.
Follow this by identifying the task lengths and build up the plan in a
project plan tool (see our Plan template).
Once you have it in the planning tool you can then do what-if tradeoffs
to see how resources or de-featuring can improve things. Do your
homework and then commit to the plan only when there is a means to get
there. This becomes the Plan of Record for the project. Change anything
about requirements or resources and the plan must be updated. Remember,
nothing is ever free.
- Lack of Full
NPD Team Participation -
CAD, TE, PE, packaging, customer, PM, Biz Ops, Marketing are all part
of the New Product Development team and must be assigned at project
kickoff. Don't pull in your product and test people a month before
tapeout; engage them at the project start for their input on design
requirements for test and production worthiness. Leave them out and you
are likely to have a silicon spin purely to support production issues;
again several months delay and lost revenue that did not need to
happen! Include a program manager that knows design and can manage the
design related details and ask the tough questions; the ones that pull
the design team into the planning process. Include CAD resources as
part of the project. If you have holes in your tool flow you must plan
the fixes as part of the project and track them just like any other
project task.
|
How we can Help
There are several areas where we can help with
"same Practices" or remove the six obstacles to your teams victory:
- Develop an online presence for your "same
practices".
- Work with your team in defining and reaching
agreement for your teams "same practices".
- Discovery and solution of the obstacles that
are preventing victories for your team.
- Direct and build the plan for one of your key
projects that must score a victory.
|
|
Feedback
To increase the value of this newsletter it is important that
I hear from you.
- What do you like or not like about this
newsletter?
- What subjects would you like to see covered in
the future?
- How is the format?
Please email me here with any questions,
comments or suggestions that will help me better serve my readers.
|
|
|
