Chapter 4

Agency and Outsourcing Risk Management

“Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where—” said Alice.

“Then it doesn’t matter which way you go,” said the Cat.

“—so long as I get SOMEWHERE,” Alice added as an explanation.

“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

—Lewis Carroll, Alice’s Adventures in Wonderland, chapter 6.

Back to the Main Question

In a recent industry survey of 366 business technology professionals published by Information Week, 7% of the respondents said their company’s approach to outsourcing its information technology (IT) is to outsource as much as possible; another 23% said the policy is to outsource as much as possible except for executive and managerial positions; another 21% said it is to outsource as much as possible except for executive, managerial, and engineering positions; and another 8% said the same but added except for development roles.¹ This adds up to 59% of companies that would outsource regardless of the nature of the IT and the task. With such an attitude toward wholesale IT outsourcing it may indeed be that Carr² was right when he predicted that IT should be treated as a utility and outsourced except in special cases. And yet, things are really not that simple. Forty-three percent of the respondents to the Information Week survey also said their company did not have a system in place to manage their information systems (IS) outsourcing vendors.³ And this brings us back to the story in the Prologue of the chief information officer (CIO) sitting in his office outside Detroit commiserating that he outsources his IT all the time but has no idea if he is doing it correctly. If he were one of those 59% then he was in for a nasty surprise. And he was; he was transferred to another position shortly afterwards. Outsourcing is not that simple.

The real question the CIO should have been asking himself was whether his objective in IS outsourcing was about better allocating risks, costs, and resources constructively after thoughtful analysis or was it perhaps only about abrogating responsibility. This means first and foremost understanding and managing the risks. It is after all the main responsibility of a manager to control and if control is impossible then at least to manage risks. A convenient way of understating the context of these risks is through “agency theory.” Only after the various risks have been brought to acceptable levels do other considerations, such as new IS initiatives and opportunities, come into play.

Agency Theory

One of the most popular theories academics have to explain outsourcing, and indeed contracting with other companies in general, is agency theory.⁴ Agency theory, and its derivative contract theory,⁵ in a nutshell, deal with the case of a principal who lets out work to an agent who then performs it. Within this context the principal faces an agency problem, which boils down to the issue that there is no way the principal can know as much about the agent and the work it is supposed to be doing as the agent itself knows. This information asymmetry, whereby the agent knows more than the principal does and may take advantage of this to advance its own interests, which may well be quite different from those of the principal, translates into three categories of risks: adverse selection risks, moral hazard risks, and unexpected contingencies risks. In the context of outsourcing the principal is the client company and the agent is the vendor company. At the core of agency is the concern to minimize the loss a principal may encounter as a result of the agent having its own interests rather than those of the principal at heart,⁶ and the realization that because of these conflicting interests information asymmetry increases the principal’s risks.⁷ As the chief executive officer (CEO) of Zappos, an online shoe selling company, put it in reflecting about the mistakes his company made in outsourcing: “Trusting that a third party would care about our customers as much as we did was one of our biggest mistakes.”⁸ Agency theory has been extensively applied to explain the details of IS outsourcing.⁹ Understanding the agency relationship is crucial because many outsourcing projects, estimated by some at 28%,¹⁰ fail because of contractual management issues.

Managing Adverse Selection Risks

Adverse selection risks deal with identifying trustworthy agents before the contract is signed and, importantly, avoiding the risky others. Chronologically within the outsourcing process this happens after the outsourcing client (the principal) has decided what the extent of the outsourced project will be, estimated the range of cost it is willing to pay, secured the funds, and issued a tender (otherwise known as an RFP, the acronym for request for proposals). Once this RFP has been issued, and vendors start bidding on it, the principal needs to choose among the contending vendors (agents). The principal’s problem is that unless proper steps are taken, such as choosing only among vendors the client has contracted with in the past or only among appropriately certified vendors, the competing agents can masquerade as almost anything they wish and can claim to be able to do more than they really can.

The principal needs to be careful in its choice of an agent—and this is adverse selection risk. Choosing the wrong agent not only may delay the project but also may cause additional expensive collateral damage. Take the large European bank discussed in Gefen and colleagues¹¹ as an example. The bank adheres to the regulations issued by the governments and central banks in the countries it operates in, including the Federal Reserve in the United States and the European Central Bank in the EU. Adhering to these regulations translates among other things to software modification. Choosing the wrong vendor might mean not only delays in implementing these regulations, and the subsequent fines from the central banks, but also the risk of corrupting the data because of glitches in the developed software. Correcting data after such a glitch is not easy or straightforward because the bank is not allowed to just change the balance sheets of its clients. With all this in mind, choosing the right agent is crucial and is treated accordingly.

Throughout this agent selection process the principal typically does not have all the information it needs about the agents who are bidding on the tender—and this poses a unique set of risks that CIOs are eager to avoid. Indeed, in my talks with CIOs they often emphasize that they outsource only to a select few vendors—and the CIOs make sure these few vendors realize how special and profitable to them this relationship is so they invest over and above so as not to lose this privilege. This, in effect, creates a select club of vendors who have a strong vested interest in maintaining this relationship. These vendors, as I can testify from my own past experience as a project manager in one of them, will do within reason all that is necessary to make sure the project succeeds, even going more than the extra mile beyond what the contract says to make sure the principal is satisfied. After all, at stake here is not only this project but also their entire long-term relationship with the client. In other cases with big client companies, the client’s IS managers will reward those vendors who have been delivering to their satisfaction over the long run with the easier-to-manage and less-risky time and materials contracts.¹² Other ways of managing adverse selection risks in an IS outsourcing relationship include preferring vendors based on recommendations either from other clients or, better still, based on previous contracts the particular vendor had with the client.¹³ Another way to preselect a short list of trusted vendors is by relying on certification from appropriate agencies.¹⁴

It is all about creating incentives that will first of all cause the vendor to not want to take advantage of its information symmetry, either by bidding on an RFP it cannot deliver on or by not completing the work. This is also a matter of managing trust and creating a trustworthy relationship between the client and the vendor.¹⁵ Trust-based relationships add special extra value to the business relationship because both sides know the other is also in it for the long run and is unlikely therefore to rush to take opportunistic advantage of the situation. It also means both sides know that in the long run it is not a zero-sum game between them. Having such a trusting relationship allows companies to somewhat let their guard down a bit so to speak and not be on constant vigilance with all the extra costs this brings about.

Moral Hazard Risks

Once the contract has been signed and the agent starts working on the contract the principal faces a new set of risks known as moral hazard risks. These risks amount to not knowing exactly what the agent is doing, not knowing the quality of its work and how the agent is doing this work, not knowing what quality controls the agent has and whether the agent is really applying them, and not knowing whether or not the agent will meet the timetables. The key issue here is to identify problems early on and take steps, preferably in coordination with the agent, to remedy the problems before things get out of control.

It is important to note here that this does not necessarily mean that the vendor is malicious, bad intentioned, or cannot be trusted or that therefore steps should be taken to curb the agent. On the contrary, the vendor too wants the project to succeed and will reasonably invest in its success, at least as long as it is not actually losing money on it. But the vendor has its own motives, objectives, and understanding of how things should be done. Moreover, the vendor is legally bound first and foremost to serve its shareholders and make a profit. So there is nothing wrong, and it is to be expected, that the principal and the agent will have different objectives, as long as all parties realize this and take steps to reduce the risks it may cause. After all, even within the same organization there are disagreements among departments, especially the IT department.

Even with strict formal contracting moral hazard remains a serious risk because, in a large IS development of any kind, so many things cannot be made explicit enough in a contract. Indeed, so many things cannot be known well enough by the client when the requirements document and with it the tender are made. And this is true even more in the case of outsourcing, because the agent has a vested interest to hide its problems. Agents do not like it when the principal tries to micromanage or micromonitor their activities. And that is precisely what happens when the principal starts suspecting the agent is having trouble, because any problems the agent cannot resolve will be the principal’s problems, too. And so, when schedule is not met, or a glitch is found, or key personnel leave or need to be moved to a more urgent project, or the technology does not perform as expected, or any of a myriad of other problems occur during development and testing, the agent has a strong incentive not to report it to the principal but rather to try and solve the problem quietly. And then the agent may try to cut corners where the principal cannot easily notice (such as in quality control and testing) in order to save time and money, as well as the wrath of an inexperienced principal when the schedule is not met to perfection. Unless the principal takes explicit steps to control such risks (i.e., the agent taking advantage of its information asymmetry) there is little chance the principal could know about it, especially if the agent is offshore.

Moral hazard risks must be accounted for, and not only because the agent may have a reason to cover up. It is important to reemphasize again the analogy of IS projects to jigsaw puzzles. It is not uncommon for the requirements for such projects to span thousands of pages, and so it is almost impossible for most people to comprehend all the details in such large documents, let alone identify where the details contradict each other or current practices. It is not until almost all the pieces of an IS project jigsaw are in place that people start seeing what pieces are missing and what pieces need to be reshaped so everything fits in nicely.¹⁶ This problem is, of course, aggravated when the IS project is outsourced and the people developing the software do not even belong to the same organization and do not share the same business culture and knowledge with those using the software. This problem is exacerbated even more when the project is cut in size, as it often is, to meet budgetary constraints after the original requirements are approved. In such cases sections are often cut out without fully understanding how the removal of a function may affect other parts of the system. It is only when all the parts of the software project are put together that the implications of the missing sections become obvious, by which time one has to be careful not to have the project digress into a blame war between the principal and the agent. Being fully aware of what the agent is doing is crucial even though the agent is doing nothing wrong, because the agent can notice earlier on what mistakes the principal made, and identifying these problems early can help in alleviating them.

Managing Moral Hazard Risks

Moral hazard risks are unavoidable, but steps can be taken to mitigate them. The first step clients can take to reduce or at least control these risks is to add procedures and processes to measure what is going on. Measuring what is happening is an imperative step in handling any kind of project. As Peter Drucker famously said, “If you can’t measure it, you can’t manage it,”¹⁷ or as Lord Kelvin (Sir William Tompson) said earlier about science, “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.”¹⁸ To measure in this case means to (a) identify the critical success factors (CSFs) at every milestone in the project, (b) assign measurable critical values of when there is trouble to every one of these CSFs, and (c) to determine how and how often this measurement should be done. Once this measurement system is in place the principal can figuratively keep its finger on the pulse of the project and know early enough if something is amiss. Without continuous measurement keeping track, and more importantly keeping an early warning system up and running, would be impossible. This is, of course, true of any type of management, but it is even more critical in the case of IS outsourcing because the principal is not there on site all the time and so really does not know what is happening. Moreover, measuring these CSFs not only sends a message to the agent that the principal is involved and cares about the project but also tells the agent what aspects of the project are most important to the principal.

Measuring is closely coupled with another step principals can take, which is monitoring. Monitoring can take several forms. To being with, as an integral part of any outsourcing project the client should insist that the vendor report on these CSFs regularly and automatically whenever a CSF measure reaches a critical value. This should be in the contract. Thus, for example, the contract should stipulate that there will be a periodic progress report from the agent, as well as a report when any quality control measure exceeds its CSF critical value. These progress reports could be addressed weekly or biweekly to tactical project management and monthly or bimonthly to senior management. Monitoring is crucial for success in outsourcing, which is not about abrogating responsibility but rather about letting someone else do the work, someone who can do it faster, better, or cheaper. Monitoring, therefore, is a crucial way of not abrogating this responsibility. And, perhaps not less important, monitoring is also a message the principal sends the agent that there is no free lunch! Monitoring may also include the on-site presence of a principal’s liaison officer who is embedded in the projects the agent is running for the principal. This could give the principal firsthand information about what is happening and why, beyond the periodic reporting. And, moreover, when the agent runs into difficulties in understanding what the principal wants, which should not be ruled out, this liaison can quickly fill in the gaps or at least know who to contact on the principal’s side to get things moving quickly. Indeed, being on-site and therefore having someone embedded with the vendor, especially when the vendor is in another country, has been shown to improve project success.¹⁹ It also creates a better sense of being one team with the developers, which also contributes to project success because the parties understand each other better and realize it is a joint project whose success requires everyone to play their part.²⁰ This also broadcasts to the agent how seriously the principal takes the project.

As important as monitoring is, it is also important not to cross the line. The principal and agent should agree ahead of time in the contract itself on what is being measured and how frequently. This also sends a message to the agent that the principal is not micromanaging the relationship. After all, as a principal you want the agent to take responsibility and enjoy their work. Even with the best of monitoring, there will still be moral hazard risk, so you really want the agent on your side. And so measurement and monitoring by the principal should be thought of not only as a tool for controlling the principal’s risks, which it is, but also as a way to broadcast to the agent exactly what the principal wants and let the agent know how the principal wants the relationship to be managed. Setting the rules of the business relationship this way should also reduce misunderstandings and inadvertent border crossings. As a principal, when you set the monitoring standards it is important to remember that the agent does have its own objectives and these are not the same as yours and indeed cannot be so legally because the agent owes its loyalty to its shareholders. Setting the monitoring rules and standards upfront before the contract is signed defines this borderline. Good fences make good neighbors. The risk of micromanaging is convincingly presented by Tiwana and Keil,²¹ who show that, based on 57 outsourced and 79 internal IS projects, applying a lot of control may be beneficial in internal IS projects but is detrimental in outsourced ones.

As important as monitoring is, having meetings with the agent is also crucial. Periodic meetings serve to bolster monitoring, but they also serve a possibly even more important role in building trust and creating a sense of togetherness, of being one team. Even when there is strict formal contracting, trust remains a crucial element in outsourcing IS projects.²² Better still is to have a senior manager of the principal on site regularly, being involved in the ongoing management of the outsourced IS project. This senior manager is not the same as the embedded liaison officer who takes part in the building of the IS project itself. Being on site during senior management meetings allows the principal to know firsthand what is happening at the project management level. The principal thereby has a real feeling for the situation, the inevitable problems that will arise, and how effective are the steps the agent might take to remedy those problems. The agent would obviously rather keep such information to itself. Being on site means the agent cannot hide it. But being on site also allows the principal to bring in its own expertise when something goes wrong, and this advice may be invaluable to the agent. This is important because outsourcing should not be treated as a zero-sum game; rather, it should be treated as either both sides gain or both sides lose.

The latter point relates to another way to alleviate moral hazard risks when outsourcing. It is about being sure the agent has a joint interest in the success of the project. Now, the agent has a vested interest in the project not failing. Failure, even if not the fault of the agent, means bad reputation in the market and low morale among its own people. It is better to have the project succeed, even if the agent does not make the profit it was hoping for. But from the agent’s perspective there is a big difference between project success, meaning delivering on time and within quality guidelines to the satisfaction of the principal, and being a party to that success. And this is something principals do not always fully grasp. The agent, while building the software project, sees opportunities and mistakes the principal could not while planning it. As a principal you want the agent to bring these issues to your attention and to do so as early as possible. Having the agent merely fulfill the contract does not serve this purpose. It is the difference between the agent who is simply a service provider and one who has a vested interest in success beyond the payment and reputation this brings.

There are many ways the industry can create such joint interest. There is first of all the option of rewarding the agent monetarily for delivering ahead of schedule or for service beyond the requirements of the contract. This could actually be a provision in the contract. There is also the option, as in reducing adverse selection risks, of—in principle—outsourcing only to a select group of vendors (this select group would be limited to those vendors who delivered satisfactorily in the past) and possibly paying these agents above market price. Agents would rationally want to remain in this select group and would therefore go the extra mile if necessary to ensure they deliver the project satisfactorily. (See more on this issue in chapter 1.) This shifts the agent’s mind-set from the short-term perspective of this one project to a longer-term relationship spanning many projects with the principal. By highlighting contradictions, missing aspects, and missed opportunities in the requirements, principals can give agents an incentive to prove their worth. And, as in addressing adverse selection risks, agents can be led to understand that part of this long-term relationship means they will have access to more profitable contracts in the future.²³ Another way to enhance agent involvement is by letting the agent take some of the credit for the success of the project. Such reputation could mean a chance to bring in future contracts with other clients. Saying an appropriate good word about the agent can go a long way toward creating a win-win situation.

A principal might also prefer agents it has extensively contracted with in the past. Taking advantage of such business familiarity not only lets the principal and agent know each other better—so each can take the necessary steps to ensure success and know what to avoid to reduce unwanted consequences—but also builds a relationship based on trust,²⁴ which in its own right reduces to some extent both information asymmetry and the incentive to take advantage of it.²⁵ Indeed, research concentrating on the principal has shown that business familiarity is a key consideration in granting contracts to agents, presumably because it reduces information asymmetry and identifies trustworthy agents,²⁶ and, as case studies show, it is crucial in software development outsourcing.²⁷ Business familiarity is of special interest as well in the context of moral hazard risks because it improves communication and mutual understanding²⁸ and reduces the need to rely on costly contractual controls and verification protocols,²⁹ such as the cost of creating and monitoring more complex and lengthy contracts.³⁰ Doing business with a trustworthy partner also means that each party can rely on the other to do the right thing for both sides after the contract has been signed and will not take undue opportunistic advantage of the situation.³¹

Notice that legal action is not discussed here. There is a reason for that. By the time legal action may be an option the project will long since have been over. Legal action might be nice for revenge and may result in some compensation when things go wrong, although it is doubtful if these could cover all losses, but it will not solve the problem of the project not being delivered on time. Besides, putting litigation into the relationship with the agent is bound to add a sour taste to it. And if the agent knows it may face litigation or penalties then it will raise its price to account for these extra risks it is taking.³² Higher outsourcing price is obviously not in the interest of the principal.

Managing the Risk of Unexpected Contingencies

The risk of unexpected contingencies cannot be avoided in large IS development projects and especially in outsourced ones. The first category of such risks deals with the nature of IS. Large software projects can be so amazingly complex that it is hard for any one person to see the whole system. It has long been a maxim that one should manage such projects with a mind-set that there will always be new topics that will need to be added into the requirements after everything has been approved.³³ This is to be expected, as it is too much to expect users to see the entire picture of the system—often described in thousands of pages with all its interwoven connections within itself and to other systems—until they try it out. Based on typical empirical numbers in projects I managed, one could expect up to about half the software problem reports in a new project to be tied to the need to expand the requirements or to address topics that were left out of the original set of requirements.³⁴ The complexity of large software projects also means that things will unexpectedly go wrong and delay the project. In one project I took part in everything went beautifully in the initial testing phase, but the moment the project went live—and we had not tens of users but thousands of users simultaneously—the database froze. It was just not calibrated for so many transactions. As a result, to the embarrassment of senior management, project release was delayed by a day until the database expert from IBM could come on an emergency basis to deal with it. These risks are exacerbated in the case of outsourcing because the requirements typically need to be frozen once the contract has been signed and the vendor has committed its personnel to it based on cost.

Apart from those requirement and technology risks, the quick advent of technologies also adds to the risk of unexpected contingencies in the form of new game-changing technologies such as, in 2009, mobile computing and, with it, support for supervisory control and data acquisition (SCADA)³⁵ and Cloud computing (see chapter 1) in 2010. A company may plan its IS properly, but by the time the IS are delivered, or maybe even beforehand, the new IS may need to be adapted to support new, originally unexpected but now essential technologies.

The theoretical literature is replete with hypothetical models of how to deal with such contingencies, discussing models of renegotiation and joint ownership.³⁶ These models are not widely used in companies we discussed IS outsourcing with. The industry often addresses this either by signing a new contract for the changes and additions or through signing the original contract as X+Y contracting (see chapter 1). In X+Y contracting, once the contract has been signed, the original requirements are frozen as is and then developed typically on a fixed price basis (the X), while additional requirements and changes are addressed as a separate phase in the contract (the Y), usually based on time and materials. Other options include splitting large projects into a set of interrelated smaller ones.³⁷ Having the scope and length of each phase shorter allows companies to adjust their requirements of the next phase to unexpected contingencies. This was typical of IS project management³⁸ and is used in outsourcing, too.³⁹ In addition, there will likely be fewer unexpected contingencies when the project is shorter. It is all a matter of the KISS principle, standing for “Keep it simple, stupid!” You control your risks by avoiding complex contracting.⁴⁰ Otherwise, the way CIOs interviewed deal with this issue is through creating a trust-based relationship with the agent, just as in the case of dealing with moral hazard risks. CIOs augment the formal contractual controls with implicit informal controls as well, such as developing joint values, shared beliefs, rituals, and social connection with the agent.⁴¹

The Agent’s Side in Agency

Agency theory deals with the theoretical aspects of contracting from the perspective of the principal. This does not mean by any stretch of the imagination, however, that the side of agent in outsourcing contracting is not crucial. Moreover, even from the principal’s perspective it is important to understand the agent’s side—not only because the agent is obviously a key player in this relationship and things will not work out without it but also because to properly understand the strategy and the options of the principal itself one must understand the agent. The saying, attributed in part to the Earl of Chesterfield, may claim, “He who pays the piper calls the tune,”⁴² but in reality the piper in the 21st century, as perhaps opposed to the one in the 18th, can, and in the case of outsourcing often does, choose whom to play for. A more accurate saying would be “It takes two to tango,” or, in this case, to make an IS outsourcing contract a success.

The underlying issue facing the agent in an agency situation involving outsourcing parallels the one of the principal, namely, information asymmetry and the risks this entails, although in the case of the agent this information asymmetry is because the principal knows more than the agent does. Although agency theory does not explicitly deal with these risks or call them adverse selection, moral hazard, or unexpected contingencies risks, the agent must still contend with a principal who knows more than it does about the business environment and the project and who has its own objectives in the relationship—objectives that are by definition almost always not the same as those of the agent. Let us examine these risks and their consequences.

Paralleling adverse selection risks, before the contract is signed the agent has only partial knowledge about what is required and what the principal really expects. The RFP may be detailed, as indeed it should be, but there is often much informal information that needs to be considered beyond what the RFP contains and beyond what the principal tells about itself. This includes internal politics, and it is typically politics and not technology that makes IS projects fail,⁴³ and it is typically politics that determines the nature of outsourcing relationships and their success.⁴⁴ This missing information may also relate to the technical details of the project. And so, while the agent knows a lot based on the RFP itself—as well as other information it could and should glean from the principal based on formal inquiries, publications, informal chats, other partners, its own prior work with the principal, or any other source—deciding to bid on an RFP remains a decision made with only partial knowledge. Add to this that deciding to bid is not just a matter of to bid or not to bid and the price it takes. It is also, no less importantly, a matter of what personnel to commit to the proposal. An IS RFP is not necessarily won based on price alone. Rather, the principal often reviews, in tandem with the price, who the key agent’s personnel are, even to the extent of actually interviewing the key personnel the agent proposes to assign to the project. As a result, it is not necessarily the lowest bid that wins.⁴⁵

Another equivalent of adverse selection risk is that bidding is expensive. The agent needs to invest time, meaning money, in understanding the RFP and the principal and, based on this understanding, determine the bid amount and maybe even recruit key personnel to make its bid as attractive as possible. This is a considerable investment, and there is the constant risk that someone else might win the RFP or the principal may withdraw it altogether. The agent needs to choose whom to even consider bidding for. Basically, the agent needs to know that the principal will be a “good” client. If the principal is going to be mired in internal politics, or is not committed to the project despite publishing the RFP, or is unable to guarantee that the necessary key personnel on its own side will commit enough time to the agent (something the agent should demand in the contract), or does not quite know upfront exactly what it needs, or has unfounded ideas about how simple IS projects are, or is unaware of how much it does not know about its own business, or tries to externalize (i.e., pass the responsibility on to someone else) its own IS headache, or has a myriad of other issues, then the agent is taking a higher risk when making its bid. This is the equivalent of adverse selection risk.

Of course, the more risk the agents face because of the principal, the fewer agent companies will bid on the RFP. Fewer bidding agents is bad for the principal because the best agents, being able to pick and choose whom to work for, might decide the risk is not worth the profit and so decide not to participate in the bidding. This might result in more adverse selection risk to the principal in that the leading agents, those with the key personnel the principal really needs for the project, might not take part. Moreover, those agents who will participate in the bidding are more likely to charge higher rates to compensate for this additional risk. It is imperative, therefore, for the principal to understand the risks the agents are taking and manage the agency relationship accordingly.

The moral-hazard-equivalent risks the agent is taking bear themselves out during the project itself. If the principal does not do its part and share information as it is supposed to—for example, by not providing access to key information and personnel and by inadequately testing the software before its release—then the project could be prolonged or even fail, and this might cost the agent a lot of money. Add to this the unavoidable and expected unexpected contingencies risks, which often require the active participation and support of the principal to solve, and it becomes obvious that agents need to be careful whom they agree to work for.

What Agents Do

Software vendors know these risks very well, even if they do not mask these in theoretical terminology. Many software vendors double-check each RFP they are interested in to verify that the principal will be a client they can work with. Software vendors also usually take extensive safety margins when making a bid, just to make sure that if the principal forgot something or if unexpected contingencies arise, they can still meet the deadline and deliver within budget. It is simply not worth the cost and bother and bad PR to quarrel with a client. This type of risk is exacerbated because of the nature of software: Things always go wrong and software is always more complex than initially thought. Although theoretically the agent can share these risks with the principal through ex post facto renegotiations,⁴⁶ this is not the common practice, and it is the agent who is forced to bear these risks.⁴⁷ In the 1970s and 1980s when computer glitches, “bugs,” in the vernacular of the time, were still the focus of much research it was estimated that by the time the software reaches the testing phase, which is after it has already been debugged by the programmer who wrote it, there are still about 2.36 bugs for every 1 kilo line of code (KLOC) on average, depending on the type of software being developed, although this will vary based on the type of bugs.⁴⁸

A key step agents take to address this risk is to prefer principals they have contracted with in the past. This allows the agent not only to select principals whose needs match its own skills⁴⁹ but also to know better what the principal wants and is capable of delivering.⁵⁰ Notice how this parallels principals’ strategy of also preferring agents they worked with in the past.

One way this is done is by making the bid price more attractive—another reason principals want to know what risks the agent faces. Hard data on relative pricing is secret and not available, but a hint of what this might be like can be found in large-scale online software markets, such as Rentacoder.com.^* In a supplement to our study of that company⁵¹ we found compelling evidence of this two-way preference. This is shown in Figure 4.1, which shows the relative price paid for the winning bid compared with the other bids on the same tender as a function of how many previous contracts there were between the particular buyer (principal) and coder (agent). Rentacoder.com is a marketplace where buyers place tenders with descriptions of short software projects they want written and where coders then bid on these tenders. The buyers are not compelled to choose the lowest, or indeed any, bid. Once a bid is chosen the buyer pays the amount into an escrow account that is managed by Rentacoder.com. On the completion of the project to the satisfaction of the buyer, the money in the escrow account is paid to the coder. All contracts are fixed price, and there are no post hoc renegotiations. This is an international market, although most of the buyers are from the United States. Notice how after having one previous contract with the particular buyer the coders typically give a significant discount, showing their preference for buyers they have worked for before. Also interesting, this discount quickly turns into a premium, showing that buyers also value having such previous contracting and are willing to pay for it. Also interesting is how offshore coders initially give a discount compared to U.S. coders to attract buyers who are mainly in the United States. Once the buyers’ concern about the coder being foreign is relieved based on experience, the offshore coders quickly raise their prices.

Choosing which RFP to bid on, applying due diligence in learning all that can be learnt about the principal ahead of time, and knowing how much of a safety margin in the pricing and scheduling to take on those RFPs the agent does bid on are steps agents take to control their risk prior to signing the contract, which is their equivalent of adverse selection risk. Addressing their equivalent of moral hazard risk is another story. Moral hazard occurs because of information asymmetry after the contract has been signed. Here the contract has been signed and the agent is now obliged to deliver, but the agent often needs the principal to share its private information and approve access to its key personnel so the agent can have access to knowledge it might need beyond that available in the RFP to make the outsourced project a success. It also means that the principal is willing to invest its own time and effort in the process, for example, by seriously testing the software being created and helping resolve the sometimes inevitable conflicts between what the requirements say and what the users really need. Protecting against such outcomes is not easy. Basically, an agent cannot be certain that the principal will meet all its nonfinancial obligations on the software development activities once the contract has been signed—and yet, in order to do its own share of the work properly and be paid for it, the agent depends on the principal doing precisely that, and in some cases more than the contract requires, during this process. These risks are increased because, if something goes wrong, it is the agent who is the likely candidate for blame. It is the agent who is the outsider in these projects, and it is always easier to blame the outsider.

Figure 4.1. Business familiarity and discounts that agents give.

There are many steps agents can and do take to reduce their equivalent of moral hazard risks. Managers on the agent’s side, just as any other manager, need to control their risks. The first step to control risk of any kind is to be able to define and measure it. The same applies to agents in outsourcing contracts, too. In practical terms, this means keeping track of the progress of the project with tools such as Gantt and Pert.⁵² Being able to answer the principal at any given moment as to where things stand and what comes next and how progress matches plans is crucial not only for good management but also for building trust. The same goes for constant monitoring of the numeric CSF of the project and of each milestone within it. Closely related to measuring every CSF is to keep documentation about everything. Principals will make mistakes and will change their minds, but if they know the agent has a record of everything then they will be more cautious about blaming and charging the agent for changes of direction during the project.

I took part in one outsourcing project where the principal complained to us, the project managers on the agent side, that there were too many glitches in the system we were delivering. This was not a malicious attack or anything. It was a standard periodic project governance meeting of the managers on the client and vendor sides to assess where things stood. Answering this would have been impossible under normal circumstances without having collected measures all along, because there are always problems so who can tell if there are too many. Fortunately, as the manager in charge, I continually collected such data, so when the question came up I could confidently relate the numbers. In this case I said up front that we had so and so many KLOCs and so and so many glitch reports, and, by the way, about half were missing specs and not our errors, and so it added up to less than the industry standard of 2.7 glitches for every KLOC. End of story. We, the agent, had answered the question and, most importantly, showed our professionalism and built trust. It also had an important side benefit. Once the principal knew we could measure their own CSF, they started relying on our numbers for their own tracking of the system. We gave them extra benefits, and they appreciated it.

Which brings us to the next thing agents can, and do, apply, which is building trust. Agents know things will go wrong, and agents know that as the outsider they will be the one blamed for it. That is unavoidable. But if the principal trusts you, the agent, then things will not be so bad. Suffice it to say at this stage that when the principal trusts the agent, the principal thinks more highly of the value of the relationship and the products and services it provides; and when the principal trusts the agent there is also better interfirm cooperation during outsourcing.⁵³ There is also better knowledge sharing,⁵⁴ and all this leads to a more long-term business relationship orientation.⁵⁵ Of course, trust is not free. You need to earn it fair and square based, for example, on keeping your word and being dependable.⁵⁶

Trust building should be directed not only at the managers at the principal who sign off on the project but also at the principal’s users. It is important to remember that when IS projects do not succeed it may be because of technology problems, but when they fail it is most often because of people problems. As one CIO put it: “I can make a project fail, but I can’t make it succeed. For that, I need my [non-IT] business colleagues.”⁵⁷ Building the trust of the users can be a crucial step toward reducing such people problems. In one outsourced project I managed from the agent’s side we created and implemented a new logistics management system. Senior management at the principal loved the new system and signed off on it at the testing phase, but when we started implementing it the users who were supposed to use it vehemently opposed it. I sat with some of them at their warehouse to discuss it (note that this was at their warehouse and not in headquarters, so I was broadcasting a strong message of “I am coming to you”). Apparently, the users felt very strongly that the new IS was not their system because they were not consulted about it, and, worse, they feared the consequences of what might happen after the new IS went into operation. This was a case of us versus them, or, more precisely, white collar versus blue collar at the principal’s organization. It had nothing to do with technical problems or glitches with the IS itself. Still, I heard them out. I even went beyond what I was allowed to do and let them register their problems directly with me, thereby circumventing the white collar quality assurance engineers. I made them know they were part of the process. This built their trust in me, the manager on the agent side. And it broke the us-versus-them barrier. Years afterwards studying another company I could show what happened there:⁵⁸ by being responsive an agent can create a sense of shared values and of being one team, which in turn increases the users’ acceptance of the new system. This is not a unique idea. I have seen many project managers on the agent side behave so, realizing that you also need to buy the users over to your side. This is helpful because, as a manager with the agent, you want the users on the principal side to be willing to go the extra mile for you.⁵⁹

Agency Costs

When considering IS outsourcing through the lens of agency theory it is necessary to also consider agency costs. Outsourcing vendors will sometimes claim to achieve a 50% cost reduction. On account of cheaper wages in low-labor-cost countries this may be true, but when factoring in the additional costs the principal incurs when outsourcing this number is closer to 20%.⁶⁰ Among these monitoring costs—that is, transaction costs the principal incurs to make sure the process controls are within the contractually agreed range—are the direct costs of overseeing the agent, costs of verifying quality produced by the agent, administrative costs in contracting and checking reports and ongoing meetings with the agent, and costs in dealing with contractual breaches. These extra activities are needed because the agent has its own objectives and must therefore be overseen. Of course, the agent also has its own costs in monitoring the principal, and for the same reasons. These expenses are apart from costs the principal may incur if something goes wrong, such as taking protective measures in case the agent does not deliver or bungles the work.

Other costs the principal needs to think about include learning costs.⁶¹ Learning costs are the costs the principal incurs as it learns how to outsource in the first place and how to outsource with the particular agent. This is about learning what outsourcing is and not about how to manage such a relationship. These costs are much higher among principals who never outsourced their IS beforehand. Investing in this learning is essential because, as with other learning processes, outsourcing may not succeed the first time around and almost certainly the principal will make mistakes. Not only are these mistakes potentially costly, but reducing their occurrence and impact by hiring experts to coach the principal will itself add to the cost of the project. A consistent message both CIOs and practitioner books give is, do not outsource if you do not know how to. Learning costs may seem prohibitively expensive, but avoiding them is risky.

Then there are also the resource costs.⁶² Included in this category are costs the principal will incur in employing the right people and placing them in the right positions to oversee the agency process. This includes having the right project leadership, which is not simple because the kind of manager needed to oversee the agent is not the same kind of manager needed to oversee on-site operations. It is about having a manager who knows what is needed and how to convey this, rather than a manager who knows how to do it and micromanage. It is key to have the right person in charge.⁶³ Also included in this category are communication costs and verification costs. Add to these the finance costs of contracting with the agent, the legal costs of writing the contract, the operational costs of actually overseeing the agent, and the cost of doing business such as writing and publishing tenders and then selecting among the bidders, and these costs too can be quite high.

Another category of costs is bonding costs,⁶⁴ namely, what happens if the vendor makes a mistake and how much will it cost to correct it? This category is not always fully appreciated by non-IT managers, but it is central to the way IS project managers think. This is crucial because the cost of a glitch in software, outsourced IS projects included, is not primarily in the cost it takes to correct the software. That is negligible. What really counts is the cost to correct the data that may have been corrupted or the cost of lost opportunities and fines because the software was not ready in time. Think of a large bank. If the agent made a mistake and as a result the bank paid interest at a higher rate than it should have, the bank cannot just go and correct the clients’ balance sheets. That is illegal. The bank, should it decide to damage its reputation irrevocably, would need to seek permission and then run transactions to correct the data. That is the kind of risk managers in banks are really concerned about. Paying slightly above market price is not their main concern.⁶⁵ This concern is real. As Figure 4.2 shows, often the release of new software, even if it itself is correct, may cause glitches in other parts of the system, especially when adding new application to an existing system. In Figure 4.2 the period delineators separate the data into three periods. The first is right after the release of the new IS when the IS team was struggling to stabilize the new system. The second is when the system was stabilized and new features were added within the scope of the original requirements. In the third period new applications were added beyond the scope of the original topics in the requirements. The second and third periods correspond to a typical Y section in an X+Y contract (see chapter 1). Interesting to note here in regard to bonding costs is that in the second and third periods there is a much higher percentage of software problem reports that relate to problems caused by previous corrections. In other words, as the software evolved, an increasing number of changes had to be released to deal with correcting previous erroneous corrections, or to add aspects missed in previous parts of the system, so they could now accommodate the newly added applications. This is not uncommon. New releases often result in new glitches.⁶⁶

All added in, a typical promised costs cutting of 40% made by the agent may end up more in the range of 20% on account of those costs.⁶⁷ Some industry estimates place learning and monitoring costs in the range of at least 1% to 5% of contract value.⁶⁸ In fact, in a recent CIO roundtable I co-managed, the CIOs placed the saving as low as 10% and added that it is cheaper to actually hire new people and do everything in-house than to outsource if the company plans to hold on to these personnel for the long run. When these CIOs of large companies have their choice, they would rather apply internal outsourcing where the projects are sent to sister organizations and offshore development centers that are part of their same organization. Industry reports support these observations: among companies who did outsource their IS, 64% have brought at least some of the outsourced IS services back in-house.⁶⁹ Interestingly, although data security is harder to achieve when outsourcing, and it is harder to manage, and vendors may lack industry-specific knowledge, still, 28% of companies sampled by InformationWeek planned to increase their business process outsourcing, 36% planned to leave it at its current rate, and only 7% planned to decrease it (27% either had not considered it or had no intention of doing it, and 2% planned to start).⁷⁰

Figure 4.2. Evolution of software problem reports: a case study.

Source: Adapted from Gefen (1991).

Another set of considerations—and the indirect costs these amount to—that principals need to consider relate to the need to make sure the agent is satisfied. If the agent is forced to bid too low, then chances are the agent might cut corners in the software development process so as not to lose money. With the agent enjoying its own information asymmetry advantage, there is little chance the principal will know of it. The agent can cut corners in many ways that may be detrimental to the principal. Some obvious examples include shifting its best personnel, and therefore more costly ones, to other projects. Other steps agents could take to cut their costs include not going through as thorough a testing as they should. Unless the principal has someone on site, there is little chance the principal would ever notice unless something went really wrong. By pinching pennies, and making the agent unhappy because of it, the principal can lose dollars. This is no mere point. According to industry sources, Osterman Research and Electric Cloud, 58% of 144 professional software developers in the United States said it was inadequate testing rather than design problems that cause problems in delivered software—and that while it only took on average 20 programmer hours to correct the bug, the lost revenue it caused amounted on average to $250,000.⁷¹

As many CIOs I talk to say, outsourcing is not a zero-sum game. The contracting needs to be a win-win situation, and sometimes the principal needs to be willing to pay the little extra to make that the case. Moreover, in contrast to the principal’s own employees, the agent’s employees owe their loyalty to the agent. If anything goes wrong or if anything is missing in the requirements these agent employees will report it to the agent. It is too much to expect them to report the problems to the principal. The principal should therefore want the agent to encourage its employees to keep their eye open for any potential problems. Unless there is a special long-term relationship with the agent, it might be too much to expect this. No less serious than keeping the agent happy is keeping its personnel who actually do the work for the principal happy. With an attrition rate of as much as 30% in some Indian offshore software vendors,⁷² it might even be too much to expect these employees to be loyal enough or care enough to report even to the agent company that employs them. Addressing these agent employee turnovers is not easy, but principals can require the agent to pay fair wages and maybe even prefer agents who have a profit-sharing scheme with their employees.

The Risk and Costs of Continual Improvements

Outsourcing IS development or maintenance presents another set of risks and the cost to address these risks. This is the risk and cost of continual improvements. It can be thought of almost as a truism in IS management that good systems never rest on their laurels. If the IS serve their purpose and are used, then users will identify new opportunities and request to expand the original scope of the requirements. Figure 4.3, based on the same project as is Figure 4.2, shows a case study of such a project. After the IS were released and the users started using the system, there was a continuous stream of requests for additional applications, and this was in addition to adding new features to existing applications. As these new applications were released, corrections had to be made in the existing IS to accommodate for connectivity to these new applications and to resolve bugs these new applications either revealed (now that the domain of the existing applications was expanded) or caused (e.g., by changing the possible values the existing applications expected in the database and so causing run-time errors when unexpected values were encountered) in the existing applications. This is to be expected in a successful IS project—but it does make planning very hard, because while IS management can schedule the release of new IS applications, it must immediately deal with the bugs the release of these new applications causes in existing applications. Bugs must be dealt with quickly because the real cost of a bug is in the damage it causes to business operations, to the data, and to missed opportunities. To demonstrate this point, industry sources estimate the cost of a bug in terms of the lost business and the damage it causes to be as high as $250,000 on average, which is by far more than the average of only about 20 work hours it takes to repair it.⁷³ This may be no exaggeration. In 2002 the Singapore bank DBS Bank outsourced its IT infrastructure services in Singapore and Hong Kong to IBM. In July 5, 2010, a human error by an IBM employee erroneously ran a recovery procedure on the storage system that knocked out the entire IS of the bank for 7 hours, blocking all ATM activity and affecting the bank’s commercial and consumer systems.⁷⁴

Such a need to continually modify an existing IS can present the principal with a conundrum. It is hard enough to manage continuous corrections and additions in IS that are developed and managed in-house, especially when new applications create unforeseen bugs in previous applications that must be dealt with immediately, and especially as users expect these new applications to be ready by yesterday because they do not always understand that enterprise IS are not as simple as programming a function into Excel. Doing so through outsourcing is much harder because the agent must be part of the process, too. In the case of time and materials, this means allocating more hours, which the agent may not have or the principal may not have budgeted for. In the case of fixed price contracting, this may mean a need to negotiate an addendum to the existing contract with all the delays and legal constraints involved. Moreover, it is by no means always clear whether the new bugs revealed in the previous applications were there all along but simply not found yet (in which case it is usually the responsibility of the agent to mend them) or whether these are new necessary corrections, and not bugs, to existing applications to accommodate their connection to the new applications (in which case the agent can demand additional payment). This makes the agency problem much harder to manage.

Figure 4.3. Nature of software problem reports: a case study.

Source: Adapted from Gefen (1991).

Summary of Main Point in This Chapter

In chapter 1 we introduced the outsourcing mind-set, the need to understand and control risks. In chapter 3 we then introduced the concept of the technology imperative. In this chapter we introduced agency theory and its expansion to deal also with the agent’s side. The three ideas are interrelated. Agency problems are exacerbated through outsourcing. Because outsourcing is the purchase of externally produced goods or services that were previously produced internally,⁷⁵ there is an inevitable loss of control by the outsourcing company even if the contract allows for control and the vendor honestly submits progress and problem reports. The key is to manage the relationship with the agent so that the risks are known, managed, and acceptable to both principal and agent. This means principals need to outsource constructively, concentrating on decreasing the cost of ownership of IT, shortening time to market, increasing flexibility and innovation through IT, supporting the required IT functionality need for mergers and technology shift, achieving a strategic potential or competence, and avoiding making the high investment on IT possible because it is cheaper for a vendor to do so.⁷⁶ Still, although there are many good rational reasons to outsource, there is also the irrational bandwagon effect:⁷⁷ CIOs or their managers think it is a trend and an accepted way of doing business nowadays, and so they jump on without realizing what it entails.

In Lieu of a Boilerplate

In continuation of the structured guidelines in the previous chapter, here are more steps to follow as discussed in this chapter.

Step 4: Know your agent and treat the agent with respect.

1. Know your adverse selection and moral hazard risks.
2. Know how you may plan to deal with unforeseen contingencies during the development and implementation phases of the IS, and fully expect that if the IS are a success then there will be pressure from the users for additional functionality and modules, which will be harder to supply if the process is done through outsourcing. Additional time and materials contracts or going in the first place with X+Y contracting could be options to handle this.
3. Determine how and what to measure to keep track of your CSF.
4. Identify ways to measure and monitor the agent, including a liaison.
5. Understand what makes the agent tick and how therefore to encourage it to play your way.
6. Make sure it is a win-win situation for the agent, too.
7. Understand the pricing policy the agent is applying.
8. Calculate and monitor your costs.
9. Expect, and take steps to deal with, expanding requirements.
10. Do not believe in 40% cost savings. If it is too good to be true, then it probably is.
11. Know how to manage the relationship on more than a costs saving basis only.