Estimated reading time: 6 minutes

Elementary, Mr. Watson: Is the Tail Wagging the Dog?

I recently had the opportunity to work on a rather critical PCB design project during what should have been the final design review. Unfortunately, after presenting my well-organized PowerPoint presentation, I asked the most challenging question to the group of assembled engineers and managers, “So, what do you think?”

As we went around the room, nearly every comment started with something like, "You know what we could do..." Ideas flew around the room, fueling a full-blown brainstorm. Unfortunately, what followed could best be described as organized chaos. The result was that several of the suggestions took the product back to re-design, and what was supposed to be the final steps didn't happen.

Although I was slightly discouraged, I asked the group a prudent question. Was the tail wagging the dog with our project? A few got my reference and agreed. The official definition of that phenomenon describes a situation in which an important or influential person, organization, etc., is controlled by someone or something much less important or influential. The events in the conference room didn't rise to that level, but it was the same basic principle.

We all have experienced the same thing at one time or another. As designers, we know the various steps in creating a PCB design. The four significant stages are the library, schematics, PCB layout, and documentation. In addition, each stage has secondary steps that you must do correctly.

Furthermore, we know the interconnect of the design, starting with the details stored in the component as the schematic symbol gets placed into the schematic and the other models get pushed into the PCB and ultimately into our documentation so we can build the board. We know how everything is connected and the needed steps.

We know the pitfalls and possible problems in a design and the necessary steps to avoid them. Lessons are learned the hard way by making difficult mistakes sometimes. I know because I've been there, making the long walk to my manager's office to explain how I messed up.

We know the deliverables at each stage, and everything is checked and double-checked. Until we reach the documentation stage, we create that final fabrication and assembly package, and it's off to be built. For the experienced designer, this is a process we successfully went through thousands of times, probably more. Frankly, it's a process we enjoy doing. It is an understatement to say that designers love their work. Actually, PCB designers are some of the most passionate people I've ever known. Most PCB designers (the great ones) eat, breathe, and sleep PCB design.

My point in all this is we know the steps and are passionate about what we do, but nothing prepares us for such a scenario as I described earlier.

How Does That Happen?
The bigger question in my mind after the meeting was not all the additional items on the tasks list but rather how such an event occurred in the first place. How did an established company not just send a PCB back to re-design, but how did we lose control of the design process at that point? Of course, changes are an unfortunate but common practice at the beginning of the design, and we'll see why that is the case in a moment; they are easy to handle when just starting things. But a completed design showed us that, yes, the tail was wagging the dog.

Honestly, it happens a lot in companies. You know what I mean. You're well into the design, and changes start happening. Now you are just not concerned with the PCB process, making sure that you don't miss something, but now you also need to change the wheels on the bus while it's moving.

If you're like me, I hate when I'm interrupted. Most people, especially the technical types, jump in and focus on the finish line. For example, when I make a road trip with the family, it doesn't matter how far the trip is; things are scheduled down to the minute with arrival times and mileage, and it's, “Strap yourself in; we're not stopping until we get there.”

I believe that the event I described earlier is not just avoidable but with several best practices it can improve the product and process flow, ultimately making the company more money.

Know Your ‘What’
As designers, we understand how something is done, how we get from Point A to B. But the tail begins to wag the dog when we lose sight of the “what.” What defines the objective or direction? I once had a boss (one of the best I’ve ever worked for) who could identify when I was struggling, and he would sit me down and ask, "What are you doing?" (And please be brief, I would say.) That simple exercise identified my direction and objective. Likewise, when there are constant changes to a design, we must ask, "What are we doing? What is the objective?”

With a clear “what,” we can identify the finish line. You will see and identify the finish line very quickly. This is a requirement, with no finish line, engineers will continue to do what they do best: engineer. Constant improvement is a part of engineering. But when trying to get a finished product to market, we must know when the design is finished, and the engineering must stop.

A Simple Answer: Design Specification
Defining a product's details occurs in what is called the design specification. Of course, your company may have different names and what is covered. But the excellent design specifications have detailed sub-documents that cover specifics like functional specification, which shows the product function and purpose. Also, requirement specifications further define what we are doing. The finished product should meet a specific criterion, including each department's deliverables and requirements.

Another is a design specification which supports the requirement specification and describes the specific features the product should have. All the various parts of the design specification are the guiding documents pre-approved by all stakeholders before any work begins.

If this were a Seinfeld episode, it would be said this way: "What's the deal with design specifications?"

The hard truth is that some companies either don't use design specifications at all, or the ones that exist are poorly written. As a result, some believe they stifle "engineering creativity," which is invalid. Look at a design specification as the banks of a river. Although they don't stop it from flowing, the river still can meander over a set path directed by the banks. In the same way, a design specification directs the path of everyone involved in the project.

How do we handle changes, then? Various folks from different departments will give input, which is fine. You always want to encourage that sort of thing. But you must seriously examine each request and ask a simple question: Is this a need or a want? You must know the difference. You can call the needs mission critical, show stopper, etc. Identify each request and know the difference. But if it is a need, the follow-up question is why it was missed and not placed in the design specification; we must find the root cause. So, either it's a change in the design or a change in the process and policies. The hope is to have better design specifications in the future

Otherwise, if you find it a want, you can probably wait until the product's next revision. For now keep the focus on the finish line and the present.

By implementing a detailed design specification policy to direct the product development, you will keep the changes down to a minimum or even zero and not have the tail wagging the dog.

John Watson, CID, is a customer success manager at Altium. 

Download The Printed Circuit Designer’s Guide to… Design for Manufacturing by David Marrakchi. You can also view other titles in our full I-007eBooks library.