It was a fine spring day in Denver. The snow was melting from a late season snowstorm, not unusual for Colorado this time of year. The CIO was busy dealing with a networking problem. The firewall system was not letting all the traffic through for the new web services interface for the supply chain software that had just been installed. He was interrupted by a call on his cell phone. “Jack, we have a problem.” What else is new? Jack thought and almost said it. “It’s the new data warehousing project,” Mary said. “It’s behind schedule again.” “So what else is new?” This time he did say it. Mary said, “Yes, I know, but we really need to do something about it. These consultants we’ve hired are costing us an arm and a leg, and progress has been so slow.”
That’s what we get for paying them by the hour, thought Jack. As the saying went, use a small brush if you are paid by the hour to paint.
Mary continued, “They are working as hard as they can, and they are even spending some extra hours they are not billing us for.” “Then what do you suggest?” Jack asked. “It’s the way the project is being managed,” Mary said. “We thought having all the programmers here would reduce the need for specifications. But at the rate we are going, we are going to blow our budget for this project in the first three months.” Jack could see it coming. The pressure from the CEO to outsource this project would be inexorable now. “We are going to have to find a way to make offshore outsourcing work for this project.”
“I know,” Mary said reluctantly.
Thou Shalt Outsource - pages 15-16 in Chapter 1 Deciding to Outsource
I was first exposed to outsourcing at one of my software startup companies in 1991. I was the third person in the company and the first technical hire. I thought my job was to hire a team and develop the software product from scratch. But on the first day, the CEO said he wanted me to manage the outsourcing of the software development.
“Out what?” I asked. He asked me to manage a small custom software development firm in Oregon as they created version 1.0 of our software. “But I want to write code!” I told the CEO.
He said, “Do you want to write code, or do you want to be a millionaire?”
At first it seemed like a tough choice. But this little company in Oregon had developed a software application for another client that was almost exactly what we needed. They had retained the rights to sell the software to others, and the CEO had negotiated a terrific deal that gave us the software along with the custom changes we needed.
Actually, the choice wasn’t so tough after all. I worked well with the team, and my role ended up being one of product manager rather than software engineer. I helped with some technical decisions, but my main responsibility was defining and directing the activities of the outsourced engineers to make sure they kept on track....
By the way, the company I worked for in 1991 that outsourced to Oregon had a successful public offering of its stock in 1996 and then got acquired at the height of the stock market in 2000 for $9 billion.
A Vendor Selection Nightmare - page 72 in Chapter 3 How to Select Your Outsourcing Vendor
A VP of engineering at a software company told me that it took him more than five months to select an outsourcing vendor. On his own, he carried out a careful search for an outsourcing vendor in India, China, and South America. He sought a low price point to give him a specific cost savings over hiring engineers in the U.S. He evaluated 22 vendors in these three countries. Then he made nine site visits. Site visits are not always necessary, but in his case the company was interested in a build, operate, and transfer (BOT) arrangement giving it the option of transferring the team to its own subsidiary.
After all this work, time, and money, he still got less than satisfactory results. He selected a U.S.-owned outsourcing vendor with an operation in China. The vendor was in the process of acquiring a second team of programmers in China. The VP found this second Chinese team to be excellent, and they quickly sketched out an architecture and design for the software that was needed. He then worked out the financial terms with the U.S.-based vendor and signed the agreement. But the acquisition of the second Chinese team by the U.S. outsourcing vendor fell through. A junior team from the existing operation in China was assigned to the VP’s project instead.
Then the nightmare began.
The English skills of the junior programmers were limited, making communication very difficult and inefficient. And their programming skills seemed even worse. Their day-to-day activities had to be closely directed by the U.S.-based VP and his staff. The source code developed in China was reviewed daily. Because of the 16-hour time difference with China, managers in the U.S. spent many late nights emailing detailed instructions (even pseudocode) and answering questions by phone when it was daytime in China. This led to severe morale problems within the U.S. staff,
made worse by the fact that the U.S. staff never thought outsourcing was a good idea to begin with. Missed deadlines and vociferous employee frustration eventually elevated the issue to the board level. But the damage was done. Within two months, the VP was gone. The outsourcing engagement he so carefully arranged went bad and caused such an awful ruckus that he was forced to leave the company.
Did You Ever Purchase an Employee? - page 73 in Chapter 3 How to Select Your Outsourcing Vendor
In the mid-1990s, a friend of mine-let’s call him Romeo-was the first employee at a Silicon Valley startup. Romeo was negotiating with the founding CEO for his starting salary and stock before coming on board. The CEO had raised a small seed round of initial funding and offered a very low salary.
“But I have five kids,” Romeo said.
The CEO said, “Yes, I know, but what does that have to do with how much I pay you?” The CEO had a point. After all, the salary should be commensurate with the value the employee brings to the company. But as any smart negotiator knows, you have to take the other person’s perspective
into consideration.
Romeo accepted the salary and stayed at the company for a while. But he was completely discouraged during his last six months there, before he left to start his own company.
A surprising cultural difference- page 100 in Chapter 4 Offshoring, or Creating Your Own Offshore Subsidiary
For example, an accountant I know has a client that created a subsidiary offshore. An employee who was originally from India went there to set up the operation. The accountant was amazed to see several expenses required to get things done quickly that were actually bribes. Similarly, in 1992, one of my companies set up an offshore facility in India. The American VP who was responsible for the group traveled there several times a year. He had many stories to tell that show how different things can be in another country. At the end of one trip, he was ready to return home after being in Bangalore for about a week. He was at the airport boarding gate, ready to go-luggage checked and boarding pass in hand. They began loading the plane but would not allow him to get on. After making several requests to board the plane, it finally dawned on him what was required. A crisp ten-dollar bill (or the equivalent in rupees) and he was politely allowed on board and was on his way home to the good old USA. That was just the way it was in India at that time.
Marchitecture and Tarchitecture- Page 119 in Chapter 5 Describing Your Software for Outsourcing
The two architecture types are sometimes confused, as they were at a visit to a client. A venture capitalist interested in investing in the company was also present at the meeting. Actually, the VC was really excited by the technology and was effusive in his praise of the technical co-founder of the company. I also thought the technology was interesting, but I was having trouble visualizing how the software would be used. So I created a diagram showing how all the modules fit together. This was a architecture diagram.
The technical founder did not see much need for documentation, but he showed the VC my diagram anyway. “Oh that’s just ‘marchitecture’!” the VC said, his tone of voice clearly indicating that it was of little value. He did a good job of intuitively sensing what the techie wanted to hear.
That was not the first time my work has been dismissed by a VC, and I am sure it will not be the last. But there are two problems with this situation (three, if you count how his emotions were being manipulated by the VC). First, the company really did need a good description of the architecture to better communicate the product requirements, both to customers and newly hired engineers. A well-defined architecture enables engineers to “own” the piece of the software they will develop. Second, my diagram showed how the internal technical modules were interrelated. As such, it was not a marchitecture diagram. Even if it was, it should not be so easily dismissed.
My job is so secret- Page 180 in Chapter 8 Protecting Your Intellectual Property
Many years ago I worked for a software company that licensed a copy of its software to the U.S. Navy. I flew to San Diego to do the installation. Even in those days, security was a notch higher than at most companies I visited. After checking in at the guard shack and meeting my escort, I was ready to get to work. But first my escort had to find a third person authorized to bring my tape into the data center so we could read in the software. Then more authorizations were needed to allow installation of the software on their Univac computer. The installation process dragged on. During one of our many breaks, I was escorted to the men’s room. Along the way I passed someone’s cubicle with a big sign on the wall. It said “My job is so secret, I don’t even know what I am doing!” That pretty much summed up my experience that day. The point is that sometimes the need, or perceived need, for confidentiality and security adds a great deal of inefficiency and cost. Software company executives consider their software IP to be their highest-value asset. But is it? How about your sales contacts and deep knowledge of the market you sell into? The actual software and the work that goes into creating it are often just a commodity.
Avoid the Impossible- Page 199 in Chapter 9 Outsourcing Your Quality Assurance
Take a pragmatic approach to software QA. It is often impossible to test everything because of limits on time and budget. For example, I was responsible for the testing of a database product at one of my startups. We received a few bug reports of slow searches, and so I decided we should test every combination of inputs to find out which ones were slow to execute. I found that there were literally billions of input combinations. Even if I could run a search combination each second, it would take almost a year to do all the searches! Outsourcing to all the engineers in China would not be enough manpower to finish testing the software in a reasonable amount of time. I finally created a list of the top hundred likely search combinations to test and found that to be sufficient.
Globalization: Good or Bad?- Page 221 in Chapter 11 The Future of Global Software Development
When I was in high school, my brother gave me the book Flatland by Edwin A. Abbott. It portrays Flatland, a world of only two dimensions, in which a square Flatlander discovers the third dimension and tries to explain it to his fellow two-dimensional compatriots, without much success.
Flatland first caused me to feel a sense of superiority over the lowly shapes inhabiting Flatland who could perceive only two dimensions. Then I realized that my arrogance at being able to perceive a full three dimensions would seem pathetic to any creature that inhabited a universe of four dimensions or higher. Humility, or at least caution, was definitely in order. It is ironic that Tom Friedman has chosen The World Is Flat as the title for his book. Like the lonely but perceptive square in Flatland, Friedman has become aware of the new global dimensions of our world and how we must adapt to them in order to prosper. Friedman is certainly not a “square” in the 1960s sense of the word. He is a well-respected journalist who has a knack for making incisive observations that uncover the key human factors of our world, and then turning out memorable prose to drive his points home.
Shopping the World- Page 231 in Chapter 11 The Future of Global Software Development
Shopping the World: Jack and Mary’s Story Continued ...
Jack started the meeting. “Okay, where do we stand?” “Well,” Mary said, “I created a list of about a dozen vendors in India.” “Terrific!” Jack exclaimed. He was worried that finding an offshore vendor was going to be difficult. They were given the assignment by the CEO at the last operations review meeting, at which the disappointing delays of the data warehousing project in IT were discussed. Going offshore has become critical because of budget constraints and also because there were not enough resources in IT to handle some new projects coming up later in the year. “How did you find them?”
“Google. I spent a couple of hours last night searching the web.” Mary explained. “I got lots of hits.” “So maybe finding a vendor won’t be so tough after all,” Jack said optimistically. “Not so fast,” replied Mary. “I mean I had lots of hits-hundreds of web sites. I also found some online directories with literally thousands of vendors. It will be a challenge to sort through them all to try and find the right vendor for us.” “Oh,” said Jack. “Let me see the list. Maybe we already know some of them.”
Jack looked at Mary’s list. It had some of the larger Indian outsourcing vendors with familiar names, and the rest were companies he had never heard of before. “I’m afraid these larger ones won’t respond. After all, we only need a few programmers.” “You’re probably right, but I thought we should have them on the list anyway. You know the CEO is going to ask about them,” Mary explained.
“Hey, I have an idea,” Jack said with sudden enthusiasm. “How about that programmer that used to work for us-what was his name?” A second later, he said, “I remember. It was Ravi. I heard he went back to India and is now doing something with outsourcing. I think he is working with family members back in India or something.” “Maybe,” said Mary slowly, trying not to be too discouraging. “I remember Ravi, but I am not sure that is the right fit for us. Do you even have his contact information?” Mary continued without waiting for Jack’s answer. “Anyway, we have to show the CEO that we made our selection carefully from a list of multiple vendors. Hiring a former employee back in India is not good enough.”
“What about ELance?” asked Jack. “No, Jack. We need eight programmers. I don’t want to manage a bunch of freelancers spread all over the world,” said Mary. “But that does remind me,” Mary continued. “I found vendors in other countries besides India. I am not sure how to compare them all.” “First of all, they have to have experience with the data warehousing software we are using,” Jack reminded Mary. “And .NET for sure.” “And some knowledge of our business would be ideal,” added Mary. “It seems like a tall order.”
“This might take longer than we thought,” said Jack. “Somehow we have to get to a short list by the end of the month.” “I know,” Mary said reluctantly. “I’ll keep looking.”
