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.

Customer satisfaction in Outsourcing

Two articles came across my inbox this morning that caught my eye, because we've been thinking a lot lately at Macadamian about how to bring customer service to the next level.

The first was an article about how recent polls show that customer satisfaction in outsourcing has decreased (ouch).

The second was a white paper from Tholons titled "Relationships at the Core of Successful Outsourcing Contracts".

Both cite that roughly 70% of organizations are dissatisfied with their outsourcers. The Tholons white paper highlights something interesting though - around 80% of respondents in their study beleived their outsourcing provider were meeting their contractual committments. Huh? How can you be meeting your obligations yet still have an unsatisfied customer?

Therein lies the kicker - the big secret that's sure to raise the hackles of anyone in legal - in a successful outsourcing deal, the contract doesn't mean squat. It's all about the relationship. Case in point: last year I put a panel together of VPs of R&D in Boston to discuss outsourcing best practices, and the panel agreed - if you get to a point in the project where both parties are pulling out the contract and arguing about what's written and what the obligations are, you my friend are in deep doo doo.

Contracts focus on meeting service levels and specific deliverables - or as the Tholons paper puts it "a fixed unit of utility at a fixed unit price for a fixed time period". If this were taken literally, quality takes a back seat. In reality, the customer expects flexibility when priorities shift mid-project, expects the outsourced team to treat the product as if it were their own, and expects continuous improvement. Often, especially in a fixed-price project, the contract is at odds with these goals.

The survey from the Outsourcing Center, cited in the Tholons paper, sums it up well - in the reasons for outsourcing relationships to fail, the majority is attributed to unclear expectations, poor communication, poor governance, and misaligned interests. Poor performance accounts for a small fraction.

In my own experience, the best projects I've worked had a clear and open line of communication between the outsourcer and the customer. Both show give and take and both feel comfortable picking up the phone at any time to tackle an issue head-on. Conversely, projects that didn't go well boil down to a misunderstanding or a gap in expectations. Sometimes, in a new relationship, people are reluctant to ask the tough questions up front. Either you don't want to ruffle feathers so soon or you're in a rush to get started. Often a frank conversation up front about what everyone expects of one another, how we will judge the project a success, and what makes it a win-win for both parties will save a lot of headache down the road... especially near release-time, when anyone who's worked in product devleopment knows, this is not the time you want to be having a conversation about misunderstandings and mismatched expectations.

On the subtle differences

My second blog post and I'm already off-topic.

Since moving to California from Ottawa, I'm slowly adapting to the subtle differences in the culture in which I'm now immersed - back bacon is Canadian bacon (or sometimes just "ham" - I haven't figured out if there's a difference but it all tastes good with pineapple on a pizza), a bathroom is a washroom (or is it the other way around?), and I now conduct my financial affairs in plain view in the bank (quite the opposite of Canada, where your bank manager leads you down a hushed narrow hallway to her office and locks the door behind you).

But the part I'm enjoying the most, and having to adjust to at the same time, is... it's OK to be frank. Especially in business.

This morning I was in LA at the Growth Capital Conference. Question period rolled around, and naturally, the moderator asked people to be brief.

In Ottawa, this means the audience member who gains control of the microphone has full licence to monopolize the next 10 minutes of the 300 other people in the audience by a) blathering on about their business - "Hi, my name is so-and-so and we're a leading provider of blah-blah to to Fortune 10000 companies" b) compliment the panel and c) pontificate at length about their views of the subject, before d) making a veiled attempt at a question that is really another comment.

And everyone listens politely and doesn't interrupt because that's what good Canadians do. We're so darn nice.

This morning however, you were strictly prohibited from touching the microphone, so that it could be yanked away should your lips start flipping off-topic. A few people were brave enough to start their question with "My name is X from company Y" before the moderator blurted "Could you get to the question PLEASE?"

If you're from Canada you're probably thinking "How rude!". Maybe... but it was certainly more respectful of my time. In the end, the Q&A was one of the most informative, insightful, and productive I've ever attended. And we got out on time.