Chapter 9 – Outsourcing
Since I have complained about the writing on a couple other chapters, I think I should begin by complimenting the authors on this chapter. I was especially pleased to see the history they present. The concept of getting resources from outside is not new to IT. Some variation has been around for thirty years. And each year there are more options available as we face “make or buy” decisions.
In IT we could argue that “buy” has now become the standard decision. Should we have IT people training new employees in Word and Eudora, or just bring in a consultant trainer twice a month? Should we write a new inventory system, or buy an ERP? Do we want to repair our desktop machines, or put a local store on contract for service? The great majority of businesses now take the “buy” option in each case.
What is new (and well-illustrated by the XEROX case) is how deep some companies will go. This is a new development and one that the chapter examines from many perspectives. You can argue that outsourcing is necessary because outsourcers can do the job better and cheaper. You can argue that outsourcing is necessary because the current IT crowd is a mess. The chapter has a comprehensive list of all the reasons given. It also has a couple additional perspectives I like:
Who should outsource? The chapter makes some critical points here because it is clear not every company should outsource IT. Their grid on page 570 could be expanded, but it establishes the key concept – outsourcing makes more sense for some businesses than for others. If you are stable, and get little competitive advantage from IT, it makes sense to look at such an arrangement.
What can you outsource? Project risk is a major theme in the next chapter of the book, but some of the key points are relevant here. The grid below describes IT projects a company might be considering. “Structure” refers to the stability of the system we are designing. Payroll, for instance, is a business function with clearly defined goals and processes, so it would be called highly structured. E-commerce is still an emerging activity with few rules, and would be called “low structure” in this grid.
High Structure – Low Tech
High Structure – High Tech
We know going in what the system will do (it is often a simple conversion of an existing successful system), and users don’t want to make many changes. The technology being used has all been proven and is well known in the company.
All the standard project management tools work. This is a good project to develop junior managers. This can also be outsourced easily.
The risk here is all on the technology side. We aren’t making many changes in a system, or the system being designed is clearly understood and is fixed in place. The growth here is in using new technology. Since the technology may not work, communication with users and back-up plans are crucial. The team leader must be able to keep track of and understand the work of technical people.
Outsourcers may be better at this kind of project than the local folks. ERPs are a good example.
Low Structure – Low Tech
Low Structure – High Tech
These projects can be surprisingly difficult. Since the structure of the system is not yet fully defined, much work with users is crucial. But users often change specs or seek to add features, so “mission creep” commonly occurs.
The best response is to have a strong leader – often a lead user – who can determine the specifications of the system ASAP and freeze them despite personal and political pressures.
Even though this is not technically demanding, outsourcers may not be able to do such projects well.
This is the worst all of all possible worlds. We are creating a system we haven’t fully defined and putting it in equipment that is new to us and may be new to the world. Success requires active user involvement to ensure the project meets user needs, and strong technical leadership to enhance the likelihood of successful operations.
Project management tools can be misleading here, with time lines showing seeming successes or 80% completion, when the very next task may show the whole project is impossible. IT might want to outsource such projects just to escape the blame for their failure.
How can we make outsourcing successful? While the book has several suggestions for making the relationship work, I think this is a place where we can also learn from failure. CIO Magazine just had a series on outsourcing disasters that led companies to end contracts and bring the work back in-house. I suggest you review these company examples:
How do you know if your company should be outsourcing substantial portions of the IT function? This requires that you have a sense for the kind of company you are now and the kind of company you will be during the ten-year life of a contract. What points would you make to your CEO about the appropriateness of outsourcing for your company?
Historical Tidbits for the Case:
While I don’t normally do this, there are some facts about XEROX that I find particularly ironic in light of their outsourcing decision. While management determined that their IT unit was pretty unsuccessful, over in California they had a research unit that is pretty well known to us computer geeks. Here is why XEROX is famous to us:
1970 – XEROX creates the Palo Alto Research Center “to create the architecture of Information.” (Palo Alto is the home of Stanford University and the heart of Silicon Valley)
1973 – XEROX PARC creates Ethernet to link computers. This is now the principle networking technology used in local area networks around the world.
1974 – XEROX PARC creates “Bravo” Word Processor. It has WYSIWYG (What you see is what you get – the same as current MS Word) interface and does cut and paste. It would be ten years before any other software could do that.
1975 – XEROX PARC creates graphical user interface for its operating system. Uses icon, pull down menus, and a mouse. It would be eight years before anyone else could even imagine these tools.
1977 – Jobs and Wozniak create the Apple Computer in Palo Alto. They manufacture the Apple II personal computer.
1977 – Bill Gates and Paul Allen create Microsoft as a company to create programming languages. BASIC is first, followed by Fortran and COBOL.
1978 – Dan Bricklin invents Visicalc (first spreadsheet program) while an MBA student at Harvard
1981 – IBM creates its first personal computer. Gets operating system – MS DOS from Microsoft. This command line operating system is the first experience most users have with a computer. It requires them to memorize commands for running programs, copying files, and naming documents.
1981 – Dan Bricklin hires Mitch Kapor to create Visigraph
1981 – Kapor takes $1 million pay out from Visicalc and starts his own company – Lotus development. He creates Lotus 1-2-3 for IBM. Bricklin has been denied a software patent so he can’t prevent Kapor from copying all his concepts.
1983 – Steve Jobs of Apple visits XEROX PARC facility. Engineers show him their inventions – the WYSIWYG word processor, GUI interface, and mouse. Apple launches a new computer called the LISA that uses these technologies.
1985 – Apple discontinues Lisa. Replaces it with Macintosh
1985 – Kapor buys Visicalc Corp and closes it.
1990 – MicroSoft releases Windows 3.0 – first full-function GUI OS from MS. Apple sues Microsoft for stealing their software. Neither company ever acknowledges the discoveries of XEROX.
(No, there is no connection between Visicalc/Lotus and this case, but I thought you might be interested in how that concept and company was emerging during this period.)
I think you could argue that XEROX invented the technologies that permitted them to become Microsoft and Novell if they had wished. Instead of being a company struggling through down-sizing and accounting scandals, they could be worth billions. They had the gold, but couldn’t think of any reason to mine it, so they gave it away. Those of you with a future in senior management might want to remember that, long after you have forgotten how they cut a major outsourcing deal.