Offshoring and Legal: Lessons From the 787 Mess
Two stories converge today:
- The ongoing discussion about offshoring (and outsourcing) in Legal
- The grounding of Boeing’s new 787 airplanes in the US and Japan
I want to be specific about the word “offshoring.” For our purposes, let’s define it thus:
Knowledge and/or professional work for a US or Canadian company performed outside the US or Canada.1
Note that offshoring is not the same as outsourcing. I want to consider offshoring specifically, not outsourcing today.
For years, the legal world has been discussing the offshoring of legal work, often focusing on e-discovery. Is it a good idea?
|Cost||Hard to manage|
|Turnaround time on large projects||Difficult or below-standard quality control|
|Cultural differences may lead to different results|
|Risks from a different legal system, such as acceptance of work product, privilege, confidentiality, etc.|
The question has been, do the pros outweigh the cons?
I think the better question is, do we know how to properly evaluate the pros?
There is enormous “excess capacity” in the system today in the US at least. (The problem isn’t as severe in Canada.) Large numbers of well trained lawyers are working down-market jobs. Those who would have once worked at an AmLaw 10 firm are working for AmLaw 100 firms. Those who would once have cracked the AmLaw 100 are working for firms in the AmLaw 200 and beyond. Others are working for three- and four-attorney local firms, or picking up freelance work, or staffing various Jacoby & Meyers-type firms, or asking, Would you like fries with that? These are by and large smart, capable attorneys, on average as smart and capable as those available offshore.2
Indeed, many of them have moved down-market not because they can’t find jobs at 1000-lawyer firms in NY or LA or DC but because they want to live in Phoenix, AZ, or Menominee, MI, or Lopez Island, WA and work 2000 real hours instead of 2000 billable hours (= 2500+ real hours) a year. I worked 2500-3000 real hours each year for over 25 years, and after a time it stopped being fun.
There are e-discovery firms (e.g., Riley Carlock, based in Phoenix) that offer the capacity to ramp up large projects effectively overnight, and can do so with effective Legal Project Management to boot. I don’t think the turnaround/capacity issue works anymore in favor of offshoring; it’s a wash.
So what about cost?
Here’s where the Boeing articles are instructive. Forbes has a piece from management theorist and consultant Steve Denning that outlines some of Boeing’s issues (it misses some big ones that would make his case even stronger). I urge you to read it and consider the questions he raises about total costs, including management costs and risk premiums. Charles Fishman in The Atlantic writes about the insourcing boom, offering similar reasons for rethinking offshoring. (He misstates insourcing as the opposite of offshoring, which it isn’t by almost any definition, but his examples are valid nonetheless.)
Some Notes From My Own Experience
At Microsoft, I was involved with offshoring some major projects and one complete product. The case at Microsoft is a bit different, since it is a multinational company, and some of this work was going to Microsoft itself in other countries. Nevertheless, by the end of my time there, I had become unsold on most of the offshoring work I was involved with. Overall costs were much higher than anticipated, quality was lower, and the management time that got sucked up into the black hole of communications difficulties and travel was irreplaceable.
What worked well? Moving some tech support worked fairly well, not just because there were smart engineers who were in a sense overqualified doing this support, but because of the follow-the-sun aspects; their night was our day. A certain amount of software testing also worked well, for the same reason; engineers would build something during the day and have test results on their desks the next morning. In both these cases we took advantage of the distance – specifically, of diurnal rhythms and the sun shining in Asia while it was dark in Seattle.
The fully offshored product was a 50/50 result. In retrospect, I think we’d have been able to get the new versions done in the US in about the same time and for about the same overall cost. That said, because it was a full product, we were able to attract some top engineers who, if based in Seattle, might have been more tempted to work on the next higher-profile version of Windows or Office instead.
The projects sent offshore for development were invariably late. They were over budget. They didn’t meet user needs when they were delivered, because the engineering team couldn’t interact with the users. (It was occasionally like pulling teeth to get the engineers and users together for US-based projects, but I spent a lot of political capital – and made a few enemies – insisting on it. The problems came not from the engineers or the users but from their managers, who didn’t see the value. There were a lot of super-smart people working on these projects, but my supply of mind-readers was limited.) I suspect if I looked at enough projects I could pull up a success or two, or at least a no-worse-than scenario, but by and large, there were too many non-successes. Okay, failures (late, over budget, under-featured). I’ll say it.
I know smart people may disagree. (Ron Friedmann probably will, for example.) That’s fine. I think we need, more than anything, to get a real discussion going on this topic.