Development Shop Productivity – Should You Outsource?


CIOs, executives and development managers will find the most interest in this article.  We’ll focus on a productivity measure for custom software development and how it may help you justify outsourcing your software development shop.

The Problem

How do you justify outsourcing your development shop when you know the immediate cost savings may not be there?  The trend toward mega-software development outsourcing shops isn’t slowing down.  But the gains to Fortune 500 enterprises are not always immediate.  You’re gut says it to you every day:  “It’s better to let someone else do this.  We just aren’t good at developing our own systems.  The bugs, the time, the bad requirements…”  But, how do you justify your gut?

A Formula to Measure Your Progress

I’ll skip past all the BS on the benefits and costs of outsourcing.  You can look these up with Gartner, or some independent analyst’s site.  What I will present is a new formula for measuring your custom development shop value and tracking it relative to an outsourced effort.

Here’s the formula:

Custom Development Value Added = CDVA
Capital Dollars Invested = C
Operating Dollars Invested = O
Return on Investment from any completed projects  = NPV
Hours spent gathering & defining requirments = ReqH
Hours spent fixing bugs = BugH
Hours spent addressing help desk tickets = TickH
Hours invested in training = TrainH
Hours of Time Off = OffH

CDVA = ((C + O) - NPV ) / (( ReqH + BugH + TickH ) - ( TrainH + OffH ))

Let’s talk through it.  CDVA is your development shop’s productivity. The first thing you’ll want to do is baseline this for your current shop over a year and then determine how it compares to any outsourcer’s proposal.

The numerator in the equation represents your financial investment in custom development.  The denominator represents labor expended relative to this investment.

So over time you want to see your CDVA increase regardless of your outsourcing decision.  If the trend goes down or stays stagnant then it’s time to seek improvement.  There are some diminishing returns here, and you may need to make periodic investments to see greater value added later on.  But the point should be clear; we’re measuring the return on our development shop’s productivity overall….rather than on a project by project basis ( which can be very misleading ).

You determine the periodicity, but measuring this at every fiscal month makes sense to my inner accountant.

You might ask why I chose measuring hours around bugs, requirements, and trouble tickets and not the overall development effort? Well….experience tells me these are the areas with the greatest variability and also the areas where expertise and experience shine.  Those who are good at software and application development can do so with minimal bugs, less requirements analysis and their end product typically needs very little support ( I can see some CIOs smiling right now ).


Outsourcing is like any business venture and may require some upfront investment to see returns over time.  But, while this is intuitive it isn’t always measured in a consistent way that takes account of key development metrics like bug counts, support tickets, and requirements time.  Hopefully this article presents a way to do just that.  Enterprise IT is under increasing cost pressures and given the historical waste and loss associated with custom application development it only makes sense to look at outsourcing vendors who have the focus, experience, expertise, and clout to deliver.  Now IT executives may have a measure to justify and track that or at least show their shop is improving.  😉


2 thoughts on “Development Shop Productivity – Should You Outsource?

  1. Two thoughts:

    1.) The requirements costs are going to be there for either an in-house development shop or an outsourcing shop. In fact, I might suspect they would be larger for outsourcing, since they are not immersed in your culture and will require (if you’ll pardon the expression) more explicit communication for everything.

    To a lesser extent, the same applies to help desk tickets. You will still be the first point of contact for any problems. You can pass them off to the outsourcer, but I suspect most companies will want to have control over the customer service process.

    2.) I think there is some prestige attached to having an in-house development group. Because the CIO of a company we’re both familiar with (thought he) had a development group, he was able to apply pressure to another outsourcer that his group could develop a replacement for their product. If you don’t have this, you don’t have that leverage, and are somewhat at the mercy of what outsourcers can offer you.

    • John,

      Thanks for the great comments. 🙂

      On point #1 I agree with you initially. But as time goes on ( outsourcer or in house ) the team should be focused on becoming more efficient/effective at reqs gathering and analysis. If they don’t…then it leads to all kinds of downstream issues in the development process: change requests, bugs/defects, service tickets, and ultimately the bad reputation that comes from poor quality. Junk in…junk out.

      On point #2… can always lever one outsourcer against another. Investing in an in-house development group purely for the purpose of prestige or leverage seems uneconomical. My point with this post is to give a tool for measuring team productivity so that outsourcing decisions aren’t based on a simple, one-time, up front cost/benefit study. There should be more to it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s