application services pricing

8/10/2019 Application Services Pricing

1/9

Conceptual Alternative Approaches to ApplicationServices Pricing

M. A. Parthasarathy, Sandeep Dhoot, Deepak Deb

Abstract

Application outsourcing services pricing is typically based on one of two well-

established models, fixed priceor time and materials.Although different in

approach and purpose these models dominate the global sourcing market by virtueof continuous refinement, ease of use, and the ability to hold firm service provider

costs. For these reasons they are likely to remain the pricing models of choice for the

foreseeable future.

On the other hand there are alternatives to these models that are attracting the

interest of CIOs and IT stakeholders. These include a group of related approaches

that fall under the category ofunit of work(UoW) pricing. Similar to usage- and

user- based pricing models common in IT infrastructure, desktop, and help desk

outsourcing services, the UoW concept is essentially a pay per use approach that

requires the ability to define, capture, and measure the total volume of work units for

application service deliverables.

There are different variants of the UoW model, each based on the distinct

deliverables unique to a particular class or type of application service. These include

new application development, maintenance and support, package implementation,

and testing.

Identifying, measuring, and ultimately pricing these distinct work units requires

close collaboration, mature service management processes, and disciplined

governance on the part of both clients and service providers. In this way it is possible

for both parties to respond and adapt to variations in IT service demand driven by

changing business and economic conditions.

Sep 2009


2/9

2 |Infosys White Paper

Basic Principles of Unit of Work Pricing

The generic term UoW based pricing refers to a pricing schedule where the price for each unit of workis pre-determined.

The simplest example of a UoW pricing is two-part pricingin which the customer pays an initial fixed fee for the first set

of units(an agreed to number or range of work units), plus a smaller constant price for each subsequent unit or bundles of

units.

Although transaction based and usage pricing models have been a feature of infrastructure and BPO outsourcing for some

time, the use of UoW principles in application outsourcing is relatively new outside of application service provider (ASP) orsoftware as a service (SaaS) contexts where per-use or per-seat models typically apply.

With application development and maintenance (ADM), independent testing, and software package implementation,

however, work units are unique to the activities/deliverables that comprise each category or service offering, resulting in

specific UoW variants for each service.

Variants of Unit of Work Model for Application Services

The key to developing specific UoW pricing models for different services rests on the ability to identify, collect, and measure

units capable of reflecting actual work output and service delivery activities. And, even within the framework of a particular

service different work units can be applied. In the case of application maintenance and support (AMS) for example, two UoW

variants have emerged -- maintenance units pricing and ticket-based pricing.

Application development, on the other hand, is based on an often complex series of phases, some of which are less

predictable than others and require greater flexibility to carry out. Nevertheless, there are identifiable and measurable

deliverables defined by functionality; leading to the development of a UoW pricing model based on function points.

Because application testing and quality assurance (QA) services involve the creation and execution of specific processes and

sequential activities, UoW-based pricing models for these services are garnering considerable attention, particularly as test

units provide a definable and measurable basis for consumption-based payment.

Finally, in the area of enterprise applications or packaged software integration and implementation services the fact that

such suites are comprised of different modules, enabling client companies and their service providers to define and agree on

models in which package points are the basis for a UoW model.

Application Maintenance and Support: Maintenance Units and Ticket-based Pricing

As illustrated in Figure 1, application maintenance and support (AMS) activities and deliverables are relatively easily

identifiable and quantifiable, which makes it possible to provide a single yardstick --maintenance units(MUs) for pricing

them on a UoW basis.

Units * x.x

Contract

ServiceProvider

Variable Rate Chart (Illustrative)

MU Units/Qrtr Unit Rate ( US$)

< 250 xx.xx

250 - 275 xx.xx

276 - 300 xx.xx

> 300 xx.xx

Variable Rate Chart (Illustrative)

MU Units/Qrtr Unit Rate ( US$)

< 250 xx.xx

250 - 275 xx.xx

276 - 300 xx.xx

> 300 xx.xx

Billing

Units * x.x

Uni ts * x.x

Uni ts * x.x

Uni ts * x.x

Uni ts * x.x

Break Fixes

Application

Support

Minor

Enhancements

User Support

DB Extracts

Others

Unit: MU

MU Meter

Unit: MU

MU Meter

Figure 1: Maintenance Unit Pricing


3/9

Infosys White Paper |3

Day-to-day service requests such as break/fix, major and minor enhancements, data base extracts, etc., can be classified

into various categories or buckets, each of which can be mapped to a MU measurement unit. In this way the multiplication

(conversion) factor for each category can then be priced based on the average complexity and effort it takes to execute them.

Further, pricing for each MU category would logically be set up to account for increases and decreases in request volume by

applying variable rates.

Similar to the MU approach a ticket based pricing model allows clients to handle AMS service fluctuations and pay only

for actual consumption. That is, by the number of tickets rather than the number of FTEs providing the services per pre-

determined capacity. This model works by taking into consideration different factors such as historical effort, age of theapplication, SLAs, complexity, etc (Figure 2).

Inputs

Inputs

Price/Ticket

Statistical

Algorithm for

Distribution

Fitment

Indirect Pricing ToolTicket Arrival Rate

Tickets Classification

Application Environment

Complexities

Optimized Ticket

Execution Effort

Optimized

Onsite/Offshore

Resourcing

Inputs

Inputs

Price/TicketPrice/Ticket

Statistical

Algorithm for

Distribution

Fitment

Indirect Pricing ToolTicket Arrival Rate

Tickets Classification

Application Environment

Complexities

Optimized Ticket

Execution Effort

Optimized

Onsite/Offshore

Resourcing

Figure 2: Ticket Based Pricing

Given the importance of different factors in calculating the price per ticket in this model, historical client data -- i.e., help

desk / service requests -- for each sustaining applications category for some period of time, typically a minimum of six

months, is an essential part of this model. Once the appropriate data is available the following steps can be applied for

evaluating and ultimately identifying mutually agreeable ticket pricing:

Ticket volumes and distribution (based on types) are used to create a baseline.

By gathering and applying client and service provider experience and industry benchmarks a baseline effort required

to resolve each type of ticket can be estimated.

The estimated effort for each ticket type is then translated into total hours required for supporting the anticipated

work volume.

A resource model is determined based on sourcing strategy and SLA requirements.

These elements can then be used to create statistical analyses using simulation techniques to arrive at optimal staffing models

and ticket pricing, including floor (base) and ceiling limits. Staffing levels and skill sets can then be further optimized to

ensure benefits for client stakeholders, end users, and service provider.

New Application Development: Function Point Pricing

The process of capturing, balancing, and ultimately finalizing new application development requirements is difficult andcomplex even under the best of circumstances. Indeed, it is widely accepted that functional and technical changes can and

most likely will occur at different stages of an application planning and development lifecycle.

Often, the end result is an application that is substantially larger and functionally more complex that what was originally

planned and agreed to by the client and service provider. With a T&M model the cost of the latters additional effort and

resources, barring any not-to-exceed provisions, may end up being reflected in the final price to the client.

With a fixed price model, on the other hand, the additional effort on the part of the service provider, unless anticipated and

accounted for, can have a negative impact on its margins. In either case there is the potential for contractual conflicts.


4/9


As an alternative to these models a variant of UoW pricing developed specifically for application development has emerged

using function pointsas the basic work unit (Figure 3). The idea of function points pricing is based on a software application

sizing model promoted by IFPUG (International Function Point Users Group). At the core, the business functions serviced

by an application is measured in terms of function point count.

10%-12%

SoW Requirement

AnalysisDetailedDesign

Build &Unit Test

Test &Acceptance

12%-15% 25%-35% 30%-40%

IdentifyFunctionality

Early FP count

Full Scope

Baseline FPcount

Final Scope

Full FP count

Revised Scope

Revised FP count

Scope Creep

Revised Schedule

Delivered Scope

Delivered FPcount

FP SizingAccuracy

EffortBreak-up

20% 15% 10%

10%-12%

SoWRequirement

AnalysisDetailedDesign

Build &Unit Test

Test &Acceptance

12%-15% 25%-35% 30%-40%

IdentifyFunctionality

Early FP count

Full Scope

Baseline FPcount

Final Scope

Full FP count

Revised Scope

Revised FP count

Scope Creep

Revised Schedule

Delivered Scope

Delivered FPcount

FP SizingAccuracy

EffortBreak-up

20% 15% 10%

Figure 3: Function Points Pricing

Pricing an application development project based on its function point count gives a unique advantage to the client since the

technology platform, skills of resources deployed and other project execution complexities do not directly impact the sizing.

This particular UoW variant also addresses the pricing ambiguity associated with identifying application functionality,

requirements analysis, and pre-build activities by allowing for re-estimates at the end of each lifecycle stage. Changes in

scope, if any, are suitably accommodated in the pricing based on a pre-negotiated price per function point basis.

Alternatively, the function point approach with the traditional T&M model, applying the latter to early lifecycle stages, e.g.,

requirements gathering and scoping, and the newer option to the actual development and testing activities, creating in effect,

a hybrid pricing model.

Independent Application Testing: Test Units Pricing

Test units pricingis, as the name implies, based on the identification and definition of measurable and quantifiableapplication testing activities or test cases (Figure 4). Similar to other UoW models it can be adapted to fluctuations in volume

and complexity and facilitates payment on a consumption basis. The basic methodology for assessing and creating unit prices

for different types of test cases involves the following steps:

Test cases are categorized by type, e.g., batch testing, installation testing, etc.

For each test case type the activities that comprise it, e.g., batch classification, scripting effort, etc., are identified.

The effort required to carry out and complete each activity is then calculated to produce a total effort estimation for

each test case in question.

Based on the cumulative complexity level of its constituent activities each test case is then assigned its own complexity

level, from which its proposed baseline price is derived.

The baseline price for a particular test case is applied to a single test/release cycle. For subsequent release/cycles the effort

would be reduced based on the lessons learned and productivity gained from the initial cycle.


5/9


Cost Revision/Data Validation/Risk Analysis Core Lean Team

Price per test case execution

based on complexity is

derived while considering

the cycles/releases. Cost

reduction per cycle is also

factored into it.

EffortCalculation

Batch Testing

Installation

DB Testing

UI Testing

Batch Classification

Test case Execution effort

Scripting effort

Release Plan

Number of rounds of testing

Number of test cases per release

Test case complexity classification

Requirements analysis effort

SLA Analysis

Test data analysis

Cost Revision/Data Validation/Risk Analysis Core Lean Team






factored into it.

EffortCalculation

Batch Testing

Installation

DB Testing

UI Testing



Scripting effort

Release Plan





SLA Analysis

Test data analysis






factored into it.

EffortCalculation

Batch Testing

Installation

DB Testing

UI Testing



Scripting effort

Release Plan





SLA Analysis

Test data analysis

Figure 4: Test Units Pricing

It is also worth noting that this particular model also allows for risk-based testing as it provides mechanisms for prioritizing

regression suites based on business risks and available budgets. Variations can also be developed for independent testing and

quality assurance service initiatives or applied testing services bundled with overall ADM outsourcing contracts.

Software Package Implementation Services: Package Points Pricing

Similar to new application development, applying UoW pricing concepts to enterprise application package implementation

and integration services rests on the ability to translate deliverables, i.e., required functionality, into work units.

Since most packaged software functionality resides in individual modules, assessing and identifying the activities involved

(in setting up, integrating, and implementing them) is the basis for determining effort, which in turn is the basis for package

points that is the work units from which pricing is derived (Figure 5).

Complexity

Factor

Implementation

Tasks

Setup Points Functionality

Points

Form Points Field Points

Implementation Complexity

Package

Points

Business Decision Layer

Module

Points

Data Layer

Data

Elements

Aggregate

Aggregate

Complexity

Factor

Implementation

Tasks

Setup Points Functionality

Points

Form Points Field Points

Implementation Complexity

Package

Points

Business Decision Layer

Module

Points

Data Layer

Data

Elements

Aggregate

Aggregate

Figure 5: Package Point Pricing


6/9


Typically, the number of processes and setup activities are specific to functionalities required for each particular module

and this in turn influences the effort sizing for each module. As illustrated conceptually in Figure 5, effort sizing occurs at

different layers within a software package.

The output of each layer assessment is then aggregated and applied to the layer above it to the point where the complexity

factor and implementation tasks for each required module is used to determine the overall implementation complexity and

price for each package point.

For example, setting up a modules processes is done through front end layers called forms. Each form will have someelements to be configured to implement certain functionality, done through either standard offerings or customized

development as per the customer needs.

Customized programs, reports, interfaces and data migration could be part of the customized development done in package

implementation projects. Naturally, the number of and complexity of these and other customization activities are also taken

into consideration during the process of determining the effort and price for each package point.

UoW Pricing Preparation and Deployment

Although the basic concepts underlying UoW pricing are not new they have only recently begun to be applied to application

outsourcing services. Indeed Infosys experience indicates that the level of adoption of the models described in this paper

varies considerably (Table 1).

Medium LowHigh

Type of UoW basepricing model

Ticket Based Pricing

Test Units (TU)

Function Points ($/FP)

Package Points

Maintenance Units (MU)

Level ofadoption

Applicability (appropriateservice engagements)

Application Maintenance &Support

Independent Testing Services

Application Development

ERP and Other PackagedSoftware (SAP, Oracle Apps etc)


Medium LowHigh Medium LowHigh

Type of UoW basepricing model

Ticket Based Pricing

Test Units (TU)

Function Points ($/FP)

Package Points

Maintenance Units (MU)

Level ofadoption

Applicability (appropriateservice engagements)


Independent Testing Services

Application Development

ERP and Other PackagedSoftware (SAP, Oracle Apps etc)


Table 1: Current Level of Adoption of Application Services UoW Pricing Model Variants

A Shared Effort

Given the absence of established methodologies for planning and implementing these models success requires a relatively

high level of sourcing maturity on the part of the client organization, not to mention a flexible collaborative relationship with

its chosen service provider(s).Indeed, it is difficult to imagine that mutually beneficial UoW pricing can be achieved without both sides bringing expertise,

practical knowledge, and a willingness to explore new approaches to the effort.

On one side the most important contribution a service provider can make is experience. That would be the methodologies

developed, best practices acquired, and expertise derived from years of delivering application services, particularly in

different industry contexts. This combination of service and industry-specific knowledge is essential to identifying and

defining work unit and effort requirements that are at the core of any UoW pricing model.

For clients the prerequisites for implementing a flexible demand based pricing model start with a relatively high level of

outsourcing maturity, particularly an organization readiness to not only adopt but most important manage a new pricing


7/9


model and, quite possibly adopt and govern an entirely new outsourcing engagement model. As noted above, a client must

also be able to supply detailed historical data related to the type of service to be outsourced.

For this reason, immediately switching to a UoW variant may not be the best route for some clients. Rather, a more gradual

approach, one based on a hybrid model for example, may offer the best opportunities for a successful transition. Such an

approach could involve the client first adopting a fixed price managed services model one in which the service provider

assumes a high level of responsibility for deliverables defined by SLAs and then pilot an appropriate UoW model or models

over time.

Regardless of how the transition to UoW pricing is managed and the variant that is to be implemented the basic philosophy

and activities are driven by the following approach (Figure 6).

Past trend of work allocations are analyzed to arrive at the baseline (no. of work units).

In absence of such data, reasonable assumptions are made based on past experiences and benchmarks. Then, the

required capacities are defined by work units.

A base capacity using a fixed price model is established. To address variations in demand estimates for additional work

units are developed and priced in increments.

No of Work

Units

Base capacity

XX XX

Fixed price / month- $YYY/ month

XXX

X XX

Incremental pricebased on pricing options

X

Pricing

Variable capacity based on

demand forecast

No of WorkUnits

Base capacity

XX XX

Fixed price / month- $YYY/ month

XXX

XXX

Incremental pricebased on pricing options

X

Pricing

Variable capacity based on

demand forecast

Figure 6: Basic Approach for Determining UoW Pricing

Once the base price for each type of work unit activity or deliverable has been established, a corresponding price for a range

or number of work units can be fixed and incremental or variable prices set to for a specific time period, usually a businessquarter. At the end of each quarter the base price and variable ranges can be revisited and refined by mutual agreement as

appropriate.

Building on the standard approach outlined above there are separate contributing factors and requirements for establishing

UoW pricing variants for type of application service.

AMS and testing services -Although specific UoW details differ by service the basic mechanism for determining UoW pricing

for application maintenance and support and testing involve similar steps and reliance on historical data in order to:

Capture and analyze volume trends for categories of tickets, service demands (or testing assignments on annual basis.

Negotiate expected annual demand for MUs, or tickets, or testing units, depending on the model being applied for the

service in question.

Evaluate actual consumption quarterly & adjust for under/excess utilization.

Application development services -particularly new custom software projects where functionality, performance, and other

factors can change throughout the application life cycle, requires a flexible approach involving:

Evaluation of base function point (FP) size of the application to arrive at project price.

Review of FP size of project at every milestone and also at the end of project.

Negotiation in the advent of scope creep costs, if applicable.


8/9


Package implementation services where required functionality determines which software modules are to be used and the

scope and nature of activities needed to implement and integrate them, pricing is arrived at by:

Evaluation of the total package points required to implement the required module(s).

Negotiation of lower/upper limits.

Evaluation of actual consumption quarterly and adjustments for under/excess utilization

Operational Considerations

After an appropriate UoW model has been selected and a pricing scheme defined the next step is work on the operational

aspects. If the application portfolio is complex, with plethora of technologies, it introduces another set of considerations as

service levels are likely to be different for different application types.

Moreover, since various portfolio factors that can have a direct or indirect effect on deliverables and productivity they must be

identified and their potential impact on the overall effort defined and managed accordingly. Determining and managing such

impacts may in turn necessitate changes to governance activities and related functions, particularly with respect to:

Process(es)-- to measure service provider performance and SLAs, and if necessary implement operational and/or

contractual remedies.

People -- specifically trained staff representing both sides of the relationship to manage service levels and contracts by

gathering and analysing increasingly complex data to ensure that the pricing model(s) is executed with the intent for

which it was designed.

Potential Benefits of UoW Pricing

Planning, implementing, and managing a UoW pricing model is a collaborative effort. As noted above, both clients and

service providers can and must bring relevant information, previous experience, and openness to the table. The result, in

addition to the potential for creating a predictable and flexible pricing methodology is an opportunity to strengthen the

sourcing relationship.

To begin with, the process of identifying and clearly defining work units may reduce the potential for conflict due to

misunderstandings over service deliverables and associated activities. Shifting to a pay-per-use UoW model may obviate

the need for labor rate renegotiations, which is the most common and sometimes contentious mechanism for adjusting

services pricing, particularly in difficult economic times. Of course as in any successful relationship there is, in addition to

mutual benefits, individual ones as well.

Client Benefits

Outsourcing has long been promoted as a mechanism for companies to shift from fixed cost models to variable ones. UoW

pricing has the potential to reinforce the shift from fixed to variable costs by enabling clients to adjust service spending up

or down in response to changing business conditions, including the ability to buy capacity as and when needed without

incurring fixed costs. Again, payment is based on work units backed by service levels, not the number of service provider

resources required or on a fixed price that does not vary regardless of service demand.

The ability to actually count deliverables also contributes to accurate demand management and budgeting. Not only do work

units form the basis for usage pricing they serve as a historical record on which to base work load forecasting and project

pipeline planning. At the same time UoW pricing, by delinking results from service provider headcount, makes it easier to

for both parties to align incentives and reapply resources in response to changing circumstances, e.g., from fixing applicationbugs to developing enhancements

Service Provider Benefits

On the service provider side flexibility means the ability to better manage resources while still meeting client needs. By

delinking results from the number of personnel dedicated to a client account, UoW pricing creates an incentive for a service

provider to develop more efficient processes and deliver better results with fewer people, at the same time setting measurable

personnel goals and implementing performance-based rewards.


9/9

The same flexibility that enables service providers to adjust resources according to client needs also frees them to apply the

same skill sets to other clients, creating in effect shared services expertise pools that can be reassigned according to the needs

of different clients.

Conclusion

While the fixed price and T&M pricing models will continue to thrive, UoW based pricing models have the potential to

further optimizing outsourcing costs. These models have the potential to assist clients to bring in much needed discipline in

the demand planning process and consume resources according to need while reducing ad-hoc and unplanned requests.

Clients can also have the ability to analyze the demand pattern and adjust the work buckets of demand. This will further

enable allocating discretionary spend activities from savings realized thru flexible spending in non-discretionary spends.

Although making these costs truly variable has significant business appeal, the implementation of these models would require

clients having a mature service management process and the relevant metrics to measure Unit of Work based models.

Clients should evaluate investment in the required technology, process design and people before considering these models.

About the Authors

M. A. Parthasarathy ([email protected])is an Associate Vice President with Infosys Strategic Global Sourcing unit.

He has more than 37 years of IT experience, including 26 years in software development, project management, and

software engineering. A specialist in software estimation techniques, he has authored a book on the subject, Practical

Software Estimation; Function Point Methods for In-sourced and Out-sourced Projects (Addison Wesley, 2007).

Partha holds a degree in Bachelor of Electrical Engineering, post graduation in Computer Science Engineering, a

diploma in Business Management, and is a Certified Quality Analyst (QAI). This paper represents one of Parthas last

of many contributions to Infosys and the IT industry as a whole prior to his retirement in August 2009.

Sandeep Dhoot ([email protected]) is a Principal Consultant in the Thought Leadership and Business

Development team within Infosys Strategic Global Sourcing unit. With over 16 years of consulting and industry

experience, Sandeep has extensive expertise in strategic sourcing, business process outsourcing, process redesign and

change management. Prior to joining Infosys in 2006, he led large sourcing engagements in the financial services

Industry and advised large manufacturing firms in optimizing supply chains.

Deepak Deb ([email protected])is a Senior Principal in the Thought Leadership and Solutions Development

team within Infosys Strategic Global Sourcing unit. With over 25 years of consulting and industry experience,

Deepaks expertise spans strategic sourcing, application & infrastructure development and deployments, business

process reengineering and project management. Prior to joining Infosys in 2007, Deepak led multiple outsourcing

engagements in various industrial sectors and developed various innovative frameworks in sourcing.

application services pricing

Documents