503.210.2100
Blog
Brian Terhune

Outsourcing product development can make any OEM nervous. All of us with experience in the field have seen first-hand what happens when outsourcing goes wrong—higher costs and time-to-market delays reduce sales volume, lower profitability, and shorten product life cycle.

In a perfect world, OEM project managers communicate their general product requirements to the development partner and establish a collaborative relationship with them. Both parties work together to define the exact requirements for the new product, and the development partner demonstrates the capability to execute.

But this thirty-thousand-foot view makes outsourcing product development sound easier than it really is. In the real world, projects stall due to a myriad of problems such as:

  • Vague or conflicting product requirements
  • Design solutions that fail to perform as expected
  • Processes that don’t include validation and functional testing

Understanding why outsourcing problems arise—and knowing how to prevent them—takes experience. This article will focus on recognizing the underlying issues that cause development problems and look at ways to mitigate the risks.

Remove the Guesswork, Remove the Risk

Product development issues manifest in many ways, and a few of the more common examples include: System interfaces aren’t well defined. Firmware features are improperly implemented. Components or subsystems do not meet required performance. Any of these can result in additional development cost or increased time to market.

 

To avoid problems in the first place, begin by recognizing vulnerability in three key areas:

  1. Product requirements
  2. Technology application
  3. Development practices

When you evaluate prospective product development resources with these three areas in mind, you improve your chances of finding a partner able to deliver the right product for you.

1.      Understand and Agree on Product Requirements

There can be no ambiguity when it comes to product requirements. It’s critical that you first agree, in detail, what it is your development team will design. They must be able to leverage experience and challenge your product requirements when appropriate. For example, if you have a requirement that will create issues with electromagnetic interference (EMI), you want a development partner able to suggest a design change that will eliminate the problem.

Identifying issues like this empowers the development team to dig deeper. Sure, they’ll document the overall architecture, but they’ll also team with you to evaluate expectations for individual components, environmental requirements, types of testing, and required certifications. Good communication eliminates the unknown and puts everyone on the same page, working toward the same goals.

Unknowns create uncertainty about costs, deadlines, and functionality. If you do not define and agree on product requirements, how can you be sure your development partner possesses capabilities necessary to complete the project on time and on budget? How do you know when you’re done?

The Product Development Balancing Act

When an OEM requests new product features after agreement on the detailed requirements has been reached, the product development team must perform a balancing act. It needs to weigh the benefits of the new feature against the potential impact on cost, timing, testing, production, and profitability of the product. You want a development partner brave enough to communicate the realities of these changes to you.

When the development team works with the OEM to establish definite, detailed product requirements and specifications at the outset, it removes the guesswork—and therefore risks—associated with change requests.

2.      No Substitute for Technology Expertise

In electronic engineering and manufacturing, technology is not one-size-fits-all. A given technology or component can work well for one product and fail miserably elsewhere. The result depends on a number of factors, including environments, tolerances, and functional requirements.

Product requirements often call out specific services instead of features. If, for example, you specify Wi-Fi instead of wireless connectivity as a feature, your development partner should make sure that is what you really want. To do that, the development team must ask the right questions.

What do you need to transmit? Is it just a few characters of text? Will the product be used in an environment where Wi-Fi is the most reliably available form of connectivity? How will it impact the energy requirements? Often, applying the right technology begins with questions about what drives the real product requirements.

3.      Good Process is the Foundation for Smooth Development

Process is the keystone of smooth product development. Good process creates opportunities for innovation, cost/benefit analysis, and product life cycle planning. Process that focuses on measured results keeps stakeholders aligned to common goals.

No project is without its speed bumps, but process can minimize their impact or help avoid them altogether. Good process provides clear detail on every element of development. From product specification and engineering, to validation, functional test, and manufacturing, sound process will mitigate inherent product development risks.

When you need to outsource product development, seek a process-driven partner who will work with you to maximize features, minimize cost, and race your product to market. Be sure they use a documented and repeatable development process, and have a track record for delivering end products that meet the needs of their customers.

Product Development Outsourcing Done Right

Product development outsourcing doesn’t have to be nerve wracking. It can do just what it’s supposed to—deliver the right product that meets requirements, contain costs, and keep inhouse resources focused on core competencies.

To make sound outsourcing decisions, identify the functions and features, all of the must-haves, your new product requires. Then find a product development partner able to marshal the right technologies for each stage of development and use a proven process to ensure timely, cost-effective delivery.

A collaborative outsourcing partner will dig deep in an effort to excavate all of the product requirements, bravely communicate the realities of feature creep, and show you the scars of their experience—demonstrating they have done this before. With a partner that applies the right capabilities, technologies, and process, you may find yourself in a near-perfect world after all.

Brian Terhune
M2M Communication

M2M Communication

While the term M2M (Machine 2 Machine) may be new to some people, it is becoming a larger part of our lives every day. Given that Stilwell Baker receives many inquiries related to electronic product development, it is interesting that M2M is no longer an option; it has morphed into a requirement. Because of this, it’s the perfect time for a three part blog series on the background of M2M evolution, where it exists today, and potentially where it will be in the near term.

An early example of M2M communication would be the technology that allows wired systems to communicate with various devices. For example, a SCADA (Supervisory Control And Data Acquisition) system that monitors pressure in an industrial facility and alerts a central computer if the pressure is out of limits. M2M communication has evolved as wireless technology and has eliminated the need for hard wire connections, thus reducing cost and system installation time. Now a sensor communicates through a wireless network to the central computer. But the evolution didn’t stop there; the one-to-one communication was superseded by a system of networks that transmits data throughout the company and its partners. When a fault is detected, the maintenance company is automatically notified and dispatched for field repair potentially reducing facility downtime. Finally,  provide the infrastructure for individuals to communicate with their personal appliances (home security, heating and cooling, consumer electronics, automobiles, etc.) and the M2M market really starts to get interesting.

The infrastructure required to support today’s M2M market is vastly different than earlier configurations. Each sensor or remote device must be fitted with a cellular module. The device needs to be on a cellular network, hence a Mobile Network Operator (MNO) is needed (Verizon, AT&T for example). Module selection is also dependent on whether or not the MNO will allow them to operate on their network. In other works, the module must pass certification testing (in addition to PTCRB & FCC certification) that shows it will operate as intended on their respective network. Security of the devices and the network is another aspect that needs to be incorporated into the end-to-end solution in order to protect the M2M implementation. Custom software applications may also be required to connect the remote device to the central server of a business.

M2M wireless networks are already in use in various areas. According to a 2011 Pyramid Research report, M2M applications can be broken down by seven general industries: Automotive,  Transportation, Utilities/Energy,  Security, Financial/Retail, Health Care, and Public Safety. On-Star is one example of a well-known M2M implementation within the automotive industry. Other initial implementations include fleet management or asset tracking. When you use your credit card to purchase a product or at the parking meter, you are using M2M.

Part two of the blog series will focus on where we are today with M2M and detailed considerations regarding implementation and infrastructure.

Earlier this month Lee Teschler, editor of Machine Design magazine, visited with Darrel Baker and Rick Lundin about their experiences with outsourced electronic development projects gone wrong.

Read Lee’s March 18 blog post on their conversation.

Darrel Baker

Since its release last June, the Tesla Model S has accumulated a significant collection of industry recognitions, including multiple 2013 Car of the Year awards. I had a chance to test drive one recently, and can say from firsthand experience that these accolades are well deserved. This isn’t just an amazing electric car; it’s an impressive car that happens to be electric. From an engineering standpoint, it also represents a radical push for innovation. Take a look at this list of some of the patents filed by Tesla since 2008—over 250 active ones related to the development of the Model S alone, and more are still pending.Tesla Model S test drive

The Model S represents as much a paradigm shift in automotive engineering as it does in our collective opinion of EVs. Though most of Tesla’s technological innovations remain invisible to car buyers, there are a few noteworthy components that are readily apparent once you take a test drive. One of the larger issues facing EV manufacturers is what to do with the battery; they’re heavy, and their positioning within the chassis can greatly affect performance. Tesla’s solution to the problem was to create a planar battery pack, and fit it along the bottom of the chassis, lowering the CG moment of the vehicle and increasing handling performance. Moreover, the 416 hp electric motor is capable of generating 443 lb-ft of torque available at any time, for any reason, meaning the car’s acceleration is far superior to an internal combustion engine (ICE). The same torque is available across the entire rpm range of the motor, so it doesn’t matter if you are at a standstill or at 60 mph. Additionally, the car has a  coefficient of drag similar to a Ford GT, and can hit 60 mph in four seconds. I’m a BMW enthusiast, and in my test drive, the Model S ripped through corners and handled an emergency lane change like a sports sedan half its size.

Perhaps even more impressively, the battery – an issue-turned-asset for Tesla – is field replaceable. Owners can swap the base 40 kW-h battery pack for an upgraded 85 kW-h setup if they feel so inclined. The simple fact that this integral and inspired design element is customizable by the consumer represents an impressive degree of engineering on Tesla’s behalf. This is clearly a driver’s car. The interior boasts a 17” touchscreen that allows the operator to extensively modify the driving experience by changing steering modes, regenerative braking, and even an adjustable air suspension that automatically changes ride height depending on conditions.

The next big challenge to be confronted by this new American manufacturer is range anxiety. People remain skeptical of EVs because of their alleged inability to match the driving distances of ICEs. As Tesla begins to design new vehicles with composite frames, continues improving battery technology, and refutes sensationalists in the press (ahem John Broder), the young company will continue to lead the vehicular march towards a cleaner future with a much smaller carbon footprint. Even now, Tesla is developing an EV with a $30k price point to broaden the possibility of ownership to the Prius crowd.

The Model S is a huge step in the right direction. Beyond the landmark strides in tech and engineering, it’s a cool car. The EV stigma disappears in the four seconds it takes to hit freeway speeds. As a result, in the next decade—maybe even the next five years—we may feel the same way about ICEs as we feel now about cathode ray tubes: how quaint.

Darrel Baker

Here’s an interesting article on Engineering Design Challenges from Product Design and Development.

I agree. Controlling costs has risen in importance for our product development customers. Probably a function of the growth of global sourcing solutions.

Engineers in the Stilwell Baker lab

 

Happy New Year!

We are starting 2013 in our new Lake Oswego facility and the engineers are enjoying the lab. It’s a large space, designed specifically for use as a development lab, and best of all, it’s located close to the engineers’ desks.

Two thermal chambers help us quickly identify and fix potential product issues at extreme hot or cold temperatures. The chambers have 7.7 and 12.3 cubic feet internal space, and the computer programmable controllers safely run them in our temperature test range from -60 degree C to +125 degree C (-76 degree F to +260 degree F). We have already detected two design issues at below -20oC that have resulted in design improvements, thereby preventing field failures.

The lab has plenty of standard tools, but my favorite tool is a 16-channel logic analyzer from Salae called Logic 16. The hardware is very small since it acts as a front end for software running on a PC, Mac, or Linux computer connected through USB. The software includes multiple protocol analyzers such as SPI, I2C, and CAN that greatly simplify BUS analysis. It has some limitations (e.g. samples 2 channels at 100MHz, but all 16 channels at only 12.5MHz), but it can capture 10 billion samples and works great for the majority of our designs.

Our work in the lab will help us bring your design to market quickly and efficiently. Be sure to ask for a tour when you visit the office.

Best wishes for the New Year!

Companies undertaking electronic product development for the first time, or those without sufficient resources to complete a project inhouse, often need help that doesn’t permanently increase company overhead. If this is the case with your company, domestic outsourcing is the way to go.

Domestic outsourcing—Benefits of outsourcing without the offshore risks.

  • Shorter delivery time frames for products
  • Better communication
  • No compromise of intellectual property
  • No unforeseen political problems affecting the trading partners

After a company identifies the need for outside product development, screening for the most suitable partner and mitigating risk are vital to producing the device or system that meets company standards. Once the screening is complete, establishing a productive working relationship with your chosen outsourcing partner is crucial for success. Two checklists, researched and created by a colleague in our industry, can help you make good decisions when it’s time to get help. Read more…

 

Company moves to larger facility and extends inhouse lab capability Stilwell Baker Building - Lake Oswego

Lake Oswego, OR – November 29, 2012– Electronic engineering and manufacturing firm, Stilwell Baker Inc., announced the relocation of all business operations to Lake Oswego, Oregon. The company cites an increase in its core product development business as the key driver for the move. With the relocation, the company has upgraded inhouse lab capacity, and now houses all departments in a single facility. Read more…

Brian Terhune

While the term M2M may be new to some, the technology has been an integral though obscure factor in industry for decades. Enabled by the development of smart phones, and the component miniaturization and wireless capabilities that made them possible and affordable, M2M technology has rapidly evolved to generate a far reaching electronic product market. M2M is no longer merely an option in product development; it has morphed into a requirement for a significant percentage of the projects Stilwell Baker undertakes.

An early example (circa 1960) of M2M communication allowed wired systems to communicate with various devices. For example; a SCADA (Supervisory Control And Data Acquisition) system that monitored pressure in industrial facility and alerted a central computer if the pressure was out of limits. With the advent of wireless connectivity, everything changed. One of the main drivers for the evolution of M2M communication has been the significant drop in price of the wireless connectivity, sensors, and processors that are the foundation of all M2M product development.  With this drop in expense, development of M2M devices is now more accessible to an expanded number of organizations and consumers. In a 2012 report, the Economist Intelligence Unit predicted that over 50 billion wireless M2M devices will be connected (globally) by 2020.

M2M wireless networks are emerging in a growing number of industry segments. On-Star is one example of a well-known M2M implementation in the automotive industry. Other implementations include fleet management or asset tracking. When you use your credit card to purchase a product, or time at the parking meter, you are using M2M.

 M2M Applications by Industry M2M Applications
Automotive Passenger vehicle anti-theft/recovery, monitoring/ maintenance, safety/control, entertainment
Transportation Fleet management, trucking, courier, asset tracking, telematics, manufacturing and logistics
Utilities/Energy Smart grid, meter reading, electric/powerline, gas/oil pipelines and water tank monitoring
Security Commercial and home, fire, police, medical alert, surveillance and burglar alarm monitoring
Financial/Retail Point of sale, ATM, kiosk, vending, lottery, digital signage and handheld terminals
Health Care Medical monitoring, remote diagnostics, medication reminders and tele-medicine
Public Safety Highway, bridge, traffic management, homeland security, police, fire and emergency service
Source: Heavy Reading and Pyramid Research, 2012

In our experience,  M2M system development  and managing integration with the infrastructure required to support it is as stimulating as it is challenging. Each sensor or remote device must be integrated with a wireless module and connected to a network. Usually this means integrating the device for use with a Mobile Network Operator (MNO) such as Verizon, or AT&T for example. Module selection is also dependent on whether or not the MNO will allow the device to operate on their network. The module has to pass certification testing (in addition to PTCRB & FCC certification) that confirms it will operate as intended on the respective network. Device and network security must be incorporated into the end-to-end solution to protect the M2M implementation. Custom software applications to link the remote device to the central server of the business may also be necessary.

Before long, many of us could be residing in the realization of Bill’s dream — smart homes — thanks to the evolution of M2M technology.

Darrel Baker

As noted in my last post, the trend to re-shore manufacturing in the U.S. seems to be growing, so early this summer the Stilwell Baker team created a survey to learn more about companies that engineer, design, and manufacture electronic products. Within the limits of the survey, the Stilwell Baker – Electronic Product Design and Manufacturing Survey Results validated the current buzz on the importance of U.S. manufacturing to American companies.

The respondents to the survey were a fair representation of market segments within our current customer base, with Technology as the most prominent industry segment, followed by Consumer Goods, Aerospace, and Industrial Goods. Less represented, though important to the reasoning in our analysis, were Government/Military, Automotive, Medical Device, Utilities, and Oil and Gas market segments.

Nearly 63% of respondents stated that it was important or crucial to their companies that electronic products were designed and manufactured in the United States, and this supports the argument that the advantages of off-shore design and manufacturing are significantly eroding. The location of the market a company serves is much more likely to be the key driver for cost-effective manufacturing going forward. It’s a welcome trend for companies like Stilwell Baker, which have a standing commitment to U.S. production.

At Stilwell Baker, we see evidence that re-shoring is gaining momentum. Companies are approaching us for redesign of electronic products that they originally outsourced to Asian suppliers—products fraught with problems. Consequently, our clients are much more responsive to end-to-end design and manufacturing in the United States than they have been in the last 10 years.

We’re hearing about the risks OEMs are no longer willing to take: loss of intellectual property rights, poor communication that leads to program delays, and the business implications of quality and reliability issues in finished electronic products. The explanations we’re getting are similar to those identified in MIT lecturer David Meeker’s 2011 cautionary case study, “Outsourcing to China” where he sites corporate underestimation of 6 risks specifically associated with outsourcing manufacturing to China.

But outsourcing doesn’t have to be a dirty word. In our survey, 62% of respondents said their companies outsourced activities in electronic product development and manufacturing, and 92% were at least partially satisfied with the results. This group also reported that outsourcing electronic and mechanical engineering as well as circuit design, firmware development, and prototyping by their companies overwhelmingly takes place in the U.S., although printed circuit board fabrication, assembly, and are frequently sourced overseas. And although Meeker’s case study reported 84% of global printed circuit board production (fabrication) was sourced in Asia as of Nov. 2011, respondents to our survey reported that printed circuit board fabrication and assembly in China and Taiwan totaled 46%, and another 46% in the United States.

 Countries where Electronic Product Design & Mfg. are completed by companies that outsource. Stilwell Baker Survey, 2012.

Activity United States Canada Mexico China Taiwan India Other
Product Requirements & Specifications 75.0% 0.0% 0.0% 0.0% 4.2% 4.2% 16.7%
Electronic Engineering, Circuit & Firmware Design 69.6% 0.0% 0.0% 13.0% 8.7% 13.0% 21.7%
Mechanical Engineering & Part Design 73.9% 0.0% 0.0% 13.0% 8.7% 13.0% 21.7%
Industrial Design 77.3% 0.0% 0.0% 4.5% 4.5% 4.5% 18.2%
Mechanical Parts Fabrication 47.6% 0.0% 0.0% 42.9% 9.5% 4.8% 19.0%
Printed Circuit Board Fabrication & Assembly 45.8% 0.0% 0.0% 33.3% 12.5% 4.2% 29.2%
Prototyping 65.2% 0.0% 0.0% 17.4% 4.3% 4.3% 21.7%
Testing 69.6% 4.3% 0.0% 17.4% 4.3% 8.7% 26.1%
Product Manufacturing and/or Assembly 50.0% 0.0% 4.5% 40.9% 9.1% 4.5% 27.3%

 

Additionally, David Simchi-Levi, an engineering professor at MIT, surveyed 105 companies in 2012 and reported that 39% of U.S. manufacturers were contemplating moving some manufacturing back to the U.S; however, he also noted that only 14% of these companies were taking action to do so. Our survey didn’t directly address re-shoring, but instead gave us a benchmark of where electronic products are currently being produced, and whether or not the work is being completed inhouse. The two surveys are related, but drawing a correlation between them would be problematic because of differences in the samples.

Based on the results of our survey, and the evidence mentioned above, it appears that companies are taking a second look at developing and manufacturing electronic products within the United States. Going overseas doesn’t have the appeal that it once had because the rewards aren’t being realized in relation to the inherent risks. American companies are becoming more sophisticated in their analysis of the results of off-shoring and find them, in many cases, disappointing. Although companies in our industry may not be re-shoring in droves, executives are thinking twice before automatically pushing production to China, and that’s a change I’m glad we’re a part of.