Applications Outsourcing Pricing – Part 3


As noted in our previous blog postings on the subject (Applications Outsourcing Pricing – Part 1 and Applications Outsourcing Pricing – Part 2), the most prevalent model for pricing applications outsourcing services involves the following components:

  1. a fixed monthly charge for applications maintenance and support;
  2. a fixed monthly charge for a baseline number of application enhancements hours (typically included as part of the fixed fee for applications support) with authorized incremental hours charged on a time and materials basis; and
  3. a framework for pricing significant development work on a project-by-project basis on a fixed fee, capped time and materials, or straight time and materials basis.

This is the third of three blog postings that describes the basic features of each of these pricing components, and discusses some of the key considerations in structuring and negotiating them. The first and second postings discussed pricing for applications support and applications enhancements. This posting focuses on the framework for pricing applications development projects.

Core Development / Testing Staff

Applications development projects are generally priced on a case-by-case basis and, in some instances, competitively bid. Although individual projects are priced on a case-by-case basis, in an applications outsourcing arrangement customers often purchase a core dedicated applications staff for a flat monthly fee to handle a steady state level of expected project work. A core dedicated team can provide continuity that enables higher levels of productivity and quality. In addition, suppliers are assured of full utilization of these resources and thus able to provide deeper discount levels. The time expended by core development team resources can be allocated to individual projects and credited against the charges for those projects. With reasonable advance notice, the customer should be permitted to increase or decrease the size of the core team without penalty.

Estimation Process

Business Requirements – The estimation process for an applications development project starts with the customer working with the supplier to define the business requirements for the project. Typically, there would not be a separate charge for the supplier to prepare an estimate (particularly in a competitive bid). For large complex projects, however, a detailed assessment may be required for the supplier to provide a meaningful estimate of the resources, effort and associated cost of performing the project. In those cases, the supplier should provide a separate estimate for the assessment and, at the conclusion of the assessment phase, prepare an estimate for completing the project within a reasonable range of accuracy.

Estimating Tools – A key challenge for customers is determining whether the supplier has provided a reasonable estimate of the level of effort required to perform a project. In the absence of a competitive bid, there is a natural tendency for the supplier to estimate on the high side, particularly with fixed fee or capped time and materials pricing. Prior to selecting an applications outsourcing supplier, the customer should evaluate the tools the supplier will use to estimate the level of effort and associated costs of projects. The customer should insist on visibility into the inputs and outputs of the tools used by the supplier to estimate project work. On an ongoing basis, actual results should be tracked and compared with estimates to refine application of the tools for future estimates.

Competitive Bids – Customers should consider putting large projects out for bid whenever it is reasonable to expect that other suppliers could be competitive with the incumbent. Our clients routinely obtain lower pricing from incumbent suppliers when work is put out for bid. Bidding out work from time to time also sends a message to the incumbent supplier that it should not assume its position is secure.

Pricing Models
There are three basic models for pricing applications development projects with a large number of variations and hybrids. The three basic models are as follows:

Fixed Fee – A fixed fee is the most common way of pricing a development project but presents certain challenges and risks. The primary challenge is that the requirements for the project need to be defined at a sufficient level of detail for the fixed fee to be meaningful; otherwise, there is a substantial risk that there will be disputes as to whether a particular item represents a further definition of the high level requirements included in the Statement of Work or a scope change. This risk can be mitigated (although not entirely eliminated) through various mechanisms, such as:

  • limiting the customer’s initial commitment to the project to satisfactory completion of the requirements phase, including the customer’s acceptance of any modifications to the fixed fee proposed by the supplier coming out of that phase;
  • building a materiality threshold into the change control process (i.e. no adjustment to price unless a change requested by the customer is reasonably expected to have a material impact on schedule or the cost of performance); and
  • adding appropriate “catch-all” requirements in the Statement of Work (e.g., the new application must include all of the features, functionality and capabilities of the legacy application it is replacing).

Of course, where practicable the best approach is to invest the time upfront with the supplier defining the requirements for the project at a reasonable level of detail before committing to the project.

Capped Time and Materials – Fixed fee pricing also presents a risk that the customer will pay too much in relation to the level of effort required to complete a project. A more favorable arrangement for the customer is to be charged on a time and materials basis up to an agreed cap. This ensures the customer pays only for the time actually expended by supplier personnel and shifts the risk to the supplier of completing the project on budget. Not surprisingly, suppliers are very reluctant to agree to this pricing model.

For projects in which the supplier has significant accumulated experience to draw from (e.g., implementation of the supplier’s proprietary software for the customer), it is reasonable for the customer to insist on capped time and materials pricing. The harshness of this model for the supplier can also be mitigated by risk / gain sharing above and below the cap. For example, the parties could agree that the customer would pay only a percentage of the supplier’s charges above the cap and the supplier would be paid a premium for completing the project under the cap. In addition, the supplier also has the protections afforded by the change control process (i.e. the cap would be subject to adjustment for material scope changes requested by the customer).

Straight Time and Materials – Straight time and materials pricing shifts the risk of project costs to the customer. It is generally used when the customer’s requirements cannot be defined sufficiently upfront for the supplier to propose a meaningful fixed price or cap. It is not uncommon to price detailed requirements definitions (e.g., SAP Blueprinting) on a straight time and materials basis. This pricing model does provide flexibility for the customer to change the scope of the project without the “overhead” of having to negotiate adjustments to the fixed fee or cap, and in some instances our clients have felt that they can more effectively manage the supplier’s spend on a project under this model.

However, straight time and materials pricing does not provide an incentive for the supplier to perform work efficiently and suppliers often argue (incorrectly) that they cannot be held accountable for successfully completing work on time in accordance with the project requirements and schedule under this pricing model. As a general rule, we have found that fixed fee or capped time and materials pricing produces better outcomes for customers.