How to Avoid Design Bottlenecks

By John Edwards

Like an author who suddenly faces writer’s block or an artist who can no longer bear to pick up a brush, an engineer encountering a design bottleneck knows that the situation can be agonizing, costly and difficult to shake.

Designers use a variety of terms to describe the incidents that can pop up to delay a project at any point during its life, including bottlenecks, challenges, roadblocks and hangups. The good news is that most design headaches can be avoided entirely, or at least quickly overcome, simply by following a few basic rules. Here’s a look at how experienced designers and design managers keep their projects on schedule and moving forward.

Physical prototypes help non-designers understand a product and suggest changes before it goes into production. Image courtesy of 3D Systems.

The Biggest Bottlenecks
Project bottlenecks often develop when the designer is unsure of a project’s requirements and goals, observes Scott Harmon, a vice president at Z Corp., a prototyping systems developer located in Burlington, MA, which was acquired by 3D Systems in January. “Critical bottlenecks occur as a result of uncertainty and a lack of decision-making,” he says.

Harmon notes that while some decisions are relatively straightforward, such as whether a design can withstand a specific operating temperature, other decisions are much less clear-cut, “such as determining whether a particular design will appeal to its target market.”

When facing a bottleneck created by poor or indecisive planning, the designer needs to work closely with project stakeholders to gather as much relevant data and insight as possible to overcome the bottleneck and complete the project. Unfortunately, designers are often left out of the decision-making process.

“They are stuck while someone less connected with the project fails to make a decision,” Harmon says. “But when the project is late, it’s rarely the decision maker’s fault; it’s usually blamed on the engineering team.”

Rich Walters, director of design at Red Fusion Studios, a Downers Grove, IL-based product development firm, says he believes that cross-functional teams are essential for developing clear and specification-rich product designs, yet warns that there are limits to the amount of input any design can bear. “Attempting to gain consensus on all design issues can add significant time to a project, and have a negative impact on the integrity of the design,” he notes.

Sudden and unexpected design changes are another major source of project hangups, says Justin Scott, a design engineer based in Washington, D.C. Schedules are based on a best-case scenario, and extra time and money is often not included for changes in specifications, he notes: “If a specification change is particularly fundamental to the design, an engineer may have to scrap weeks’ worth of effort to accommodate it.”

Occasionally, a design change results in a project-blocking challenge that appears almost unresolvable, says Scott. “Certain components of a design may become difficult or impossible to obtain, which requires the design be re-engineered,” he adds. “These challenges are less frequent, but they do occur. I have found the best resource in this situation is the assistance of another engineer to help overcome hurdles from a new perspective.”

Addressing Challenges
The best way to solve virtually any kind of bottleneck is for the design team to gather together—in person—and discuss the relevant issues in an open forum, Walters says. “Although business cultures are changing, we still see a lot of management by memo, where emails fly back and forth, creating a tone of conflict and distrust,” he says. “By bringing the team together physically and using the project brief as a discussion guide, you can usually resolve issues in a matter of hours instead of days or weeks.”

The first step when encountering a design process challenge should be to check the requirements document, says Tim Jacobs, process design group manager and senior technologist with Optimation, an industrial engineering services company in Rush, NY. “If one does not exist, develop one with the client,” he advises.

Once the requirements have been defined, the next step is often a block diagram and then a flow diagram. At this point, space requirements can be developed in a preliminary way—often in the form of a layout or 3D model. “The flow diagram and preliminary model are the foundation for the project, and should be agreed upon before proceeding with the design,” Jacobs says.

A physical prototype is critically important in resolving many kinds of bottlenecks, Harmon notes. “It’s specific, there’s no uncertainty—it’s not a drawing or a rendering ]and] nothing is hidden or half-done,” he says. “It’s an object that you can hold in your hand; you can see, feel, measure and assess a prototype.

Harmon says he believes that models tend to reveal big mistakes sooner. He notes that a prototype also allows non-CAD people to interact with a design in a comfortable and familiar way.

“Managers, manufacturers, customers, marketers, salespeople, market researchers and others are all involved with successful new product launches, but none of them uses CAD,” he explains. Harmon says that prototypes effectively bridge the gap between designers and the non-tech world.

“I know most engineers would rather gouge their eyeballs out than invite the opinion of the sales department,” he says. “Still, I’d rather have them criticize early and sell later, than criticize after the product is done and find something else to sell.”

Setting Design Requirements
Most experts agree that having clear, specific, agreed-upon design specifications helps keep bottlenecks from developing.

“These specifications should not be set down until sufficient research has been done on similar products in the market, customer requirements and engineering methodologies to avoid costly design challenges,” Scott says. He notes that once all of the specifications are in place, good project management takes over. “If specifications change, so should the project schedule and cost estimates. An experienced project manager shepherding a product through the design phase will ensure that bottlenecks are anticipated, accounted for and alleviated.”

Design requirement specifications are essential for preventing project delays, as long as they are set thoughtfully and with a purpose, Walters says. “Designers need to know limitations, end goals and the reasons for the spec,” he explains. “If a specification is expressed as a design solution, the reason should be made clear.”

Specifications that are in conflict with each other must be eliminated, and the remaining parameters prioritized, according to Walters.

“On legacy projects, the tendency is to use the abundance of resident knowledge to create an extensive list of specs,” he says, noting that while it’s important to learn from history, care must be taken not to let past experience stifle the design process: “Be leery of a 10-page specification after one week into a project.”

Good designers, he notes, understand that development is not always linear, and that new problems will arise—creating a need for changes.

“In new product development, specifications are often best left flexible until initial research is done and initial concepts are developed,” Walters says. “But at some point, the team needs to put a stake in the ground to allow the project to move forward.”
Staying flexible will help keep projects from derailing over a minor obstacle. “Single-minded adherence to a spec sheet in a changing environment is a path to ruin,” Harmon warns. “This is why tools that aid decision making and allow for rapid changes during the design process are so critical.”

Using the Right Tools
According to Walters, using the appropriate software for each task helps a designer avoid bottlenecks and efficiently produce accurate, usable results.

“Design software is a tool to communicate intent and/or to prove out a solution before the start of creating any physical manifestation of the product,” he says, noting that if the design software isn’t integrated into the system and doesn’t provide useful data downstream, then efficiencies are lost, design intent can suffer, decisions can slow and—perhaps worst of all—wrong decisions can occur.

“That’s why it’s important for design, engineering and manufacturing to have a coordinated set of software tools and well-trained people using them,” he says. Installing software updates is also important, because obsolete software could lead to wasted time, incorrect designs and other mistakes: “Just like in the shop, it is dangerous to use a dull tool.”

Jacobs says that designers who handle a variety of different assignments need to be familiar with an array of software tools, using each one for a specific type of work.
“Is it going to be machine design with tight tolerance?” he questions. “Or plant layout requiring many disciplines to share space? Is it 2D or 3D? Database or just simple graphics? Analysis required for strength or stress?”

Harmon agrees with the need for task-specific software. “Design software is a tool—use the right tool for the right job,” he says. “You wouldn’t use a screwdriver to pound a nail.”

On the other hand, however, Harmon stresses that software is no substitute for solid experience. “I’d take a great designer/engineer with an average software tool over an average designer/engineer with a great tool,” he says.

Managing Change
“It often seems as if the designer’s primary responsibility is managing change,” says Walters, who opines that designers can most effectively gain control over change management by building trust and communicating openly with fellow team members. “When change occurs—and it will—communicate with all team members who will be affected as early and often as possible.”

Walters says that it’s also helpful to develop alternative solutions, which will give project stakeholders options and allow them to participate in problem-solving exercises. “That way, you won’t adopt a change that looks good on paper, but can’t be executed on the manufacturing floor,” he says.

Scott says a good designer manages change by setting expectations properly. “Having a can-do attitude is paramount when working alongside management, sales, marketing, production and so on,” he adds, “But an engineer must always be careful not to make off-the-cuff estimates of time or cost that may have to be revised later.”

Scott advises that engineers should strive to make accurate estimates and finish projects in less time than their estimates project. “If design specifications change, an engineer should try not to become frustrated—design is our job, after all,” he says. But a designer should always be ready to explain, quickly and clearly, exactly how any changes will affect schedules and cost estimates.

“Trying to make design changes without affecting these things will almost always fail, and hurt the engineer’s reputation in the long run,” Scott says.

Solving Problems
Walters notes that an important step in problem-solving is correctly framing the issue in a way that creates the widest possible range of potential solutions.

“We like to use the phrase ‘In what way might we?’ to help us do this,” he says. “So rather than saying, ‘The product fails in testing,’ the opportunity becomes, ‘In what way might we change the design to extend product life?’”

Intelligent problem-solving also includes a willingness to think creatively, and to be willing to search for solutions wherever they may exist.

“By looking outside your industry, you might find a material, technique or process that will help you leapfrog your competition,” Walters says. Meanwhile, if a problem is truly vexing, or if team members disagree on the course of action, an outside facilitator can be brought in to help optimize the options and identify any underlying issues that may be creating the bottleneck.

In the case of an unexpected behavior that crops up in the testing phase, scientific reasoning can be used to find the answer. Scott recommends a four-step process:

1. Observe the behavior.
2. Form a hypothesis that explains the behavior.
3. Devise an experiment to test the hypothesis in a
repeatable manner.
4. Perform the experience and record the results in detail.

“Analyze the data recorded and repeat the process again until the behavior is explained,” Scott says. “At this point, suitable solutions can be devised and tested.”
He warns that skipping any of the steps “will result in frustration, lost time and wasted effort.”

Walters, meanwhile, has one final word of advice and reassurance: “No problem is so big that it can’t be solved, especially if the team members trust and respect each other’s skills and are committed to open communications throughout the process.”

John Edwards is a freelance writer based in Gilbert, AZ. Contact him via [email protected].

MORE INFO
Optimation.us
RedFusionStudios.com
3DSystems.com
Zcorp.com