David Herron
David Herron
David Herron is a co-founder of the David Consulting Group. Mr. Herron has more than 25 years' experience in software development. He has recently been focused on the use of metrics to monitor applications development outsourcing arrangements and the impact of IT on the business. During the past 10 years, Mr. Herron has served as a consultant to Fortune 500 companies in the areas of software metrics and software risk management. He is an authority in the measurement and estimation of software productivity and quality, specializing in the determination of software project size and effort. He can be reached at consulting@cutter.com.
The Value of the Function Point Method An interview with David HerronIn this interview, David Herron explains the importance of the function point method as a chief gauge of the effectiveness of an outsourced application development and maintenance function.
Q: In your latest Executive Update, "Finding the True Value of Outsourcing," you tout the function point method as the primary measuring stick for the effectiveness of outsourcing application development and maintenance. Why the function point method?
The function point method results in a sizing measure that serves a dual purpose. It provides a measure (value) of the functionality being delivered to the customer and it gives the offshore provider a valuable tool to estimate the cost of the development or maintenance effort.
Q: Cost savings is certainly a primary driver behind offshore outsourcing. But, based on your experience, are some companies falling short of the savings that they anticipated? Why?
In many of the outsourcing deals that we have been involved with, the basis for cost savings has been reduced labor expense. It is a relatively easy target to meet since labor costs can easily be impacted by reducing staffing levels. The bigger problems come from the "hidden costs" that are not anticipated. Typically, service levels are not established to completely measure the true expense and true value of the software deliverable.
Q: In your view, is the use of function points more important, or just as important, when outsourcing functions offshore as opposed to outsourcing them domestically? Please explain.
The value of using function points is the same for both onshore and offshore outsourcing. Furthermore, function points should be used for all retained applications as well. Using the function point method for sizing the software deliverable creates a common point of comparison to measure performance improvements.
Putting a Fine Point on Outsourcing: Service Levels and Baselines An Interview with David Herron, Senior Consultant, Cutter ConsortiumQ: What's the biggest change you've seen in outsourcing?
For our clients, which are all in the applications development and maintenance arena, we're seeing deals that are shorter in duration. A lot of the 10-year contracts signed in the early 1990s are coming due, and we aren't seeing any large mega-deals coming on their heels. Things change a great deal in that length of time, and there wasn't usually enough flexibility built into the contracts. We're seeing lots of five- and seven-year deals, and more selective outsourcing. Rather than outsourcing the whole IT shop, companies are outsourcing maintenance or a specific project.
The other change is that people aren't going after cost savings as strongly. Cost is still an issue, but finding supplemental resources with the right skills is the biggest issue right now. Offshore prices are also increasing. A client recently told me that potential savings from an offshore company were almost negated by the cost of communication. Companies are looking for higher skill levels and -- simply -- bodies. I think offshore outsourcing will continue to be popular, but the price differences are not going to be as dramatic.
Q: Is outsourcing a viable solution to the IT worker shortage?
From a people perspective, it's working. From a cost-savings perspective, people are readjusting their thinking. The issue is whether there are enough skilled people out there to satisfy the market. Only time will tell -- lots of applications are being developed, and we'll see shortly how good they are.
What's definite is that all the companies we work with say they have learned a great deal from past outsourcing relationships, and the lessons-learned are always the same: you need realistic expectations, carefully defined service levels, and excellent communication.
Q: What's your advice on establishing proper service-levels?
Getting the right service-level measures in place from the beginning of the contract has proven to be extremely important. The trick is to put in measures that drive a desired behavior. Many companies are putting in management-related measures. But the provider is going to manage the day-to-day; what you need is to monitor the overall service being provided. For example, in application development, the service-level measures should drive behavior that yields high-quality software. The day-to-day management of that involves making sure that people are doing reviews and inspections on their code. But you don't want the service-level to call for reviews and inspections. That guarantees reviews and inspections -- not quality code. Instead, the measure should be how many defects per unit of work are there. Instead of dictating to the vendor how to get there, the customer simply says, "You've got to get there."
The other factor in getting service levels right is having a baseline. Many times, companies try to establish a percentage of improvement without having an accurate performance baseline. They either didn't establish a baseline at all, or they established it during the first year of the contract, a time when productivity is always low. They have faulty starting points, so accurately measuring improvement is nearly impossible. And the provider isn't motivated to get an accurate baseline established. If it's a bit nebulous, they can more easily come in and show how well they're doing. Often, the client doesn't want to spend the time or the money on baselining; they don't understand the value of it.
Q: What's the best way to make baselining more palatable?
We take a cross-section sampling approach to baselining. We don't baseline the whole organization; we look at a profile of what's going to be outsourced, find some representative data points, and capture and analyze those. It can be a 60-day effort that goes on during negotiations. That's before anything has transitioned to the provider, so you're not seeing any serious productivity decline.
People tend to think that baselining has to take a year and cost a large amount of money. But for applications development outsourcing, you can do it fairly quickly and without incurring a lot of cost. In addition, a proper baseline will produce performance profiles indicating attributes that contribute to high or low productivity yields, which will help you establish comprehensive service levels.
There are two major deliverables of a baselining process: a quantitative assessment of performance (time to market, effort, productivity levels across various technical platforms) and a qualitative assessment that shows where your software development practices are relative to industry best practices (processes, skill levels, ability to execute, customer interaction, etc.). That profile can be used to say, "We do some things pretty well; let's continue to do them (or have the outsourcer do them at that level). Here are places where we have some weaknesses, let's let the outsourcer know about them so we can achieve some levels of improvement." It also gives you the ability to set specific improvement goals. Let's say your goal is to improve performance by 10% across the board. But you may already be doing mainframe applications really well, and 10% would be overly ambitious. Likewise, there might be areas where you're doing very poorly, in which case 10% would be too little improvement.
Interestingly, we did a baseline project for a large financial services company. They were in negotiation with a large, well-known outsourcer, but as a result of the baseline study, they felt they had such a clear understanding of where they needed to improve, they decided to break off negotiations and take a couple of years to see if they could improve on their own.
Q: What are the trends for outsourcing for the next five years?
We're going to continue to need resources, so outsourcing will continue to be popular. We're going to continue to see shorter deals on selected projects. But the idea is to develop a good partnership, so that when the contract ends, you can make some necessary changes (as a result of lessons learned or technology changes) and ink a new deal without much of a hassle.
The key to that is good relationship management. Unfortunately, the biggest mistake I find clients make is the management of the contract and the relationship after the deal is signed. The people who are in charge are busy or don't have the required skills to manage the contract and the relationship. It's a full-time job, and it requires someone who is very talented in negotiation, client management, workflow management, and so on. I can name case after case where senior management put the deal together and turn it over to a development manager, who may or may not be familiar with the deal and doesn't have the talent required. Or the deal is turned over to the supplier management group, who is used to dealing with contract programmers -- not the same thing at all.
For more by David Herron, see: