Introduction

This paper is primarily intended for students who are facing their first design review, but the scope extends to engineers on the job. The secret to avoid being intimidated is to both understand the design review process and to be prepared. If you heed the advice in this paper, your first review should go well and you have the opportunity to make a favorable impression on those who sit in judgment of you. Failing to heed the advice will result in one of the more humbling experiences you have had.

The primary purpose of a design review is risk reduction. Mistakes or the potential for mistakes represent a risk that is avoidable. It is in everyone's interest for a project to succeed. It is human nature to make mistakes or to have misunderstandings. A properly conducted design review becomes a superhuman instrument that can detect individual human errors before they become problems. The mistakes you make that are caught by the design review process are generally not remembered by anyone after a very short time. The mistakes you make that result in a catastrophic failure of some system are remembered and laughed at by everyone for a lifetime or longer by the generations that follow. A secret to success is to learn how to use design reviews to your advantage.

In my twenty plus years as an engineer I have been involved with a number of design reviews as presenter and as invited panelist. In most cases, design reviews are very cordial affairs and everybody is on the same team. However, when there are competing interests or politics involved then it is especially important to be fully prepared because there may be an adversary not of you personally but of your company or other people who has an interest in your presentation going badly. Rather than make an obvious attack, the adversary will conspire to take advantage of any weakness and ask seemingly simple but embarrassing questions. Here is where experience on your feet pays off.

Mental Preparation for your first Design Review

Your first attempt at anything is naturally going to reveal your inexperience. Do not let that bother you - it is a normal process we all go through - even the instructors who sit in judgment of you. The starting point for experience is always inexperience. Accept yourself as-is. Focus on doing the best job you can. Expecting perfection from yourself at this point adds unnecessary stress to your life. If you have done all the required work, the worst possible outcome of the review is that you will have learned something very useful (perhaps how to prepare better or do a better presentation). Keep in mind that the instructors who are conducting the review have been doing so for many years and are well aware of the common errors that students tend to make. There is absolutely no way that you are going to fool them. You will discover that they seem to magically know the exact area of your design that you have not put much thought into. They will then pelt question after question at you on your weak points and take only minimal notice of the strong points of your design. Keep in mind that there is no need to waste time addressing the strong points - a design review is not intended to be an ego boosting session as you will certainly discover. It may seem cruel, but actually they are doing you a favor by subjecting you to more challenge than seems necessary. They are trying to get you to think and to be prepared for the real world which is much less forgiving than your world as a student. If you are going to make mistakes, the best place to make them is while you are still in school where you can learn with minimal harm being done. Then, after you graduate, you will not embarrass yourself in front of your boss and coworkers.

The Two Types of Design

It is necessary to understand what design is before the design review process can be discussed. Design consists of two distinct levels - system and implementation. System level design is determining the high-level systems or functions necessary to achieve required specifications. Implementation level design is the gory but very important engineering detail required to properly implement the functions necessary for the system. Implementation level design consists of determining the appropriate subsystems, sub-functions of the subsystems, and finally, the discrete components needed. System design might be done by a small team of very experienced engineers and implementation design may be done by a much larger team or teams of engineers both experienced and inexperienced. It is very likely that in a large system the implementation of each major system component will separate into lower level system design and implementation design operations - perhaps repeated many levels down. Both system and implementation design address two issues - the required functional specifications and necessary elements not part of the requirements but that may be needed or useful in testing the system.

One of the most common errors in engineering is to blur system and implementation design (Engineers have a tendency to skip the system level design and jump straight to the implementation level). A close minded engineer (often one who has an exaggerated sense of self importance or greatness or who has aspirations of being the Savior) may have a favorite implementation that can be force fitted to meet a system requirement provided the problems of that implementation are ignored. This is a recipe for disaster, cost and schedule overruns, and total disillusionment by those stuck with making something work that was never meant to be. This mistake can be eliminated by a good design review. It is better to have one engineer with a bruised ego early than a team of disillusioned engineers later.

The Design Review Process

The design review should review the system and implementation design separately even if both are done in one session Preferably, there was at least one system design review before the implementation phase of the project was started. It is usually too late to fix system problems after the implementation has been completed. The design review should first verify that the design should meet specifications. A secondary function is identify possible improvements to the system design. These may or may not be incorporated based on the discretion of the project leader. It is not uncommon for the sponsors of a project to realize at this point that they made specification errors, omissions, or have other issues that were not conveyed to the designers. Design changes will be then be necessary - this is normal - accept it. Issues that might be important should be brought up and discussed. The third (and often overlooked) function of the design review is check the design for possible undesirable features or consequences. This task is much more difficult than verifying that the design meets required specifications. The goal is for everyone from the designer, the project sponsor, and the reviewers to be satisfied that the system design will achieve the project goals without surprise problems (most problems are surprises).

Once the system design is verified then the implementation is reviewed. There is generally no point in reviewing the implementation if the system design is faulty. Although, when both reviews are done together, the implementation might as well be looked at to find good or bad attributes - might save time when the next review is done. The concept is the same as for system level but the discussion is now focused on smaller details. It is just as important for the implementation not to have undesirable features as it is for the implementation to achieve the requirements. The discussion should focus on both.

A very likely result of the design review is that some design changes will be necessary. This is not a failure of engineering. Rather, it is the reduction of risk achieved by the collective intelligence of people far enough removed from the details so as not to be blinded by them. Once the necessary changes have been made, a follow up review should be conducted.

It is also possible that one or more design engineers has a serious problem with a suggestion (or requirement) by one of the reviewers for a design change. It may very well be that the engineer is right. After all, the engineer has been living this design day and perhaps night and knows it well. The reviewer may be expressing a first thought on the issue. The design change may be dangerous, costly, or may not even work. Since it is difficult to anticipate an error that a reviewer (yes, reviewers are human too) may make, the engineer is not likely to be prepared to make the proper points to win his or her case during the review meeting. Heated tempers or making statements without thought will not help and will only serve to discredit the engineer. I have found that the best approach is to first politely disagree or express reservations and accept the challenge for change. Then, back at your desk, study the issue carefully. You might have been wrong. Or, if you are convinced that you are right, then carefully prepare a written presentation that clearly shows the issues and how your approach (perhaps with some improvements) is the proper way to proceed. The best presentation is one in which the other side discovers its error without you ever pointing it out. Then, let your immediate coworkers review this to find any embarrassing errors you might have made. Then, give a copy of the presentation to the reviewer and other immediately interested parties for private review. Refrain from giving a copy to too many people - particularly if there is the possibility that someone may ultimately look foolish. A short term victory without grace is the beginning of a long term loss. If you have done a good job preparing your case you might be pleasantly surprised that your adversaries (maybe just on this one issue) will see their error and not only concede but congratulate you for preventing an error from causing pain and expense to all. Or, the reviewer (who may be one of those Saviors) is determined to go down the wrong path. In this case you are stuck. However, a clever engineer will usually figure out some way to cause the problem to become obvious to all by "innocently" performing some test (absolutely no sabotage) in support of the change but that fails unexpectedly to the supporters. If this does not work it may be time for you to consider other employment options as clearly, you have talent beyond what is appreciated at this location.

Choreography of a Design Review

The participants in a design review meeting are the engineer or team whose design is being reviewed, a panel of reviewers one of which is the lead reviewer and moderator of the meeting, other interested parties that might include representatives of the project sponsor, other engineers or teams who are tasked to interface to the system being reviewed, and perhaps other spectators that may be present either to learn something or provide moral support by their presence. The usual choreography of a design review has the meeting moderator make opening statements, introduce all the participants, and then turn the meeting over to the engineer or team whose design is being reviewed. Then, the engineer or team presents an understanding of the design requirements. After this presentation it may be appropriate for some questions or comments by the review panel. Next, the engineer or team presents high-level system diagrams that describe the approach to meeting the requirements. It is usually best if the reviewers refrain from asking questions or making comments during the presentations to avoid distracting the presentation and inadvertently introducing confusion. Although if it becomes obvious that there is a major conceptual error then an interruption or complete stoppage of the review may be called for. Once the basic system design has been presented then the engineer or team is ready for questions from reviewers or other interested parties (the project sponsor) that are intended to either enhance confidence that the system design is sound or expose an error that needs to be corrected. This process may be the longest part of a design review and may last for hours (with appropriate breaks for lunch or dinner). Finally, the engineer or team presents a brief (it better be brief - everybody is now tired and wants to go home) overview of the next phase of development. The moderator then adjourns the meeting.

The Different Settings for Design Reviews

Design reviews as a student. Since this is also a learning experience, expect more interruptions, questions, and comments than normal. Criticism is normal and should not be taken personally. This is a formal and serious setting and tends to be particularly stressful. Try to learn all you can from it.

Design reviews with your fellow coworkers (or fellow students). This is typically done prior to a major meeting involving management or other important people. Or, it enables the different team members to gain understanding of everyone else's work. It gives everyone a chance to practice, correct embarrassing errors, and hone their skills. These are always very cordial (even jovial), and informal.

Design reviews involving other teams. On a large project there will be numerous engineering teams focused on a particular aspect. This meeting enables other teams to learn more about the big picture. A very important function of this meeting is verification of the interface of one team's system to another team's system. Errors or misunderstandings are often made at the interface level and these kinds of design reviews help to keep different teams on track.

Design reviews with a sponsor. The stress level for these important meetings can range from none to very high depending on how well (or not well) things have been going. The sponsor has a vested interest in the success of the project and may ask some difficult questions only for the purpose of feeling confident about the project. The sponsor has no interest in making you look bad although some pointed questions might inadvertently do so. Be very prepared.

Design reviews where there are competing interests. This is the highest stress and worst situation possible. A power struggle may be taking place between different groups or companies involved on a large project and you may catch hell depending on who you work for. Ugly personal statements may be made, outright lies may be stated, and attempts to distract and discredit an otherwise good presentation may be made. Your best strategy is to focus on what you are there for and ignore the crap going on around you. If you let the crap weaken you then you have assisted the aggressor. One extremely powerful technique that I have witnessed is if someone is yelling a question or statement at you that contains obscenities or insults then you politely ask them to repeat the question as you did not understand them. If they continue with their obscenities and insults then you politely tell them that you can not make sense of the question; would they please state it in simpler terms. This process continues indefinitely until they either properly ask the question or give up. In all cases, you remain polite and cordial. Never complain about or even mention their obscenities or insults - just do not understand any statement that includes them. Keep in mind that their objective is cause you stress. Not becoming stressed causes stress for them. Understanding that you have the ultimate power should help manage your stress level.

Strategies to Follow and Errors not to make

When the design review involves high visibility with the project sponsor it is common to conduct a dry run a few days before the event so that obvious flaws in the presentation can be corrected. A student team might do several dry runs among themselves prior to the big event.

It is very important to have all drawings or other documentation complete and checked prior to the event. You should be very familiar with these and not become surprised during the review.

If the event is expected to last all day then it is critical to get at least eight and preferably ten hours sleep the night before. This insures that your mind will be sharp and reduces the probability of errors. Avoid any sleep aids as the effects may linger well into the next day and dull your performance. A long walk (or jog) the evening before is the best stress reliever known.

For at least a full day before the event, it is critical not to consume any alcohol or other drug in the hopes of relieving stress. You may feel relieved during the review only because you are unaware of your shortcomings.

Practice and experience are the only ways to overcome nervousness in speaking before a group. Never turn down an opportunity to teach a class as this gives you excellent experience gaining confidence thinking on your feet.

For some reason, humans tend to be afflicted with hoof-in-mouth disease in which the person continues talking after all has been said that needed to be and the additional speech serves only to bring up issues that did not need to be or should not be brought up or otherwise makes the person look foolish. Be aware of this and try to avoid it - but it is difficult. Generally, you are not aware that you are afflicted with this disease until you hear an audio tape of the meeting and hear yourself making numerous dumb statements that you wish you had not said.

No matter how much you have prepared, it is possible that you will be asked a question that you are unable to answer. In the case of a student design review it is almost certain that you will be asked at least one question that the instructors know you can not answer just so they can gauge how you handle this situation. If you try to fake an answer then expect more detailed questions on your improvisation (a nice way of saying your lies) - to the point where you look like a fool. An answer about as bad as faking it would be, "I do not think that issue is important." No one can challenge you when you answer, "I do not know the answer to that right now but I will find out;" or, "That issue did not occur to me but I will investigate it." The other party may be disappointed that you were not able to answer the question but they will respect your honesty. And, you will not look like a fool.

It is possible that someone will point out an error you have made in your design. They may or may not be right. The best strategy is to defend your position until something comes up that makes you realize that you are in fact, wrong. It is extremely important to balance defending your position with keen listening to pick up anything that might cause you to change your mind. The sooner you find out that you are wrong the better things will be. If you are wrong then very quickly admit error. It is folly to defend a wrong position. If things have become a bit stressed prior to your enlightenment, a touch of humor can settle things back down for you as well as for everyone else. If the setting is appropriate (avoid all humor if the setting is not conducive), such quickies as, "Well, I guess this just proves I am human;" or, "To err is human. To forgive is divine. I am glad this is a divine group;" or, "Gee, if it weren't for mistakes, I'd be perfect;" usually bring a chuckle and get things back on track as well as giving you a moment to recollect your thoughts. The key point is not to take things personally, do not feel bad, be thankful that it was just an error in a meeting rather than a catastrophic failure that will leave people laughing at you for years to come. A short term loss with grace is the beginning of a long term victory.

One problem particularly affects students. Suppose the student or team has done their engineering and has a system that is very likely to work. Because of inexperience, it is likely that this system has room for simplifications or component count reductions that may be suggested or even insisted upon by the reviewing instructors. The inefficiencies in component count usually occur at the partition between different team member designs. With a little thought, two components might be combined into one but the overlap might cause testing to become much more difficult than it was when things were partitioned well. It is not as easy to pinpoint the problem in a simplified system when something is not working right. Unfortunately, the students often feel they have to give in to this and then end up spending a lot of time trying to make something work that they do not understand as well as their original design. Students should strive to resist changes that are not related to design errors. Here are some possible strategies. If the design is for a one of a kind item then the engineering expense of simplifying the design is not worth the components saved. Or, the risk of changing a design that everyone is comfortable with is too great if the schedule is short. It is better to have an inefficient item that works than an efficient item that does not work. Sometimes a statement to such as, "I am just a student learning this for the first time. I want to gain confidence that my design actually works before I attempt to optimize it," may buy time. Sometimes an out is to offer to consider simplifying the design after everything works to specification - but only if time is available. Some changes may be simple and should cause no problem for the team - these changes should be accepted without contest. If a change causes concern then that concern needs to be expressed and documented. Later, when things might not be going well with the changes, you have a basis for backing up to the original design.

As a student team, suppose you are asked the following question, "Explain how you determined the value of R14 to be 8.2k." Your response had better be one of the following: "8.2k was required by specification such-n-such;" or,
"This was the value provided (or recommended) in the manufacturer's application circuit for use with such-n-such part;" or "As shown in the design notebook it was calculated based on such-n-such requirements;" or (when there was no known method of doing a calculation), "Experimental data recorded in the design notebook indicates that 8.2k is about the optimum for such-n-such requirements;" or (in the case where some resistance is necessary but it only needs to be between some rough maximum and some rough minimum), "Our calculations in the design notebook indicate that the maximum value the resistor can have before such-n-this problem (or issue) occurs is about 37k and that the minimum value the resistor can have before such-n-that problem (or issue) occurs is about 1.7k. We chose a value close to the geometric mean of the extremes (generally if the extremes are wide you choose the geometric mean and if the extremes are narrow you choose the average)." Carefully review your design notebook prior to the review. Expect to be asked a question about any component that you have not documented how the value was determined. This question is going to put you on the spot. Some bad answers (see War Story 1 below) include: "We just picked it and it seemed to work;" or, "It was just a handy value we had;" or, "We don't know." It is important to realize that as a student, you must have some definitive basis for determining a component value even if that basis is not the best basis that a professional might have used. It is a very minor offense as a student to not have used the best criteria. After all, you are a student, not yet a professional. It is a major offense to have guessed or used no criteria. If you are asked this question and you realize that you do not have a good answer, your best response is something to the effect, "I regret to say that we failed to determine a good basis for that value. It should have been done and there is no excuse." You are still in hot water with this response but at least the water is not scalding as in War Story 1. Etch this in your brain - it is folly to defend a wrong position.

True Stories from the Battlefield

Although it is good to learn from your mistakes, it is even better to learn from the mistakes of others.

War Story 1:

The following is an excerpt from a student oral presentation of a senior design project that took place many years ago. Although it was not a design review, it illustrates the importance of being prepared and having done a thorough job of engineering.

Reviewer: "Didn't you take professor Kuhn's EE431 Class?"

Student: "Yes."

Reviewer: "Did professor Kuhn discuss bias current compensation in op-amp circuits?"

Student: "Yes."

Reviewer: "Then why did you not bias current compensate this op-amp circuit?"

Student: shrugs and says, "I don't know."

I will spare you the gory details but to put it bluntly, a crucifixion took place that afternoon. For this student's particular circuit, bias current compensation was not needed - simple calculation showed that the error was too small to bother with. The compensating resistor was not needed and should not have been there in the interest of minimizing the number of parts. But, that is not the point. Suppose the student had responded, "My calculations in the design notebook showed that the error due to bias current is only 1.4 millivolts which is smaller than other acceptable errors in this system. In the interest of minimizing the circuit, I chose to leave it out." That response would have showed that the student understood the issue, had done the appropriate calculations, and had made an engineering decision based on those calculations. While it is always possible that someone on the review team might disagree with the student's decision, no one can put the student down for having failed to do competent engineering. Actually, if the student had the appropriate work in the design notebook, the above exchange would probably not have taken place. You will be asked questions more on what you did not do. A key point to make is that the reviewers sensed that the student had not done the proper work and thus focused on that. The moral is to be sure you have an engineering basis for every decision and if challenged, then state that basis - that is exactly what the reviewers are looking for. If the reviewers push you, they expect you to push back. Your job is not to whimper away.

War Story 2:

The following exchange took place at an at-work design review where I was an invited panelist. The subject at the moment was an anti-alias low-pass filter to be used to band-limit a signal prior to being digitized by an analog-to-digital converter.

Mr. Kuhn: "What is the bandwidth of the signal?"

Engineer: "We don't know."

Mr. Kuhn: "What are the spectral characteristics of signals that might be aliased?"

Engineer: "We don't know."

Mr. Kuhn: "How did you determine what filter to use?"

Engineer: "We felt that a third order Butterworth low-pass filter with a cut-off frequency of 320 kHz would do the job."

Mr. Kuhn: (with much disgust) "My EE431 students could have done better than that."

Had this engineer been a student at UAB, this would have been the classic setup for a crucifixion. The moral to this story is if you do not know something then seek to find out. Even if some data can not be exactly known, there are methods by which a reasonable estimate can be determined. If all you have is an estimate to base your design on then that is far better than a wild guess plucked out of thin air. An estimate with basis can be checked by someone else. A wild guess can not be checked. If they had any sort of reasonable estimates for the data then I would not have faulted them. Engineers are not paid to guess.

I have some more stories but at this point I have developed writer's block as I have been writing for a good part of the day. I will add more stories as I can remember them or hear of new ones.