In my opening article I stated the importance of measuring IT OPS to provide the underlying framework for a Continous Improvement (CI) culture and to this effect I identified a list of IT OPS measurements which I consider key to understand how your IT organisation is performing. In the first article of this series I suggested a simple way of measuring the Feature Average Lead Time (FALT). 
This article is about measuring the Development cost of a Deployed Feature (DECODEF). This is probably the easiest figure to measure as, conceptually, is just the multiplication of man days times the average cost of your resources. Some interesting considerations emerge when considering the calculation of the average cost of people involved in a release. The practice of having off-shore teams is now widely adopted not only in enterprise-scale organisations but also in small-medium ones; as an example, here in the UK is quite conventional having service companies with part or whole of their teams in off-shore locations, where the cost of labour agrees more with the balance sheet, often by at least one order of magnitude. When one looks at off-shoring, usually the following team configurations are in place:
- Mixed Team: Part of the team is on-shore, part of the team is off-shore in some sort of mixed balance
- Off-Shore Team with On-Shore management: The technical team is off-shore and the management is on-shore, generally within the organisation head offices;
- Off-Shore Team: The whole team is off-shore including management
Calculating the average cost of staff requires some attention when considering teams spread throughout the world; it is quite a common practice defining different average daily rates, depending on the location and function of each resource (e.g. an on-shore manager is significantly more expensive than an on-shore resource but also an off-shore senior technical person or manager is more expensive than a more junior resource). To have meaningful figures my suggestion is to indetify and classify different types of resources working on your project (on/off shore, manager, developer, etc), how much time each resource has spent on a production deliverable and how much productive time each resource can dedicate to the project (weighting); any time entry tools, opportunely configured, could come to the rescue with periodical reports. A simple suggestion on how to calculate the cost of development, and one which works for all typologies defined above, is the following:
- Define the typology of your resources
- Calculate the average daily cost per typology of resource
- Define the weighting of each resource on the project. The weighting is the amount of productive time a resource can dedicate to a production deliverable
- Have a reporting tool to provide the total number of hours a resource worked on a production deliverable
- Calculate the man days that each resource worked on a production deliverable, by dividing the total number of hours per resource by the number of hours in an Ideal Day
- Multiply the average daily rate of a resource type by the man days she spent on the production deliverable
- Sum all results to obtain the total cost of development for a deployed feature, or DECODEF
It’s worth mentioning few things:
- It’s easier to follow this process if the project is organised in small, atomic tasks measurable in hours
- The measurement needs to be thorough, or the results won’t be accurate and informative
- It’s worth defining what is your team Ideal Day as defined by Mike Cohn in his book on Agile estimate and planning. In my teams I define an Ideal Day to be composed of six productive (not elapsed) hours.
- Not all resources could be available for a production deliverable 100% of their productive time; although not ideal some specially skilled people might work on more than one deliverable at one time. Some sort of weighting might therefore be required
Here follows an example for the calculation of DECODEF in a Mixed Team scenario:
Although the data is completely made up, please note the weighting, the number of hours spent on a production deliverable, the calculation of man days, the different resource types and the different average cost per resource type.
Why am I insisting on production deliverable as opposed to project? In my world a project generally consists of a series of production deliverables and if it’s true that each of these provides business value to stakeholders, then at each deliverable the team is delivering business value. In order to know with a certain accuracy how much true value the team delivered, it is necessary to deduct the costs. Calculating the delivered business value sooner rather than later might provide some excellent insights with regards to the direction the project is taking. It might be the case that the business elarges budget as the project progresses; in this case I believe it’s preferrable to deliver business value whenever possible to show our sponsors that they are getting good value for money, or that they aren’t!. On the other hand, these measurements might show that it’s too costly to go ahead with the project compared to the benefits (ROI) and therefore there is no interest in continuing with it. Like in software development, early feedback is preferable to a big-bang approach.
I hope that this article provided some insights on how to measure the cost of development but mostly why it’s important to measure them.
Reference: Measuring your IT OPS – Part 2 from our JCG partner Marco Tedone at the Marco Tedone’s blog blog.
