Managing Vendor Performance
is to both parties’ advantage
There are a variety of reasons why we outsource our application development and maintenance activities to third-party vendors. There are an equal number of ways that the contractual arrangements for these are drawn up and executed. In the majority of these engagements, the primary service-level measure that is most often present focuses on vendor performance. How effectively we apply these measures usually makes a difference in how well we govern the engagement and how accurately we measure the value received.
Vendor performance may include measures such as on-time delivery, quality, productivity, and cost. In practical terms, all measures of vendor performance can be summed up into three dimensions: Cost, quality, and value. A successful outsourcing arrangement is one that is competitively priced (cost), delivers a working software product (quality), and meets the needs of the business (value). Service-level agreements and measures need to be established to take these three dimensions into account.
As you might suspect, the challenge is to be able to properly measure the value dimension. One could successfully argue that value equates to delivering within budget and/or producing a quality deliverable. Cost and quality measures are easily defined and measured. But what about the measure of value delivered to the business? Furthermore, how do you equate cost to value? How can we ensure that we are getting a good price for the value being delivered?
A Metric to Measure Cost and Value
An ideal scenario would be to have a metric that would measure both cost and value. For example, in manufacturing, output is often measured as a cost per unit of work (a unit of work representing a high quality delivered product that brings value to the business). So, what is our cost per unit of work for software?
If we can agree that software delivers value to the customer in the form of business functionality, then our “unit of work” measure for software can equate to a measurement of functionality being delivered to the business. Fortunately, there is an industry standard measure called function points that does exactly that. Function points are a measure of the features and functions being developed and delivered to an end user. Function Point Analysis defines features and functions as they relates to things, such as input transactions, output displays and reports, inquiries on data values, groupings of maintained data, and interfaces to other applications.
Using the function point measure, coupled with a measure of cost, we can easily produce a cost per function point, which serves as our cost per unit of work. Using some historical performance measures, we can develop a standard cost per unit of work and then use that standard as a benchmark to measure third-party vendor bids and deliverables.
A Sound Negotiating Position With Vendors
With this information available, an organization now has the basis for a sound negotiating position with an outsourcing vendor, with deliverables based on this cost per unit of work. The function point size metric can also be used to effectively measure the quality of the software deliverable. There are several common function-point-based quality metrics, the most notable one being defect density. This is often calculated as the number of delivered defects per 1000 FPs.
In conclusion, an ADM outsourcing arrangement that includes service-level agreements measuring both quality and value (cost per unit of work) are more likely to be successful and well governed. It is to both parties’ advantage to consider these metrics. The value for the client is an assurance that value deliverables are priced right. The value for the provider is to be able to demonstrate that what was promised was delivered within budget.
About the author
David Herron is Vice President for Software Performance Management at the David Consulting Group. He is an acknowledged authority in the use of performance metrics to monitor the impact of IT on the business and on the advancement of IT organizations to higher levels of software process maturity. He has co-authored two books on Functional Measurement with David Garmus.
This blogpost was originally published at the website of the David Consulting Group.