How to choose an outsourcing partner

One of my favorite questions in our Outsourcing R&D event was around how engineering leaders go about finding and choosing an outsourcing partner. The answers revealed some best practices, and also confirmed some anecdotes from my own one-on-one conversations with VPs of Engineering

In terms of finding a partner in the first place, first and foremost, companies tend to look to partners with whom they've worked with in the past. Sounds obvious, right? It's worth mentioning because sometimes we get caught up in the need for change; we forget how much we invested with our current partner in learning how to work together, and how much they've invested in gaining domain knowledge about your business. It's often much more efficient to work through whatever issues you're having with your current partners than to change horses.

Second, the panel advised you ask your network, both internally (have other groups used outsourcing successfully) and externally.

Finally, if you need to resort to Google for finding potential partners, take the time to do reference checks. Ask for references from companies of a similar size as your own, and ideally, in your home town, so you can get a sense for how they treat companies of your size, and how they work with companies in your region (how responsive are they, are time zones an issue, do they have someone "on-the-ground" and so on)

In terms of choosing the right partner, the panel had a number of good tips and tricks:

• avoid hot spots like Bangalore, where it is becoming increasingly difficult and expensive to find and retain engineering talent
• conversely, make sure your partner is in a region with good infrastructure - first-mover advantage in a remote location comes with high-infrastructure costs. When working with a partner, you don't want to be paying for basic infrastructure (PCs, Windows licenses, broadband, etc)
• use a local agency or consulting firm to help narrow down the field of choices
• match your partner with your company size; if you're a startup, or a small group within a large company, work with a relatively small (around 200 or fewer people) partner, where you can still have the attention of their senior management

Another tip I'll share from a similar panel discussion I organized in Boston - the RFP process is your surrogate for the actual experience of working with that vendor. How the potential partner behaves in the proposal and sales process is a good indicator, or at least the best you have, of what they'll be like to work with. Here are some tips for using the proposal process to pick the right partner:

• If you're not a Big Design Up Front (BDUF) company, don't do a BDUF request for proposal. Leave out some details on the project, so that you see if your potential partner can read between the lines, and if they ask the right questions. The quality of their questions is a great indicator of their domain knowledge and experience
• Do your own estimates, so that you have an idea of how much the project should cost and how long it will take, however, bear in mind that most studies show an outsourced partner, at least for the first project, will be anywhere from 50% to 80% as productive as your internal team.
• This one's tricky, and since I work for an outsourcing company, I have trouble advocating trying to trick your partner, but one tactic is to put an unrealistic deadline in the RFP and see how your potential partner reacts. If they come back with a proposal that meets the date, barring some miracle time-saving device, you should question their estimates.
• Beware of proposals that either have too little detail, or an unrealistic level of detail given the information you've provided.
• Finally, how responsive were they during the proposal process? Were communications open? And did they meet the proposal deadlines?

Hopefully these tips can help take some of the anxiety out of choosing your next partner, or at least help make for a more predictable outcome.

Deciding what is core

This post continues my report on our R&D outsourcing event in Ottawa. The next question asked by the moderator was "What can be outsourced, and what not?" The question triggered a sidebar on one of my favorite topics - what is core to your business, and what is not.

The panel had great answers to help guide you in deciding if something is core:

• If it's something that you can articulate as a difference between you and your competitors, it is definitely core.
• If it's something that needs to have very high quality, or will be consumed in high volumes, it is core

I find the first rule to be the most useful - it's simple and bullet proof. Every business has something they concentrate 80% of their effort on improving, and something they do better than their competition. It may be a technology - for Google, it is their relevance engine; for a gaming company, it might be their 3D engine. In the case of the gaming company, they definitely don't want to outsource the design and engineering of their 3D engine. But, they could easily outsource all the context pieces: the software that lets users build levels in the game or customize the characters, the portal that links the community of players together, the network engine that enables multiplayer play, the VoIP software that lets players communicate by voice while they play, and the e-commerce engine that bills people for connecting to the gaming network. These pieces are all important - you can't release without them, and some of them are very complex, but they are context - you need them to be as good as the competition, but focusing your internal resources on making these pieces better than your competition is not what's going to propel you to the top of your market.

Generally speaking, I find it harder for ISVs to articulate what is core and context, and decide what pieces of product development could be outsourced. For a telecommunications company, or a medical device company, the lines are clearer - the package design could be outsourced, the software is context so we can outsource that. It could be because ISVs tend to have technical founders, and some see outsourcing in R&D as a failure of their engineering team. In other knowledge-instensive industries however, like pharma, telecommunications, and consumer electronics, over 90% of companies use outside firms in R&D, and rely on a supply-chain of co-developers and outsourcers to develop products. In software, at last count (2006) about 30% of ISVs leverage 3rd party capabilities in product development. But this is changing, at about 10% a year, and I have no doubt it will catch up as the industry gets more and more competitive. I'm even starting to see a few isolated cases of software companies that have decided that marketing and product design will be their core competency, and who outsource the entire product function end-to-end, but this is rare.

One of the key takeaways from the panel is you need to know what is core, and what is not, and that your outsourcing strategy has to tie in directly into your product strategy.

Next post I'll wrap up with my notes from our R&D Outsourcing panel, and reveal how technology executives go about choosing an outsourcing partner.

Why Not Outsource? The Burning Questions Continue

This is my second post related to the "Outsource Product Development" roundtable we hosted in Ottawa this month.

After we asked the panel "why outsource?" we asked them "why not outsource"? The panel was comprised of companies of outsourcing beleivers, people who were actively leveraging outsourcing in R&D, so this question gives us an idea of what experienced managers see as the risks and potential pitfalls:

• It could have an impact on your own team - you have to be careful which parts of the product you outsource. Another panelist noted that this risk can be mitigated if you make it a point to integrate the in-house and outsourced team
• The risk of failure, and the costs of failure. Contrary to what some beleive, it's simply more difficult to manage an outsourced project. It requires at least as much follow up, if not more, than an inhouse project.
• It's difficult to forsee the hidden costs, such as management overhead, or the cost of bringing the product back in-house to be maintained once it has been developed.

The next question, what should you not outsource, spawned a good discussion about what is core and what is not core, which I'll cover in my next post.

Why Outsource? And Other Burning Questions Answered

Earlier this week we teamed up with Fidus and OCRI to host "Outsourcing Product Development, How to Minimize Risk and Maximize Rewards". I couldn't make it back to Ottawa for the event, but my esteemed colleague Francis took great notes. The roundtable consisted of engineering executives from Alcatel, Teradyne, Liquid Machines, and MXI. All have been directly involved with outsourcing in R&D.

In my next few blog posts I'll report on some of the questions asked by moderator Jim Roche, starting with my favorite:

Why outsource?

• To augment capacity, and deal with peaks and valleys.
• To reduce costs, and blend the cost of outsourced resources with your internal resources
• And the answer I liked best: Tap new ideas, inject new blood and innovation, and challenge your own practices.

The last answer was from one of the companies with the most outsourcing experience. To me, that answer indicates you've reached Outsourcing Nirvana, or the highest level of maturity in outsourcing. You're looking beyond the bottom-line cost savings and asking yourself "How can I use outsourcing to increase my top line? How can I use my partners to create better products?"

Another good answer came from a panel I organized in Waltham, MA: to let us do things we wouldn't otherwise be able to do. In other words, the panelist looked at outsourcing as a way to free his team to do tackle opportunities rather than being reactive.

Coming up: Why not outsource? What is "outsourceable" and what is not?" Stay tuned.

Here's to the next 10 years!

This month Macadamian celebrates it's 10th year in business. A major milestone makes me retrospective, and I can't help looking back to see how far we've come.

We founded the company in the midst of the bubble, when incredible amounts of money were being thrown at every crazy idea under the sun. When I joined, we were 8 people working out of a bare-bones industrial complex. I think that's one of things that attracted me most - it felt like a startup, in the positive sense. The founding team was passionate about what they were doing, and my interview was a very lengthy and serious affair, in stark contrast to other interviews I was having ("Pulse? Breathing? Good - expect an offer from us tomorrow"). I'm proud to say that a stringent hiring process is a value we've kept to this day. Like any decent startup, we wore a lot of hats. I was hired as the Web Developer/IT guy/Network admin/QA. One day I was building a Linux firewall (which I'm proud to say ran without incident for 5 years) and the next day writing a test plan.

We grew to 40, scaled back in the bust, and hunkered down. It wasn't the most fun time. Actually, it wasn't fun at all, but I think it matured us. Those two years were like a crash-course in business. Competition was intense and opportunity was scarce. It forced us to focus, and more importantly articulate why we're different.

In 2003, the R&D tap turned back on and since then we've grown to 130, added user experience design as a key capability, opened labs in Eastern Europe, and set up an office in California. We're doing less team-extension far more end-to-end projects, where we're being asked to help flesh out requirements, design the product, build it, test it, and deliver. We're still in the same industrial complex, but with much nicer furniture and paint on the walls. And I now wear two hats - a 50% reduction in hat swapping, which is a good sign we're growing.

What a ride! Here's to the next 10 years.

Palm dumps its hyped-up Foleo

I'm sure everyone will be blogging today about what Palm did wrong, that they saw it coming, etc. etc. etc.

What I found interesting about this news is that it highlighted how much it costs to build a flop. Palm is taking a $10M hit. Obviously, they believe that's only a fraction of the cost of actually releasing the product, which is why they are canning, or at least delaying the launch. The information they have, their gut, or both, is telling them the product won't be a success as-is.

We've been talking a lot about this lately at Macadamian, and our CEO Fred has written about it in his blog (so as usual, I'm taking his idea, rewording it, and passing it off as my own; what is it they say about imitation and flattery?).

Actually, it's more than talk- we're gearing our business model to help companies improve their batting average at product innovation. That's why we acquired Maskery, and why we're working hard at integrating the two teams and building an end-to-end method for creating software products. Macadamian has always been good at building products - helping people get good quality products to market faster and more reliably. What the Maskery team is bringing to the table is experience in helping a client make that product more successful commercially. How? In a nutshell, they know how to talk to users, and what questions to ask. And not "would you buy this product" questions; their strength is in things like user research and rapid prototyping - finding out early what aspects of the design will be an impedement to adoption and what will stop people from trading their hard earned cash for the product, before you spend $10M on development.

Think about it. In the past few years R&D teams have been outsourcing what they can to places like India. Most of the data says that, over time, you will acheive a 20% cost savings. Significant? Yes. Do you need to do it to be competitive? Absolutely. Macadamian has labs all over the world, and we'll continue to keep opening new ones in new locations as we scale. But lets suppose that, as an R&D manager, you are seeing a 20% cost savings through your outsourcing. How much more effort will it be to save 21%? It's more likely that next year, you will save only 19%, because of attrition and rising labor costs overseas. After a while, trying to squeeze out another 1% is diminishing returns.

At Macadamian we decided to change the game. What if you could cut another 20% to 30% of your product R&D budget? Think about it - if you are really really good, a few of your products exceed market expectations, most meet them, and some are total flops. What if you could cut your loss on your Edsels sooner - at the idea phase, rather than just before release when you've spent 10M greenbacks? Or what if you could improve your success rate, so that a greater percentage of your products met or exceeded their market expectations?

My favorite example is our collaboration with Imasight, who engaged Macadamian to build the software and design the interface of their medical imaging product. By visiting target end-users, and by going through our user-centered design process, we uncovered things like the fact the early prototype was difficult to use in a lab environment, because the buttons were to small and tightly spaced to be used with medical gloves. We went through a few iterations and redesigns early on, and now the product is out to market, and getting rave reviews from early customers. What if we had skipped that step, dove headlong into engineering, and released a design like the early prototype? Would anyone have bought it? Perhaps, but I can guarantee they wouldn't be bragging to their colleagues about it.

So did Palm do something wrong? Beats me. I wasn't in their boardroom, nor do I know anyone on the design team. I can tell you that you can avoid the same fate.

Designing for people with disabilities isn't a "special case"

I was sitting on the shuttle bus at San Jose airport the other day, and I looked across to see the wheelchair seating. What I saw truly floored me.

Nestled in the complex array of straps, hooks, and tiedowns was a sign that outlined the 14 steps (in paragraph form, no less) to securing a wheelchair on the bus.

Just reading and interpreting the instructions took me roughly 5 minutes. I'd say that strapping in a wheelchair is probably a 10 minute exercise, and that's after you've negotiated the wheelchair inside the bus in the first place, which would be no small feat. 15-20 minutes is an eternity for a shuttle bus that leaves every 5 minutes and makes a 10 minute roundtrip.

It was clear that they retrofitted the design of the bus to accomodate people in wheelchairs, but like any time design for people with disabilities is treated as a special case or afterthought, the designers failed miserably.

There are only a few things that stick out from engineering school (obviously money well spent), but I had a great course on design and human interaction. One thing that has always stuck with me is that, as an engineer or designer, if you consider how someone with a disability is going to use your product upfront, all users will benefit.

Quiz: Which is easier to navigate for someone pushing a stroller: an escalator or an elevator? Stairs or ramps? Which is easier to use for people with arthritis: those stupid, stiff, round sink taps that turn off when you let go, so that you have to try to hold with one hand while you rinse the other, or taps with long handles for leverage? Know anyone who has kids and has pushed a stroller? How many people have arthritis? Are they a special design case?

Back to the bus - it's also cramped, narrow, and high, so it's egress is difficult for anyone with luggage, especially the elderly. Do you think there might be people with luggage on an airport bus?

How does this translate to software design?

Using low-contrast between labels and buttons, or controls and background, like the trend to "metalize" a UI, may look hip, but it makes it much harder for people with even the slightest visual impairment to use. For example, I'm red-green color blind, which is a very mild color-blindness - in a nutshell, colors don't have quite as vivid contrast for me. When someone uses dark blue against black, the interface is almost impossible for me to use. Careful use of high-contrast makes it easier for everyone, but especially those with vision problems (know anyone who wears glasses?)

Another example in web design - using ALT labels correctly in images makes it possible for screenreaders to tell a blind user what the image represents, but it also makes it easier for the rest of us to know what the image will be while it loads, or search engines to index the page.

So, like me, if you take one thing away from this post, when you design a product, whether it be hardware or software, think about how someone who isn't quite as able bodied as you will use it, and you'll make it easier on all of us.