Adventures at Work, Episode 5: Supplier Management and Engineering Outsourcing

When I was at Synapse, I did some consulting work with Nike. Among other projects, Synapse was involved with the Nike+ Fuelband, one of the first cool activity trackers before the proliferation of them that we have now! Although formally there to help with drafting requirements, I also found myself advising them on how to work with contract manufacturers - drafting statements of work, creating requests for proposal, evaluating responses, and so on. I created an instructional outsourcing guide for them, which they (gratifyingly) treated like gold. It turned out that I had more experience with engineering outsourcing and supplier management than anyone else on that team, due to the five years and many projects I did at Harris.

Engineering outsourcing wasn't something I intentionally chose to do. I essentially fell into it in the course of my job, when we had a lot to do and not enough internal engineering staff to do it. To my surprise, I found that despite the inherent challenges, I loved it. When it worked properly, it was a win-win for everyone: our company got a good product for a good price, internal engineering could stay focused on their core competencies, and the supplier's overall engineering and operations processes improved as a result of our collaboration. It felt great to really create lasting value and relationships beyond just delivering a single product.

I'll start with general guidance, then highlight some of my own examples and pull out a list of lessons learned on how to engage with suppliers in a way that sets up a positive and ongoing relationship. I will continue to use the term supplier or contractor here, because as my colleague Bo used to say, vendors sell popcorn. Suppliers don't just sell an existing widget, they bring more to the table in terms of engineering services and manufacturing expertise.

Outsourcing Document Structure

A basic request for proposal (RFP) package consists of a statement of work (SOW), a technical specification, terms and conditions, and a cover letter.

• The SOW includes project timeline, recurring cost target, expected quantities, delivery type (physical goods, file formats, source code), meeting cadence, milestone reviews, payment schedule, incentives and penalties, any pricing lock-in (e.g. starting price guaranteed for the first 12 months), design warranty, bug fixes and post-production support. Expect to receive back from the bidding contractors their own SOWs that usually contest some of your proposed terms and may also include past performance examples, resumes of key personnel, and other "why you should pick us" details. One key requirement we began including, after experiencing a bait-and-switch: if staff have particularly impressed you during the bidding phase, ask for a guarantee of key personnel that includes their names.
• Terms and Conditions contain legal language, licensing, ownership (hardware, software, IP), escrow arrangements (in the event the supplier went out of business during development), and escape clause (process for either company to terminate the arrangement).
• The technical specification includes a high-level description of the product at a sufficient level of detail to allow an accurate quotation, as well as use cases and reference specifications for guidance. It's important not to be overly prescriptive, defining the "what" and not the "how". We usually had a baseline PRD (product requirements document) and asked the supplier to map their more detailed specification against it for compliance purposes.
• The cover letter includes the project overview (what you're trying to achieve), project timeline, RFP timeline (due date for responses, Q&A period, notification that all questions will be shared with all bidders), and a request for a bidding compliance matrix (are they proposing 100% compliance to all specs, or asking for changes in certain areas).

Note that the packages you get back in response will have some of these same documents, many of them boilerplate documents that they send to every customer. As mentioned above, the contractor will usually deliver their own SOW. They almost always have their own T&Cs, and are reluctant to accept others since their own lawyers have written them. Expect a fair amount of back-and-forth wrangling to settle things once you award.

Our typical timeline looked something like this:

The big three items are the non-recurring cost (how much they're charging for the development), the recurring cost (either for physical goods or SW licensing), and schedule. I'll note here that almost all of our contracts were firm-fixed price, where the supplier commits to an overall price just like a housing contractor would, versus time and materials where you pay an hourly rate until the job is complete.

The Team

Our team was comprised of a systems engineer (me), a supplier-specific project manager (Bo), and a contracts manager (Jacki). The three of us got along great and had some amazing times together while getting through a ton of hard work. I managed the technical aspects of our projects, including drafting the technical specs, reviewing RFP responses for accuracy or inconsistencies, running our side of the design reviews, and so on. Jacki worked on the statements of work and all of the contractual documentation and milestones, keeping us on the right side of things legally. Bo handled all of the day-to-day with the supplier, keeping them accountable for meeting their deadlines, scheduling meetings, pulling in additional disciplines when needed (like operations reviews), and often fielding complaints.

This is probably the leanest team possible to handle multiple projects. None of us were solely dedicated to these specific projects, but in reality, managing all of them in addition to the attendant business travel took about 75% of our time for several years.

Team cohesion was critical. We traveled together all the time, sometimes tired and irritable. We often had to pitch in and help each other to get through our volume of work. Bo and Jacki both reviewed my technical documentation for errors, I always read through the SOWs and gave feedback. Nobody ever said "that's not your job"; in a small team, it was important for us to work together on everything.

Evaluation Criteria

Obviously, non-recurring/recurring costs and schedule get the most attention, but those aren't the only factors to consider. What are the supplier's qualifications? Do you have a past relationship with proven history already? If this is your first engagement, have you checked their references? Looked at business financials (e.g. Dun and Bradstreet)? Performed a manufacturing audit? How was the overall quality of their response compared to others? In other words - what's your confidence they can actually do what they say they can do?

I developed a weighted matrix for all of our RFP evaluations. The sections included general criteria (overall response, intangibles), product design characteristics (physical, hardware, software), schedule, supplier qualifications, and life-cycle cost. We met as a team and decided on the weighting in advance. We then reviewed the responses, filled out our evaluations independently, and met again to review and downselect.

As part of our selection process we evaluated a supplier's business practices, engineering practices, manufacturing and logistics (usually with a full on-site audit), then made suggestions and changes that ultimately improved things not just for us, but for all their customers. In essence, they received free consulting services improving their entire company in addition to the awarding of our business, and most thanked us for this later on.

Once you've awarded and had a kickoff meeting, it's down to the day to day management of the supplier - regular meetings, design reviews, and payment milestones, all the way up to final delivery.

Project 1 and 2: Rechargeable Battery and Non-rechargeable Adapter

Lessons: Building a relationship, importance of on-site supervision, the "did you read it" spec

One of our major projects (the specs of which I wrote about in another article here) was developing a new battery. For many reasons, but primarily existing solution cost and being sole sourced, we wanted to develop an additional supplier. The project was fraught with challenges. We spent a lot of time working together to finally achieve a solution we were all happy with in the end. During this process, our teams gained respect and trust for one another.

When it came time to award a related project (an adapter for non-rechargeable batteries), choosing an existing partner we'd invested so much time in made a lot of sense. They had the necessary design and manufacturing skills, and their quote was cost competitive, so we awarded to them. Then the struggles began. The electronics were straightforward enough, but we had a lot of mechanical challenges making an enclosure that could repeatedly open and close, yet remain watertight when immersed and be rugged enough to be dropped. We also had schedule pressure, since customers were already clamoring for this product, and in fact we'd even provided engineering prototypes (at the sales manager's request) to customers for early field testing.

This was a tense time for both of us, as schedule slipped and customers were pressuring us for deliveries. It was fortunate we had our previous experiences to build up an "emotional bank account" while we pushed through our problems. We brought in our own mechanical engineers to help consult and provide design guidance for some of the manufacturing test equipment on the assembly line. I did a line walk myself and helped with the statistical analysis of the immersion testing. During a critical period when we were modifying a PCB to a unique customer spec, I irritated their PM when I insisted on seeing verification data before the unit was couriered to the customer. Guess what? It hadn't, in fact, been modified. If that unit had shipped, we both would have been in a lot of trouble. He thanked me profusely after the fact, which ties back to my original statement - those experiences building up trust with your partners really help when you're working through challenges. It also underscored the importance of regular on-site supervision: even when you don't think you'll be able to contribute, often you'll be surprised at how much you can.

The initial battery experience with the weird specification, in particular, also led to me often putting in an odd or extremely difficult specification. I called this the "did they read it" spec. Suppliers respond to so many RFPs with so much boilerplate documentation, it can be difficult to assess if they even had an engineer look at it, or if they hope to simply capture the business and issue change orders later. By including one area that should trigger concern and questions from the supplier, you build in a check to see how closely they've read and evaluated your documentation. It worked well for me on several occasions.

Project 3: Wireless Remote Control

Lessons: Managing multiple sites with dependencies is challenging, Suppliers will make exactly what you ask for

One of our smaller projects was a wireless remote control, a small device with just a couple of buttons transmitting over a Bluetooth-like link. It was deceptively complicated. We had one company developing the mechanical design, with the complications common to rugged military-grade equipment. We had other companies independently developing and testing the software, and delivering to the manufacturing facility for integration. When delays or issues happened, finger pointing between them was inevitable. We had good reasons at the time for choosing the team we did - one had the mechanical expertise with good past performance and a competitive bid, the others had the software chops - but a single house, or structuring the software firm as a direct sub to hardware vs. reporting through us, would have reduced the amount of handholding required.

When developing the initial specification, we had a general idea of the device size, but no industrial design concepts or visual representations. To give a little guidance, I made a quick mockup myself in SketchUp (a free, simple 3D modeling tool, owned at that time by Google). I should note that I have zero background in industrial design, and my model was the opposite of elegant. We specifically included language that this drawing was only a visual reference, and we expected the suppliers to provide their own industrial designs. Imagine my surprise at our first design review, when the 3D models they brought in for evaluation were exactly the same as what I'd included. In lieu of strong opinions otherwise, we ended up rolling with it and my concept is what ended up shipping. It's probably the one and only time I'll act as a program's industrial designer (thankfully). If I was doing it again, I'd either include nothing other than dimensions and have a face-to-face industrial design kickoff, or include only a line drawing with no detail.

Avoiding overly detailed visualizations in RFPs also applies strongly to bidding out software. Unless you have a strong internal UI/UX team that wants to provide detailed guidance, let your supplier develop the interface elements and provide them to you for feedback. Wireframing tools that show only very basic line drawings, like Balsamiq, can be very helpful in defining the UI elements and a very basic layout. The crude drawings are informative while reducing the possibility of the supplier implementing things exactly as you've drawn them.

Project 4: Map software application

Lessons: Being aware of internal company politics, "insourcing" projects

Working in design outsourcing can create some sensitive situations, politically, within a company. Ideally, there's very little friction. Suppliers are often engaged when they're doing work internal staff don't have the time to do, and/or don't have the skills or equipment to do. When internal staff are already fully utilized, nobody cares that some excess work is taken outside. It's encouraged, since the company can focus on what they're good at, and pay others to do what they're good at to create products that capture even more business. No conflicts.

But what happens when internal staff aren't busy, especially suddenly? If a project gets canceled and a team of engineers is suddenly at loose ends, management immediately goes on the offensive to staff them wherever they can. One day the story is “we don’t have any engineers for your work, find a different method.” The next week it’s “we need something for these people to do, staff them on your project - now." Explaining that firmware engineers aren't the same as Android UI engineers, while true, will not endear you to anyone. You are now perceived as the bad guy, putting your coworker's jobs at risk to give work away to other companies.

We were asked on several specific occasions (and for various reasons) to speak with internal teams about working on our projects. It's a difficult position to be in. Your project is usually of the lowest priority to them - if anything else comes up internally, particularly if it's longer term, you'll be dropped without the contractual recourses you'd have with an external firm. Design reviews and deliverables are more open-ended, since they're not tied to payment milestones. And since there's no firm-fixed price commitment, budgets can balloon if projects drag out.

In an effort to be fair and accommodating to business needs, we chose to do what we called "insourcing". When requested, I delivered our RFP packages to an internal engineering manager, asking them to review it and deliver a quotation back to me, just like an external supplier would (minus the contractual docs). If there was a business need, we were never opposed to choosing our internal teams, but it gave us a point of comparison.

In one case, we'd already awarded a large contract to a supplier, and were asked to carve out some work for an internal team that was suddenly at loose ends. One of the deliverables they expressed interest in was a simple software application that displayed GPS coordinates in a basic mapping UI. We asked the supplier if we could make a change order to excise the work from the contract, and how much of a cost reduction it would give us. At the same time, I asked our internal engineering manager to give me a basic quotation for the project. Our supplier gave us a contract reduction of $13k, and the internal quote came back at more than 10x that figure. Despite that, the internal team got the work - and management was happy. Takeaway: Don't risk your job, or the jobs of others, to outsource. Go with the flow and make contingency plans in the event things fall through.

Project 5: Charger

I've written in another article about one of our battery charger projects. We completed it and shipped it, but one customer complained about charge time, and we realized by approaching the problem a bit differently we could improve the overall customer experience. The lesson here was twofold: one, being adaptable to customer needs and feedback after shipment is critical. Two, with a good relationship with the supplier (as well as a good SOW for support tasks), simple changes shouldn't cost an arm and a leg. It was in all of our best interests to make this simple firmware change, and the supplier didn't gouge us for it.

Project 6: Large radio project

We spent over three years managing, with a few others, the largest outsourced development the company had ever done, working closely with a design firm in a different country five hours ahead of our time zone.

I could spend hours talking about this one, but here are some of the key takeaways:

• Face to face meetings are important to maintain team cohesion. We set a minimum of a week a month, and traded off which site was traveling.
• Good videoconferencing is important. Webcams don't cut it, especially for important meetings where you need to "read the room", see people's reactions to statements, and so on. For several meetings, despite having specific videoconferencing rooms at our company, we actually booked outside facilities with professional camera setups (due to much better quality, better pan/zoom capability, and better availability for long meetings).
• The ability to whiteboard was important for us, especially during the early ideation/industrial design phases and at design reviews. We found it easier to use physical whiteboards in the room and simply zoom in on them, versus virtual whiteboards which tended to break the flow.
• Respect the culture of the supplier. We Americans were very accustomed to working through lunches, and this visibly stressed out our partners, who hated this practice. I began to offer to take them on a brief walk out of our secure building after lunch, they very much appreciated it. We likewise took much less time off in the summers, and had to work with them to balance staffing during these times.

Lessons Learned Summary

Without a doubt, my biggest takeaway from years of doing outsourced development is that the end result should be a mutual benefit to both parties. The business terms should be mutually advantageous. The execution teams should build mutual respect and trust with one another, and can carry that forward into future awards. The supplier should derive an overall improvement to their entire business that carries forward well past a single program.

Beyond typical RFP work, which I've touched upon, some specific lessons I learned were:

• Ensure purchasing and sales have a say up front while generating your proposal. They may wish to include special terms (like a 12 month pricing lock) or plan to shift business away from a poorly performing supplier, affecting future quantities and manufacturing capacity
• Consider asking for key staff in writing, to avoid being dazzled by a PhD and assigned an intern
• Don't write overly prescriptive specifications, give the supplier room to innovate while implementing
• Host industrial design kickoffs for physical products (UI/UX kickoffs for software), and never provide more than a rough wireframe line drawing unless you want a supplier to mimic exactly what you've given them
• Consider having a very challenging requirement that suppliers should question or push back on if they've actually read the document
• Have a Q&A period, and send the consolidated list to every supplier before they issue an RFP response
• Don't let cost and schedule overly dictate your choice, carefully weigh all the criteria before awarding
• Have clearly defined roles and responsibilities for the internal team, but allow everyone to contribute
• Build the supplier relationship. Meet face to face regularly. Videoconference often. Be responsive to questions, scheduling meetings, issues, etc. Process change orders when scope changes happen. Supervise onsite in problem periods.
• If two suppliers have dependencies, consider structuring them as a prime/subcontractor relationship instead of managing both independently yourself. This preserves accountability and eliminates you as a bottleneck.
• Maintain awareness of internal company challenges and be ready to pull work internally if required.
• Follow customer feedback after shipment and follow up with bug fixes or modifications as necessary.

Conclusion

I know many people in Big Tech think of a Global Supply Manager job as "yell at the vendors until they reduce their price". At some companies, it does trend more in that direction. In my experience, however, Supplier Management (as part of design engineering outsourcing) was actually a highly rewarding area to work in. It required soft skills, team building, technical chops, negotiation, travel, and the end result was usually a true partnership, where both sides benefited.