There has been an enormous amount of hype an blather about ‘wikinomis’, using IT to take outsourcing to its logical extreme—enterprises that do nothing except manage their IP (intellectual property). It’s great work if you can get it, of course, though not so great for the actual workers, who get nothing but piecework out of the deal.
I know a bit about this area, from both the technical angle (I worked for many years in distributed computing) and social. But I’ll state here that I’m not an expert.
One of the most famous (or notorious) tub thumpers is Donald Tapscott, with his influentiona book Wikinomics: How Mass Collaboration Changes Everything (Tapscott, D., & Williams, A. D., Penguin, 2006) and subsequent writings (http://www.wikinomics.com/blog/). There are many people talking about this in various permutations, but let’s let Tapscott stand for the general movement. This is not totally fair, but he’s made himself the poster guy, so I don’t think its unjust.
The basic concept is to apply a ‘wiki’-like philosophy to all enterprises (Tapscott gets to educational enterprises in a later book).
Methodologically, this is working from a few cases, claiming big success, and arguing that the principles should be applied (partly by analogy) to everything.
So, for example, industrial production should be accomplished by the owner of the IP issuing detailed specifications for not only parts but whole subsystems, which will be bid for and fulfilled by anyone in the world. The contractors deliver all the pieces, the owner snaps them together (and, I hope, rigorously tests) the complete product. No more centralized, bureaucratic company, no more integrated factors. Everybody does their own thing optimally, rather that trying to do everything acceptably.
What could be wrong with this picture?
Let’s start with the notion of specifications. Obviously, many manufacturing industries have a long and successful history of creating specifications for suppliers. Electronic components are almost always purchased this way, specified carefully and delivered by third parties. I note that these cases are also subject to rigorous statistical quality controls to detect deviations from the specification.
However, there are many products and services for which we don’t have the understanding to actually define the requirements. The building industry has a long history of less successful application of this approach. And, of course, the software industry has a long history of catastrophes from many sources, including difficulties in stating and meeting requirements.
Why is there a problem? It is very simple: you have to have an unambigous (i.e., formal mathematical) language to describe the desired product. For some things, we have such languages. For others we don’t. When you don’t have the language, you use English or Chinese or whatever human language you chose (and let’s not forget that wikinomics postulates multilingual coordination—oh, boy, no possible problem there). And basically, you get a lot of negotiation about what is supposed to be created, whether it is “right” or not, and so on. This is a huge challenge for anything non-trivial.
Within a single enterprise, these negotiations are managed by, well, by managers. When you all work for the same company, you have strong incentive to bring these negotiations to a successful conclusion. And you can impose solutions, even if all the parties don’t agree.
In the wikinomics world, it is difficult to conduct these negotiations. Anyone who has dealt with large procurement contracts knows that the parties are highly constrained, especially in how they can negotiate. In particular, the people who know the most (e.g., the engineers, designers, and production workers) are prohibited from talking except via the contract officers.
Distributed productions a la wikinomics brings this problem to the fore, big time. If you strictly follow the model, the only communication between the parties is: the specification, the contract for payment and delivery, and the finished piece. If the specification is ambiguous (or wrong), it essentially requires a renegotiation of the contract—bad news for everybody.
A second big problem with creating specifications is that any complex system requires a lot of integration, so the subsystems not only work, but work together. This is why buildings are difficult to create; even if all the pieces are tried and true, the building wont work until they are put together acceptably.
Let’s move from the conceptual problems to evidence. Bear in mind that the technical infrastructure for this approach has only been widely available outside computer intensive industries for a decade or so, The 2006 book had a handful of examples, none of which are long standing. Since that time, there have been many more examples in one form or another.
The most interesting one is the Boeing Dreamliner project. From the beginning Boeing designed the project to be distributed around the globe, with only design, final assembly, and testing done at Boeing. Everything else was to be done by other companies. This is an amazing project, including, for example, specialized cargo aircraft to fly completed wings from Japan to Seattle.
Tapscott describes and praises this project in 2006, seeing it as an example for all to follow. He was certainly correct to call attention to this effort.
Now that the Dreamliner is in production, we can review the actual project with the hoped for results. As it happened, there were huge problems which resulted in delays and cost overruns. This is not at all unusual for large aircraft projects, so we can’t blame wikinomics for everything. For example, there were parts shortages, tsunamis, and so on—normal stuff.
But the crux of the project was the notion that the parts of the aircraft would be manufactured independently, and Boeing would basically snap them together, and voila, a Dreamliner to test, polish, and sell.
Unfortunately, the pieces didn’t snap together painlessly. Or at all. Boeing ended up having to make some of the assemblies itself.
Without detailed information from the company, it is impossible to diagnose the problems. But, given the known difficulties with the approach, it is easy to imagine what may have happened.
By the way, these problems are not due to stupidity, and it it’s not the case that Boeing shouldn’t have tried this. It’s merely the case that there were failures at exactly the weak points I would have predicted if they asked me.
So what do I think of ‘wikinomics’? Information technology has made possible many new ways to communicate and cooperate, which can be exploited by organizations and enterprises. But not everything works everywhere, so you need to be cautious about claims that IT solutions from, say financial services, will work for another type of work, say teaching. Maybe, maybe not.
Personally, I am deeply concerned about the underlying philosophy of “the enterprise doesn’t make anything”. Somebody has to make things. Trying to run a company that basically only knows how to design and sell products or services, which the actual work is done by someone else seems unsustainable to me. I think many companies are discovering that taking this approach means they end up at the mercy of their contractors. There is a reason vertical integration was invented.
I’ll return to this topic in the future. I need to read what he says about education in his recent book.
Robert McGrath's Blog 