Successful hardware projects start with…

Article By : Steve Hageman

Running a design project with a design data sheet does not guarantee success, but it does tend to keep people focused on the important tasks.

Who hasn’t worked on a project that went nowhere or got canceled? Sometimes the project deserves it because it was ill-conceived or poorly executed. Sometimes markets moved or there wasn’t really a need, and sometimes the project was just in chaos from the start.

This last reason to get canceled is the one that is most easily prevented. It usually stems from a lack of a solid game plan. What is a solid game plan in the electronics business? Well, it starts with a “design document”. Although, I prefer to call it a “design data sheet” for hardware projects.

If you don’t have one, your project is going to have lots of tension, re-spins, and course changes. Which usually ends up with something that no one envisioned from the start, has many schedule delays, and cost overruns. In the worst case, the project ships incomplete, or ends up canceled.

Where to start

The project design data sheet has some similarities to a product datasheet that is given to a customer, but it does not need to include the boilerplate marketing talk.

Look at any op-amp datasheet; one-half of the front page will be features and applications. These items, although important as selling points to customers, are not suitable for a design data sheet. The design data sheet is the place where hardware design, performance, and cost goals come together in one document. The document intends to get the design/implementation team on the same page at the start of the project and to drive the design to a known endpoint.

Look at that op-amp datasheet again, starting with the first page, there is a “description”. Any project needs an executive summary “description” of the project. For example, on an FFT analyzer that I designed for use in my Lab, I wrote a description that said:

“Four-Channel, Simultaneous Sampling, FFT Analyzer useful in measuring signals in the 0-5 kHz band. Used for dual-channel, IQ baseband measurements, and 2-channel cross-spectrum noise measurement. Turbo mode to allow a single or dual-channel(s) to be read at a much faster rate for high over-sampling applications.”

After this brief description, I usually include a block diagram and or a physical size figure. Figure 1, is the initial block diagram I drew for this project.

Figure 1 The block diagram starts out simply at first, just capturing the main detail. By the end of the project, it should have been revised into a document that would be useful in troubleshooting the finished product.

The block diagram is an important part of any hardware project. It starts very simply and then expands as the project takes shape to include more and more information. At the very minimum, it shows the signal path through the product. At the end of the project, the block diagram should be complete enough to be used as a troubleshooting document by production.

The physical size picture listed the desired case from Hammond Manufacturing and a sketch of the front and rear panels (Figure 2).

Figure 2  A physical size, front and rear panel layout, no matter how rough, should be included in the first draft of the hardware design data sheet. As the project progresses, the details will be filled in.

That gives the design team something to shoot for and serves as a reminder of what the finished product should look like.

The key specifications

Again, using our op-amp datasheet as a guide, not every specification is important to every customer. The way to sort these specifications is to start thinking about the key specifications, or the performance targets that you are shooting for that would matter for both this project and, for your customers. Some companies call these the “money specs”, or the specific specifications that are the major selling points to your customers.

For my FFT Analyzer, I made a list like Table 1.

Table 1 A design document or design data sheet has to begin somewhere. The key specifications (or “musts” as explained below) are the easiest to start with, then as the project progresses, other details are added as they become apparent.

The list above is a skeleton of what any real product needs, as even a simple thing like a power supply will probably run a full two pages, minimum. You should also list every IO connector, and what protection is needed as ESD, or overpowering on poorly protected IO connectors, is one of the highest failure rate items on any product.

Overcoming engineering writer’s block

Don’t know where in the world to start? Just start with something easy, like the operating temperature range, power requirements, size, etc. Also, the key specifications are the easiest to start with. Fill out the other specifications by looking at competitors’ datasheets and looking for other important items that you may have forgot to include in the first cut.

In reviews, others on the team will realize that specifications need to be added, modified, or deleted. Some will naturally criticize the document as being incomplete, but that’s just natural. What you want to get is insightful input on what everyone has missed up to that point. This is doubly important if you have forgotten important information that has a significant staffing, cost, or schedule impact.

Realize that this feedback would have never happened if you did not have a design data sheet in the first place.

With word processor technology, it is easy to re-arrange and reformat the document as you go along, so keep getting input and making refinements as the project progresses. Keep the block diagram up to date as well.

What happens when?

What happens if you started with a very hard-to-achieve specification, or even worse, someone (typically a marketing type) says: “It needs to do this also.” What do you do?

When I worked at “Classic Hewlett-Packard” [1] in the 1990s, they had a wonderful process for dealing with these sorts of inquiries without distracting the entire team. They would take these inputs, in light of the entire project scope, with an eye toward separating the “musts”, and the “wants” of the design [2]. This would define what is a project “must”, versus at least having a listing of useful “wants” for the product.

For instance, in a bandwidth specification of my project, the filters may be set to do just what the “must” specifies, thus limiting a “want”.  What if, when the designer is working on that part of the circuit, he discovers that he can set the bandwidth to cover the “want” also with no degradation, and little cost, he should do it right? Without some list of this “want”, the enhancement probably would not happen.

Now if you have ever done this, you will know that the discussion of “musts” and “wants” can quickly devolve into a discussion of: “wants”, “high wants”, “high priority wants”, “pretty, pretty, please wants”, and so on.

Don’t get dragged into splitting priorities like this: It is either a “must” or a “want”, nothing else.

If you start to get dragged into these situations often, it is a sign that everyone is not aligned on the project goals and scope yet. It is always better get that straight right away before moving on.

Revisions

Complex products naturally change during execution. Something that may have seemed simple, like product cooling, may be more difficult as it becomes obvious that the power is higher than originally envisioned. So, the design data sheet will need to change. I suggest that there should only be one owner of the document and it is even better if it is in a revision control system. Shared drives are a poor choice, as what one person thinks is an adequate revision control will be vastly different from what another person thinks. There is nothing more un-fun than opening up a design data sheet that you wrote and finding changes all over the place with no record as to who, when or why they were made.

To prevent opening the document and finding countless undocumented changes, only put a PDF on the shared drive and have a note on the document’s front page that any proposed changes should be funneled through the owner.

The design data sheet is a living document. It is meant to capture the best information at the time of the last revision. As things change, so does the design data sheet and block diagram.

Who is the owner?

This brings up the next point: Who is the owner of the design data sheet? It needs to be the engineers who are doing the design work. Yes, I know that adage applies: “It is more fun to start a new project than to do the current one.” However, if you want a chance at a successful project outcome, you simply cannot skip the required upfront work required.

Other aspects of product design

Most products require firmware or software now. There should be an equal document describing the firmware/software goals written and maintained by that team [3].

Likewise, any hardware will need some testing done. On a small team, the design engineers may be responsible for this, in larger companies another department may be responsible for this. At any rate, the design engineers should rough out a design document for these tasks, or at least closely team up with the production people early in the design phase to ensure alignment.

Why the design team? Because they know the hardware and as such will know the hardware limitations and what should be tested. This exercise of thinking about production tests will also give them insight into the required firmware/software hooks that will be needed to independently test each hardware section that is useful in both performance verification and debugging of broken hardware. This information needs to be shared with the software/firmware team as part of their requirements.

Takeaway

Running a design project with a design data sheet does not guarantee success, but it does tend to keep people focused on the important tasks, by taking the opinion out of a project and making the goals clear. It also brings to the forefront any massive changes that can impact the project completion early. And that’s the goal– get the information, good or bad early.

This makes it easy for project managers to actually track and proactively manage the project. Making any needed course changes along the way.

References

[1] Micheal Malone, “Bill and Dave: How Hewlett and Packard Built the World’s Greatest Company”, ‎ Portfolio Trade, March 25, 2008.

[2] Some companies call the product “Musts” the “Minimum Viable Product”. https://en.wikipedia.org/wiki/Minimum_viable_product

[3] Sometimes the software/firmware can be driven in a data-sheet form, other times the “Agile” or other approaches are needed. https://en.wikipedia.org/wiki/Agile_software_development

Steve Hageman has been a confirmed “Analog-Crazy” since about the fifth grade. He has had the pleasure of designing op-amps, switched-mode power supplies, gigahertz-sampling oscilloscopes, Lock In Amplifiers, Radio Receivers, RF Circuits to 50 GHz and test equipment for digital wireless products. Steve knows that all modern designs can’t be done with Rs, Ls, and Cs, so he dabbles with programming PCs and embedded systems just enough to get the job done.

Expo booth:

New products & solutions, whitepaper downloads, reference designs, videos

Conference sessions:
  • Internet of Things (IoT)
  • Supply Chain
  • Automotive Electronics
  • Wave of Wireless
3 Rounds Lucky Draw:

Register, join the conference, and visit the booths for a chance to win great prizes.

Leave a comment