About Marco Tedone

Measuring your IT OPS – Part 2

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.

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Join Us

With 1,043,221 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Examples Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.