"Outsourcing Issues and Pitfalls"




Copyright © 2005-2007, Cybron, Inc.

Introduction

The purpose for this article is to provide a general description of problems typically encountered while outsourcing a Software Project. Its audience is Business Management, and Program Managers involved in the consideration, planning, and oversight of Software Projects.

The intended effect of this article is to help recognize, prevent, and avoid such problems. The problems addressed in this article are general to Software Development Vendors, but may also be applicable to internal Development Groups. They are based on the industry experience of the author.

Motivations and Interests

It is the opinion of the author that most problems are systemic in nature and solution. Relevant parties can generally be counted on to act in their interests. Conversely, such parties can generally be counted on to not act against their interests. This is very applicable to the problems encountered with outsourcing Software Projects. It is important to consider the motivations and interests of those involved.

This section identifies significant entities associated with software development and their motivations. Its purpose is to illuminate their personal interests in the software development process.

Business Management

Business Management is motivated to meet financial and strategic goals. Their primary tool is cost-benefit and variance analysis.

Business Managers are motivated to provide high value prospects and deliver on those prospects, as a means to grow or sustain their careers. Depending on the Company, they may also be inclined to grow the influence and size of their organization. Business Managers are largely assessed by peer review. Business Managers need projects to behave in a manner that is understandable to that audience.

Software Development Vendors

Software Development Vendors are motivated to maximize the profitability of a project and minimize financial liability while meeting the terms of the contract.

Development Group Managers

Development Group Managers are motivated to plan and manage the implementation of visible and important Software Projects. They usually report to and are reviewed by Business Management.

Technical Advisors

Technical Advisors are motivated to provide information that is valuable and relevant to the interests of their manager, and the Advisor's organization.

Development Groups

Development Groups are motivated to remain relevant and grow professionally by working on and completing interesting and visible projects.

Problems and Pitfalls

Based on the motivations of the involved parties, a common set of problems and pitfalls arise. Each of these problems is directly related to a combination of motivating factors. By describing scenarios in these terms, it becomes easier to understand their nearly inevitable occurance.

Lack of Adequate Planning

Planning a successful Software Project is complicated. Determining a useful and cost effective set of features given so many trade-offs and constraints can be overwhelming. It requires significant technical aptitude and experience. It can be very time consuming. The process does not follow patterns typical of other projects. Small issues may ultimately have very significant impacts. It is the tendency for Business Management to rely on the Development Group to just "work out" these issues during Implementation. The justification for this is that certainly some number of issues will arise during implementation, so a few more won't make much difference.

However, increasing the number of unresolved issues causes the risk of failure to grow exponentially. The basis for this is it allows the Development Group too much latitude to determine feature design. It gives the Development Group reasonable cover to explain cost overruns. It weakens the ability for Business Management to hold the Development Group accountable.

Without adequate planning, such issues will likely arise during implementation and verification that detrimentally impact the value, quality, and utility of the project. The proposed resolution of some issues can completely negate the value proposition of a project entirely, with little equity to be salvaged.

It is important that the Business Manager understand that necessary planning is tedious, involved, and at least equal in significance to implementation. Adequate planning should generate a large list of issues and resolutions. An experienced Technical Advisor is essential to generate such a list. Most of these issues may be readily addressed. The resolution of such issues should be rigorously tracked. All significant outstanding design and implementation issues should be resolved before implementation begins.

Solution: During planning, the Business Manager should continuously monitor the top issues and their resolutions. The Business Manager should be vigilant in ensuring that the proposed features are reflective of the business goals for the project. The Business Manager should encourage a verbose and rigorous planning process.

Passive Internal Resistance

Software Development Vendors are essentially competitors for internal Development Groups and organizations. Client agents managing the outsourced project may actually benefit from its failure or diminished success. Internal Development Groups are not likely to facilitate the loss of their jobs and organizations to outsourcing.

Software Development can be a fragile process. Basically, it is about discovering, assessing, tracking, and resolving issues and information. It relies heavily on professional character, diligence, and opinion. Thus, it is easily impacted by subtle dissention and reasonable deniability. The negative impact of such dissention is nearly insurmountable. Even if the project is concluded within the terms of the agreement, the project may be perceived as a failure based on the informal assessment of a few biased employees.

Solution: Business Managers should be skeptical of the technical opinions and assessments of employees whose interests are not served by the successful conclusion of the outsourced project. When it is necessary to utilize such internal resources, the scope of interaction and significance of assessments should be limited and qualified. Business Managers should utilize Technical Experts and Advisors whose personal interests are neutral or tied to the success of the outsourced project.

Lack of Appropriate and Meaningful Acceptance Criteria

This often refers to performance and reliability criteria. Instability and poor performance may completely negate the benefit of a comprehensive feature set. Criteria such as "performs well" or "reliable" are unenforceable unless accompanied by repeatable procedures for their determination. Inclusion of ambiguous acceptance criteria in the development agreement only serves to weaken the agreement and undermine the vendor relationship.

Some criteria are measurable but not very meaningful or appropriate. For instance, arbitrary determination and inclusion of performance criteria may result in more costly maintenance. Expensive malfunctions are most frequent in optimized code. Such optimizations may use augmented data structures and data caches, requiring more expensive personnel to maintain and augment them later. Finally, external dependencies may preclude the ability to meet such criteria.

Determining and including appropriate and meaningful acceptance criteria facilitates the understanding of both parties as to what is expected. Inspectors can design appropriate acceptance procedures that will promote confidence on the part of the Client. In contrast, inappropriate and ambiguous criteria impede the ability of the inspectors to determine whether the deliverables meet the contract obligations, possibly resulting in arbitration.

Solution: Planners must endeavor to provide adequate and appropriate acceptance criteria. Such criteria should be reviewed and approved by the inspectors responsible for acceptance testing. Inappropriate criteria should be avoided since it will only add cost and complexity to implementation and inspection.

Unrealistic Expectations of Business Management

Often, Business Management does not approach Software Development realistically. This can be a symptom of lessn experienced Business Management not trusting the assesments that experienced Business Managers are providing. There is a prevailing view that previous problems can be avoided, and new problems will not emerge, without significantly changing the process. This just isn't the case. One only needs to review "post-mortem" documents to see that the same class of problems occurs serially.

Software Development is an iterative process of discovering, assessing, tracking, and resolving issues and information. There are almost always significant unresolved issues throughout the process. During implementation, plans will often change to account for an unexpected complication. The elimination of such issues and complications is perhaps the unreachable paradise of Software Development. Such complications are difficult to predict in a defendable way.

Software Development Groups consistently understate the complexity and effort involved. The reasons for this are many and systemic. Business Management develops unrealistic expectations about the complexity, effort, time, and cost of software development projects. They are more likely to trust bids and estimates that support their unrealistic expectations. Phrases like "that's a ten minute fix", or "its just code" only serve to strengthen this misconception. Basing decisions on this unrealistic information is costly and detrimental.

Solution: Business Management should be realistic and pragmatic about Software Development. When planning a project, Business Management should just assume that they are underestimating the time and effort it will require. For typical projects, a 25% to 40% cost buffer is not unreasonable. Business Management should promote an environment where more realistic bids and estimates can be provided. Business Management should determine a reasonable cost schedule for the development of a fixed feature set. Then Business Management should focus on picking the Development Group that will predictably deliver the best value.

Open Ended Implementation Contracts

Accurately estimating development costs is an expensive proposition. Implementation Bids are particularly expensive to produce. Firm Implementation Bids present considerable risk to the Vendor. Firm Implementation Bids require sufficiently detailed Feature Specifications from the Client. Such Feature Specifications require significant time and effort. Historically, projects are rarely planned and specified to the completeness necessary for producing firm bids.

Generally, and certainly in the absence of detailed specifications, a Vendor is motivated to promote contracts which allow for cost overruns and limited liability. This saves expensive detailed cost estimation work and reduces the Vendor's financial risk. The Client is motivated to accept such an agreement as it reduces the pressure to produce highly detailed and stable specifications. It also gives the Client a great deal of freedom to change and alter Features throughout the project.

With such a contract, there is little motivation for the Vendor to provide cost containment and efficiency. If the project goes over budget, the Client is forced to keep paying the overruns or cancel the project altogether. The success of this arrangement relies on the Vendor to act against his immediate interests. However, most outsourced Software Projects are commissioned under open ended contracts. Many such projects are concluded successfully.

Firm bids should be the ideal solution. However, the unpredictable nature of Software Development makes such bids very risky for the Vendors. Firm bids are much higher than open ended bids to account for this risk. Since they require significant upfront expense on the part of the Vendor and Client, they aren't that common.

Solution: Ideally, the Business Manager should minimize using open ended contracts. If the vendors cannot provide firm bids because of lack of adequate detail in the specifications, then more detail should be provided. If firm bids are proposed, then the Business Manager should verify that such bids are reasonably feasible for the Vendor to execute.

Conclusions

Successfully outsourcing Software Development is in many ways similar to other types of outsourcing. However, some general key differences are (1) planning and costing can be as expensive as implementing, (2) altering features and feature sets during implementation is deceptively expensive, (3) it requires significant time, attention, and expertise on the part of the Client, and (4) it is more complicated than it seems it should be.

Software outsourcing issues and pitfalls can be avoided by significant diligence and pragmatism. Detailed planning is key. Frequent and consistent review is a necessity.