 |
 |
Getting to More Predictable Design Execution |  |
|
|||||||||||||||||||||||||||
Dear Subscriber, “Predictable design execution”. This phrase is the
foundation of an organizations successful product
release strategy. It means that things will happen
as expected on a design project. No unplanned
diversions. None! You may view this as a tall order
to fill, or even impossible. I maintain it is
entirely possible, even on a complex mixed signal
design. The only requirement is that the design team
must meet the following criteria: If you can do that successfully, you will be predictable. If you are predictable you will meet your product launch, per the plan. Jeff Jorvig
If you want to become more of a predictable design team then step back and take a thorough, broad view of every design task or activity that is being completed. You are likely to also find activities that are not being done, and should be. Apply my criteria from above. Did everyone have what they needed for every step they completed? You must dig deep into the details to be able to answer that question, without hesitation. Avoid glossing over any steps or making any assumptions about what is known. Assumptions are sure to damage the predictable nature you are striving to attain. You must embark on a quest to find what you don’t know about your design process. Think of design as a flow of information from individual to individual. There is an input and an output of information for any activity. Where are disconnects in the transfer of information from one person to another? Unpredictability is born out of bad or missing information; someone did not get the information he or she expected AND someone did not deliver the information that was needed. Once you understand this basic concept of predictability you are armed to go find what is not known. Consider information that must be delivered into design as well as information that is required to be delivered to designs partner organizations such as test, product engineering, applications, business, marketing, program management and CAD. The figure included at the beginning of this article is a good representation of the broad landscape that must be scrutinized on your quest to find what information is not known. One example of "designer to designer" information exchanged would be a schematic. It is the correct information ONLY if the person integrating it at the next level has no issues. If problems occur during integration it indicates a breakdown in information between designers. The schematic requirement information was not correctly defined and/or transferred to the designer who created the schematic. Another example of "CAD to design" information transfer would be the parasitic extraction of a design block. The information transfer is correct ONLY if the designer is successful at extracting their design, with no issues. The inability to successfully perform an extraction indicates an information breakdown between CAD and design. Design was not successful in specifying and transferring his or her requirements to CAD. A third example of "design to business" information is a die size. If designs final die size (and aspect ratio?) meets the agreed business requirements the information transfer was successful. Consider that the business may view die size as die pitch while design may view die size as data extents. Ensure you are always talking about exactly the same item, criteria included; make no assumptions. As a closing thought on this subject I want to stress that design must own and drive any activity to uncover disconnects in the design process. They will know the details of the design process, where to look and what information is required to be successful at design. Do not fall into a trap of assuming this is about program management; it is 100% design management. If you are ready to find what you do not know about your design process and migrate to a higher level of predictability, please read on.
The first step in finding what you do not know about your design process is to identify a designer to lead the discovery of the unknown. This must be someone skilled at peeling the onion back to find the root cause of any inadequate exchange of information. They must also have solid knowledge of the design flow and the tools associated with it. The design and non-design members of the product development team must view the leader as an unbiased party to ensure open discussion with the team. For this reason I strongly recommend the use of an individual that is not part of the organization where the discovery activity is to take place. The discovery of all the inefficient information exchanges in your design process will not happen without homework on the part of the leader. If the leader assumes that all the information disconnects are generally known, they have lost the battle before it has begun and I suggest you engage a different leader. The leader must carry the flag high and visibly believe in his assignment to find what is not already widely known. He or she is looking for understated disconnects that prevent the smooth flow of information through design from concept to production. The leader must contemplate the deliverables that are necessary to feed into later tasks. Consideration for information that is necessary in supporting the success of product engineering, test, systems and marketing in their part of the project is also part of the quest for the unknown. The tools at the leaders disposal include one on one
interviews as well as large group brainstorming
sessions. Keenly focused detective work is necessary
to ferret out subtle areas where bad or missing
information is disrupting the task to task flow.
Several key questions the leader should keep ready
for discussion include the following: Make use of these questions as you talk with people about the work that they perform on projects. Listen carefully to how they answer and pay close attention to what they do not say. There are significant nuggets of information to be found in what is not said. If you have any questions about how to best manage a discovery of the unknown for your organization please contact me.
If you have any specific design process questions that you would like an opinion on (my opinion) please email them to me and I will address it here. I will maintain your anonymity, unless you indicate otherwise. Go ahead and throw me to the wolves - give me something that you have been struggling with for a while. Also, please let me know of any general design process topics that you would like to see covered in future newsletters.
|
|||||||||||||||||||||||||||
 |
 |