Looking Outside – Outsourcing IT Application Development

by Ed Carroll, executive, Agilis Solutions

During the dog days of summer, as the economy softened, with revenues shrinking and budgets tightening, some CEOs asked their CIOs, “can’t we outsource that application development?” Large companies have outsourced many IT functions in the past and have seen successes with some of these efforts, but for various reasons have maintained ownership of application development. However, software companies, in contrast to large IT shops, have successfully outsourced application development for several years. Perhaps the large IT shops have taken notice. Several large companies in the Portland area are currently investigating the pros and cons of outsourcing application development. Since there are some significant horror stories about failed outsourcing attempts, it is worth considering how to avoid a bad outsourcing experience.

Outsourcing is a partnership, not a marriage
As those who have successfully outsourced application development know well, outsourcing a part of the business is not like buying a software license. Outsourcing application development will be a partnership arrangement that will require give and take from both parties. Contracting for a license involves a tangible thing (the license); go ahead and squeeze that turnip. However, contracting for application development services is contracting for a very intangible thing; squeeze that turnip too hard and failure is guaranteed – if not sooner, then later. As in any services partnership, success happens when both parties are clear on and agree to the goals and objectives of the other partner. This means an alignment of corporate, cultural, and financial goals, as well as details such as project cost, schedule and quality.

A win-win contract is critical to the success of an outsourcing partnership. In a win-win contract, both sides remember to leave enough on the table during negotiations to keep the other party interested in the deal for the duration of the contract. On the other hand, a business outsourcing partnership is not a marriage. One side is still the client and the other is still the provider, and it is just as important to maintain that perspective too.

I once managed a contract where the provider forgot this perspective. When we (the client) told them (the provider) that we were dissatisfied with their performance, they lamented, “but we thought we had a partnership here.” I guess they felt that a partnership did not mean they had to live up to the expectations defined in the contract; they soon learned otherwise.

Building trust over multiple interactions
One difficulty in putting together a partnership is that some people do not understand that the basis of the partnership is trust, and that trust does not just happen because of a competitive bidding process. Trust happens over a long period of time and through multiple interactions. For this reason, competitively bidding for application development services is a fallacy in conception. The fallacy is in the assumption that two or more service providers can be compared “apples to apples.” For example, if two or more companies bid the same price to develop an application, how can it be determined which company will deliver on budget? If they each bid the same duration for the project, how can it be determined which will deliver on schedule? And of course, how can it be determined which will deliver code on schedule, on budget and with the fewest defects?

You can (and should) talk to references, especially those with an existing relationship with your company (an example of trust building). However, references are only a partial indicator. Beware of references that have not actually used the services of the prospective provider.

You could look at code examples from the provider’s previous work, if available. However, sample work may not be available if the provider only develops applications for other companies, and not for sale through its own channels. Some providers consider it part of their IP protection policy to not give out information belonging to their customers, and some customers contractually restrict the provider from showing work to another customer.

Build a trust bank
An alternative approach might be to establish a trust bank by building relationships with several providers specializing in the areas of interest. Look to trusted, existing sources for referrals and select the top two or three providers. Contract with all two or three to develop a pilot application; something of high value, but not mission critical. If that pilot project goes well, then extend the contract to another project, perhaps a little more important or a little more challenging.

Divide the work needed into the same number of “pots” as the number of pilot project providers. In the first pot, place several small, but not too small, discrete (separate and independent) projects that have high value to the company, but are not mission critical. These are the pilot projects useful to “test and initiate” the relationships between your company and a potential partner. In a secondary pot, place the other, more important projects – these will be delayed until a potential partner proves itself trustworthy enough to take on these larger, more mission critical projects.

As these pilot projects progress, the trust relationship between client and provider will also either progress or decline. If the relationship declines, then either reduce the next effort, or cancel the relationship. If, on the other hand, the relationship progresses, then expand the next effort until the comfort level exists to establish a true partnership (greatly expanded, long duration contracts).

Weighing process vs. talent
Recall that it is important to be clear on the goals and objectives supporting the desires to outsource. An executive of one large company I know of has stated that they want to outsource their application development in order to use their external resources more effectively. Currently, this large company outsources many operations: IT support, system administration, application maintenance, product manufacturing, logistics, etc. However, they have resisted outsourcing application development in the past, preferring instead to manage projects internally and to hire individual contractors when internal resources (or head count) are not available. They have stated that they feel these resources hold the interests of the business at their heart, “something that no outsider could match.” Although this is a compelling argument, it ignores the interest of a true partner to meet the needs of its customer – which can be as strong a motivator as any internal resource might hold, if the goals and objectives of both partners are clearly understood and aligned.

An advantage that internal resources bring to the table should be an ingrained understanding of the internal processes the large company employs toward the development of applications. Most companies focus their attention on the processes specific to developing and marketing their commercial products and services. However, unless the company is in the business of developing and marketing software applications, that focus is on the development and marketing of something else. Without this focus, non-related areas, such as IT (and especially a small segment of the IT department – application development) do not receive the attention (infrastructure, funding for tools, training or higher talented personnel) necessary to be a world-class operation. This is a very common reason to outsource – to seek out a partner who has a focus on the area of need and who can therefore provide a better product or service.

One trap that is easy to fall into is to assume that talent is sufficient to compensate for a lack of focus. No matter how talented individuals are, they cannot match the repeated effective productivity of a team with well-thought-through processes in the area of interest. For application development, that advantage is exemplified by predictable schedule and budget performance – processes specifically designed to be flexible – that is, to handle dynamic requirements easily, and with far fewer code defects. Partnering for application development can be boiled down to a decision between hiring a partner with the best processes to develop high quality applications, or temporarily hiring talented individuals.

When an executive says he wants to use external resources more effectively, one way might be to partner with a firm who has a focus on the product or services needed.

The big guys vs. one throat
Some executives always want to partner with the big guys; this is where the saying, “no one ever got fired for hiring IBM” came from. The advantage of partnering with the big guys is the presumed access to a very large talent pool, providing the buyer with the best expertise money can buy. The real trick in this game is to ensure that the expertise flaunted actually ends up working on the buyer’s project. More than one large consulting company has the reputation for applying expert talent only until the deal is closed, and then staffing the project with new college graduates.

In application development, large companies often can claim the best industry practices and the certificates to prove their claim. The danger is to assume that those certifications apply to all of the thousands of employees. Sometimes an entire company will get the credit attributed to a single team.

On the other hand, a small firm offers the advantage of the attention of a high-level executive with the power and authority to quickly and easily resolve any issues that may arise (one throat to choke). This is in part the reason that small companies are able to be more nimble and responsive in a dynamic business environment, especially when the demands come from a large client who represents a significant portion of the small company’s revenue.

Perhaps the ideal solution would be to find a partner who could combine all of these attributes – large talent pool, top expertise, availability of that talent to the client, nimble responsiveness, and an accessible and attentive executive whom the client can rely upon to resolve any issue quickly and easily.

Handling dynamic requirements
I know of another large company that has not outsourced application development in the past because they felt their requirements were too dynamic to expect success from an outsourced provider; in fact, they took pride in having dynamic requirements. However, this same company is now considering the pros and cons of outsourcing application development. Obviously, finding a partner who can handle dynamic requirements will be critical to the success of their partnership.

Gathering requirements involves several forms of communications. Recall from my previous articles that 70% of projects fail – mainly due to poor communications. Therefore, handling dynamic requirements should be all about effective communication. Effective communication begins with adopting an attitude about change that assumes change will happen – be prepared ahead of time, understand who needs what communication and have processes in place to ensure that the right people have the right information (see my article Adapting to Change).

Well-documented statistics on communications show that 55% of what we convey is transmitted visually through body language – posture, smile, arm positions; 38% of what we convey is transmitted aurally - tonalities, inflections; and only 7% is transmitted by the actual words we speak.

These studies demonstrate how critical it is for projects to have face-to-face communication between key stakeholders when gathering the requirements for a desired application. The same is true for working through architectural options, as well as truly understanding progress.

Establishing effective onsite and offsite communications
Almost all outsource firms will say that they will put resources onsite, if needed or as required by the client, to gather requirements. Some will fly in a person from their team located far away (US-based or from India/China). The better provider will base a person at the client’s site who is local to the client’s location and culture, and experienced in dealing with the specific offshore team. Sometimes the onsite person will do little more than send work requests back to the team that is staffed and managed in India/China, in effect forming a bottleneck for communication flow. The better providers will utilize onsite personnel who are actively involved in solving the technical problem at hand, forging an effective communication bridge between client domain experts and offsite developer personnel.

Part of that communication is formal and part will be informal – the casual hallway discussions, the quick Q&A while looking over a developer’s shoulder as he works on a prototype, etc. Critical to repeated success will be well-established processes that encourage an abundance of communication. For example, a provider might have processes that require communication with an offshore team be done in triplicate form: a telephone conversation confirmed with an email action item agreement, and followed up with a quick Q&A on Instant Messenger notes for clarity.

Along with the processes to encourage close communication, processes for capturing domain knowledge and transferring it to the development team are equally important. The farther away geographically the domain and developer team members are, the more important it is to formalize the processes to ensure close collaboration.

An executive once told me about an outsource firm (in Asia) who received the initial set of requirements documents and then pretty much did not communicate again until the end of their three-month project – when they delivered their solution. Is it a surprise that the result was not quite what the executive had hoped for at the start of the project?

Conclusion
There are many ways to increase the effectiveness of communications. Consider extending the typical requirements interview and analysis with processes for creating multiple prototypes. Or use an iterative development method that keeps the domain experts engaged on a daily basis with the developers – feeding back questions, ideas and solutions. See my previous three articles on Writing Effective Use Cases for more ideas on which processes are key to successfully defining dynamic requirements on large projects, or my article Why Outsource for more ideas on the pros and cons of outsourcing application development.

Large companies that want to outsource application development would do well to talk with the software companies who have successfully outsourced their software product development. Listen to their stories (some horror, some good) and learn about the efforts they put into making a successful partnership.

About the Author
Ed Carroll has been building software products for more than 20 years, with particular expertise in automating economic analyses, decision support and supply-chain management processes. He has provided strategic technology leadership as vice president of engineering for Egghead.com, director of technology at Nike and director of software engineering at Boeing. He can be reached at EdCarroll@AgilisSolutions.com.