Issue link: https://iconnect007.uberflip.com/i/1369942
MAY 2021 I DESIGN007 MAGAZINE 49 regarding the product's power dissipation: "If you need to ask these questions, then you don't know what you are doing." is statement was made as a manner of posturing himself as the lead and to discourage others from question- ing him. I spoke up and indicated these power dis- sipation questions were directly related to the standard size envelope the product could fit into. ese questions were ignored, and the product was designed to fit in the smallest form factor possible. In the end, the product design failed because of several fatal flaws: e product's peak power dissipation exceeded its size envelope, and there was no room in the customer's application for the product to increase in size. e worst-case outcome had occurred, the design was not viable, and thus had an earned value of zero. You get zero points for optimizing your design time if your design fails. Work hard to behave in a manner that is generally respectful to others around you, because it helps foster productive communication and cooperation in your design team. I understand this can be extremely difficult at times, but I also believe that the rewards of being a more effective team outweigh any short-term euphoria from telling someone off, stonewalling, or self-posturing. Understand the Requirements Crucially, we have influence in the design process over the requirements upon which we base our designs. It is important not to gloss over this step in the process to work on implementation. A well written requirement is something that is needed, can be verified, and is reasonably attainable. A requirement should only be issued based on items like customer needs, marketing analysis, regulatory require- ments, and internal/derived needs. Requirements really need to be verifiable. How do you demonstrate to a customer or regulatory entity that you meet a requirement if you cannot verify it? A requirement is also no good if you cannot make it happen within the constraints of the project. Can you imple- ment the design requirement within schedule? Is the requirement technically infeasible or made of unobtanium? Well-written require- ments reduce assumptions made by design- ers and consequently reduce project risk. As I've heard many times from seasoned systems engineers, "An ounce of good requirements is worth a pound of re-design." Design reviews are another area in which our designs can be helped or hindered. First and foremost, take your design reviews seri- ously and do not turn them into a rubber stamp approval session. You should have a panel of appropriately selected stakeholders present based on the level and type of review. Review topics should show how the design meets the requirements—or does not. Do not omit the issues/problems with your design in your reviews. is can be a great opportunity to get help from another col- league or at least demonstrate to management that you need additional resources. Also, do not let a reviewer stonewall you with disap- proval during a meeting. It is not helpful if someone disapproves of your design without giving you reasons that can be related back to the requirements, measured, or demonstrated. A successful design review should demon- strate the design meets its applicable require- ments, design changes are needed, or course corrections need to be made in terms of scope, schedule, or cost. Speak Your Managers' Language Effective communication to your design stakeholders reduces delays in resource acqui- sitions. First, do not assume that other people are specifically aware of what you are doing and what you need. For example, let's assume you need a logic analyzer to verify the timing of waveforms produced by an FPGA in your design and the scope of work needed justifies your need to purchase one. You were able to get the instrument on the approved capital expense list and filled out the purchase request