Last week I wrote about Salami Slicing -- the viscous circle task of "making money" by offering less product for more money while squeezing your employees and supply chain for every possible penny.
To some extent, that's good business. After all, part of Adam Smith's argument for capitalism was that competing organizations would find cheaper ways of doing business, passing a portion of the savings on to customers. So by shopping around for the best deal from your suppliers, you are encouraging them to innovate.
If you look hard enough, you can always find a better deal. The problem comes in when you below rock bottom prices, to prices that just don't make any sense any more. Or, as John Ruskin is claimed to have said:
It's unwise to pay too much, but it's worse to pay too little. When you pay too much, you lose a little money — that is all.
When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing the thing it was bought to do. The common law of business balance prohibits paying a little and getting a lot — it can't be done.
If you deal with the lowest bidder, it is well to add something for the risk you run, and if you do that you will have enough to pay for something better.
Another way to state this law is "you get what you pay for", and you can see it at play every day in the real world. For example, I recent bought a pair of dollar store sunglasses for a family trip to Itasca State Park in Minneosta.
I usually don't wear sunglasses, but it was thirteen hour trip each way, and hey, they were a dollar.
Yes, one buck. They didn't look terrible and the road wasn't a beauty contest.
Of course, one of the glasses fell out of the frame after the first half of the trip, lasting a total of fourteen hours. It wasn't just cheap and short-lived -- no -- it was so cheap and so short-lived that I had to drive back with my eyes looking into the sun all morning.
The problem was that I payed too little. Even going the next level up, getting something for five or six dollars at a grocery store, likely would have lasted me ten to twenty times as long. Above that, and, if I took care of it, we could see one hundred times as long for only twenty times the price.
Now let's talk about the organizations I see doing outsourced testing.
Question 1: of the organizations doing outsourced testing (or, in some cases, even in house) -- how many of them are managing the test organization as it they were me going to the state park?
Answer 1: Far too many
So me ask question 2 -- What is the testing equivalent of broken sunglasses?
My guess is that not only is the software is broken and management doesn't know it and has bad information, but more than likely the software is also late and delayed because the outsourcer had problems setting up and staffing the test lab.
It gets worse.
To explain how it gets worse, let's start a typical salami-slicing scenario. Say, for example, you have a software project that needs to be tested. For the sake of dicussion, assuming it were possible, let's say you break the project into one hundred minor "featurelets" that ca be tested in isolation as the sum of the project. (This is just to save estimation -- more about that later.) We'll call this statement of work the 'demand', and it's not cheap.
Counting salary, benefits and other things on the back of a napkin, your loaded cost for an employee is about $500 per feature, maybe $750 if you hire a short-term contractor from that local 'Agile' shop. To save money, you outsource the work to a location with cheaper labor, say $250 per feature, for a total of $25,000 in savings off that regular cost, more in comparison to a consulting shop.
Sounds good so far right?
Well ... let's get back that Ruskin quote. The projected savings assume that the outsourcer can actually do the work. What if he can't? What if he doesn't understand the requirements, or the environment setup, or the intended use? What if he calls you up and asks for guidance or to place someone on-site? What if he turns in the work for the first twenty features and you realize it technically fulfills the letter of the contract, but you find the result unacceptable?
This creates a new type of demand, the cost of asking for the same thing a second time, perhaps with more clear language. This kind of new demand is something that the british psycologist John Seddon calls 'failure demand.' That is to say, when you are salami slicing, you might decrease the cost of each individual piece of work, but the number of pieces of work consistently increases. And it increases by a lot.
To put that a different way, we'll use Mr. Seddon's language:
"When you focus on decreasing costs, costs go up."
Back to our test example, that means bugs will slip through to production, you'll have to do a patch release (or two) and need retesting -- plus the time to manage the project will go up. Outsourcing in this way becomes a sort of false economy.
This is a real situation that occurs with many companies; in 2008 at a major test conference, one presenter claimed that she to be successful with test offshoring they needed to write test cases at a roughly 3rd grade education level. That's not an intended as an insult, more as a fact of life -- when you try to communicate an idea to someone who is thousands of miles away by paper, information gets losts -- and you have no mechanism to recognize this and adjust. So to be successful, you have to convey simple ideas in a very step-by-step fashion -- ideas so simply that both you and the other party understand the words without confusion.
Even this, however, has a problem, because you are telling the person what to look for. Yet at the end of every test case is this hidden check that few people write down: "... and nothing else strange or unexpected happened."
It turns out that describing that check in a simple, step-by-step fashion is surprisingly hard. In order to execute it well, you have to like, well, you see ... you kinda have to know the application.
Tell us how you really feel, Matt
Let me be clear: I'm not against outsourcing. My cohort in graduate school wrote our master's capstone on outsourcing, and there are a lot of cases where it makes sense. Here are a few cases:
1) When you need to use a commodity. Commodities are products that you can purchase that are essentially identical, where the only thing about them that differs is price. Paper, Gasoline, Oil and Corn are all commodities. You can tell a commodity because it has a "futures market." In most cases, they are cheap to buy but expensive to develop yourself, and multiple companies compete by price to sell to you. In that case, it makes sense to purchase your supplies from someone else. For example, try to find a local restaurant that makes it's own napkins, silverware or china -- it just doesn't make sense. More practically, electricity, bandwidth, and, to some extent, databases, compilers, and operating systems lean in this direction. Outside of Microsoft and Apple, most of us buy these products without a second thought.
2) For expertise you don't care to develop. In this case you might start a long-term partnership. The classic example of this is the big company hiring an advertising agency, but it happens in software as well. I know of several web development and programming shops that partner with companies to build software, but the partnership is focused more around expertise and priorities than it is around hourly rate. In some cases, these companies have worked together for two, three, five or ten years successfully. One thing I see in common in all these engagements is that they were not primarily motivated by cost.
3) For temporary staff. Most companies have up and down periods in a rough cycle; hopefully the trend line is up, but you will always have a time period where the current big project is winding down and the next big project hasn't started. With straight employees, it's very hard to properly staff. So you might bring in contractors, consultants, or hire a firm to offload some of the work during the ramp up phase of the big project. The benefit here is not cost savings per transaction; it's quick ramp up and down. In fact, you'll generally pay a premium to hire contractors; the hire bill rate is given on purpose in consideration of less job security.
4) When your company lacks expertise in an area and wants to develop it. In this case, you are hiring an outsourcer yes to do a project, but also to train and equip your team to do the work themselves. The Agile Coach/Consultant is probably the best software example of this, but I know folks who do this kind of work in software testing.
If you'd like the whole story, you can read the old Capstone paper. It's not terrible.
In the mean time, let me re-iterate: Organizations that manage by costs alone worry me. Because you can always save a dime here or there by taking a short cut. As Ruskin tells us, when all you care about is cost, you run the risk that what you deliver isn't capable of doing what you ask it to do.
Somewhere in North America, there is a drum, beating for 'higher efficiency', and what it means is cheaper transaction cost.
I don't care about cheaper transaction cost. I care about value, and, if any cost, lower total cost.
Now if we wanted to change our organizations to focus on value -- what would that look like?