Managing your Vendor’s Performance

David HerronHow much insight do you have regarding your software vendor’s level of performance? And how do you know if an outsourcing arrangement is cost effective?

Outsourcing arrangements typically have contractually agreed to service level agreements (SLA). These SLAs define a variety of parameters, which serve to govern vendor performance. SLAs can include issues of compliance to standards, delivery timelines, penalty clauses, escalation procedures and other guidelines for managing vendor outcomes. But, how do you know that the delivered outcome, usually software, is being provided efficiently and economically? Wouldn’t it be nice if we could measure software deliverables on a cost per unit of work basis just like in manufacturing; whereby, we could evaluate the vendor’s level of performance based on a software cost per unit of work.  

How do you define a unit of work for software, you may ask? We can define a software unit of work by using an industry standard software measurement method known as Function Point Analysis (FPA). We define a software unit of work as a unique software feature or function that an end user has requested; an online screen to process a specific transaction, for example. When software is first being developed, a formal requirements document or backlog of requirements (for you Agile folks) is developed that is intended to describe all the required features and functions for a desired program. The FPA methodology was designed for the primary purpose of measuring or sizing those software features and functions as requested by an end user.

FPA defines a software function as one of five elements; a unique input, output, inquiry, remote data access or internally maintained data. The methodology clearly defines the characteristics of each of these five elements, making it easy to identify and classify the requested functionality. Each element is evaluated and assigned a value based on its complexity. The result is a numeric value of size. The cumulative size of all five elements thus represents the total of all the unique functions – or a total number of units of work.

To develop and deliver software, as defined by the user requirements, the vendor charges a contractually agreed to fee for that service. Now we have all of the ingredients necessary to develop a cost per unit of work measure. A simple example would be: a software requirement was sized using FPA and included features and functions that measured as 150 function points (units of work) and it was delivered at a cost of $150,000; therefore, the cost per unit of work would be $1,000 per function point (or unit of work). 

The real value of using this cost per unit of work approach is to understand what defines a reasonable cost per unit of work. The size of any software deliverable can be consistently determined using the FPA methodology. The cost, however, can vary depending on a myriad of variables.  In other words, not all function points cost the same.

The mature organization has taken the time to baseline their own levels of performance and has established an internal cost per unit of work. At that point, they are well positioned to evaluate vendor bids based on a cost per unit of work basis. For those organizations that do not know their own level of performance, they can utilize industry baseline performance measures based on function points to determine whether or not a particular vendor bid is within an acceptable range of performance.

This blog post is available as a download in our Publication library for your use!

Questions? Leave them in the comments and we'll get back to you!


David Herron
Vice President, Software Performance Management

Written by David Herron at 05:00
Categories :



"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!