Outsourcing is common in the computing world these days. It is said to save costs, eliminate the need for additional in-house employees, and provide adaptable staffing levels that can flex with the ups and downs of business cycles. But there are costs and dangers to outsourcing and companies can leave themselves open to business practices that can be quite predatory.
Most vendors view the growth and protection of their revenue stream to be the most important thing. Even when they do behave ethically, this can cause conflicts of interest between what is best for the vendor, what is best for the vendor account manager, and what is best for the customer. It can lead to some nasty behavior.
I once worked on a large project alongside a consulting company that actually had meetings to decide just how inefficiently they needed to work to maximize their income. A job done too quickly that resulted in a high-quality system would end the project and the checks would stop. A job done too poorly would get them fired and the checks would stop. Somewhere between these two scenarios was an optimal point where they could drag out the project and maybe land a lucrative maintenance contract fixing the system. Customers were not invited to these meetings.
Who to Blame?
Even more perniciously, I have seen vendors deliberately identify "targets" in the customer’s environment who could be blamed when something went wrong. The "target" might be a middle manager in the client organization; one low enough to clearly see what was going on and act as a whistleblower, but also high enough to be listened to. The vendor would collect email messages, memos, meeting minutes, and so forth, to be used against the person. Then if the target started making waves, the memos were presented to senior executives in the client organization and the whistleblower portrayed as "…not a team player…" These smear campaigns were often successful and resulted in the targets getting fired. It worked out well for the vendor—they would get rid of a potentially dangerous irritant and divert the blame for problems at the same time. Perfect!
Stubbed Out
"I want you to get everyone writing stubs for the system," the vendor managing partner told me. On a project some years ago, I was in charge of a large group of programmers and I was puzzled by the directive, "What are the stubs supposed to do?" I asked. The managing partner replied disdainfully, "Stubs are dummy programs that don’t do anything, their functionality hasn’t been decided yet." "Heck, I know what stubs are," I responded, "but we need a reason to write them: to set up a system architecture, test infrastructure interactions, to check out program load capability… We don’t write stubs just to write stubs…"
The managing partner’s eyes narrowed. "You’re not a team player, are you?" he said. It was not a question and I had just become a target. He wanted to report to the client that code was being written, whether it was needed or not. But he was right: I was not a player on that kind of team.
Organizational Issues
These examples operate at the personal level and can lose people their livelihoods. But problems can occur at the organizational level:
- Project Estimation—vendors can take over the project estimation processes under the guise of "improving project management" requiring clients without their own internal capability to rely on the vendor’s assessment of what projects will cost.
- Project Tracking—vendors may appropriate all project tracking and status reporting so that the customer sees only what the vendor wants them to see.
- Governance—unless customers exert a strong hand in managing the portfolio, they rely solely on the vendors for results and the vendors may have a vested interest in it not being too successful.
- Vendor Conflict—I have seen situations where different vendors were contracted to build different parts of a system and another vendor to test it. It is a recipe for finger-pointing and blame avoidance that might end up with more money going to the vendors.
Revolving Vendor
The goals of the vendor and the customer may not be the same. Vendors are in business to maximize the benefit to them and they may do things that are less than optimal for the client. Vendors may recruit inexperienced talent, because they do not have to pay these people as much. But once a programmer has spent a year or two with a client, they are now "experienced" and can command a higher billing rate elsewhere. So the vendor may move out a person who knows what the system does and move in a novice who does not.
If developers come from overseas, their visa may be linked to the vendor and the developers must behave the way the vendor wants them to behave.
The net effect of these vendor strategies is the customer pays a lot more for systems that are of low quality.
Fixed-price contracts that are running over budget give vendors a strong incentive to put lower-cost (and less-talented) resources on the project just when a project needs to keep the more experienced and skilled developers.
Owning and Using
The net effect of these vendor strategies is the customer pays a lot more for systems that are of low quality. But that is just money; there are broader consequences.
In a previous column,1 I discussed the difference between owning and using systems. Companies need to own the systems that are the executable version of the knowledge of how the company works and why it exists. Companies that outsource the development and maintenance of these systems outsource their future. Now the company does not control that knowledge—they have paid someone else to manage it. Losing control of these systems and the knowledge they contain, they have also lost control of their markets. Vendors can peddle this information by selling their experienced developers’ services to the client’s competitors. They can siphon off what their developers have learned and can build and sell their own solutions and when everyone uses the same packages no one has any competitive advantage. The diluting of a company’s specific knowledge can reduce innovation; the gene pool of variations that catalyze new ideas is thinned out when everyone uses the same systems.
Apprenticeship Has Sailed?
Where do we expect our future talent to come from? I have worked with companies where people say with pride that, while the "grunt" programming is being outsourced, activities further up the food chain are being done by experienced in-house people. But how did they become experienced? How did they acquire the necessary business knowledge and technical expertise? They usually started as a novice programmer and, by working hard, displaying ingenuity, and seizing opportunities, rose through the ranks to become an invaluable resource. If the entry positions are being farmed out to vendors, companies cannot grow the next generation of senior technical staff and become even more vendor-dependent.
Action and Reaction
Outsourcing is still in vogue, but there are some interesting trends occurring.2 There is growth in hybrid client/vendor governance, a move to insourcing development, more in-house integration, and contractual stipulations on vendor cooperation. These are all healthy trends.
But there is a deeper issue at stake here operating at the executive level of many modern companies. The headlong charge to outsource essential development is framed as cost reduction but it is driven by something akin to executive cowardice. Building modern systems can be very difficult. Creating and managing an organization that can build these systems is challenging. Looking beyond the next quarter’s financial results requires executive vision. Sacrificing short-term quick hits in favor of long-term growth and corporate health requires technical and leadership backbone. But 25 years ago, leaders of many companies did step up to this challenge and now they do not. Now, to avoid the hard work and challenge of today, executives are signing checks and turning over the keys of the kingdom to vendors.
But vendors only work the way their customers and the market allow them to. Rather than being controlled by them, companies can genuinely partner with their vendors, obtain good systems for a reasonable price, and own and manage the systems knowledge that defines their business.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment