Skip to content

Instantly share code, notes, and snippets.

@sleepyfox
Last active July 15, 2020 16:56
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sleepyfox/4c5abf71f04fd0695f7e5aa15cc2cd02 to your computer and use it in GitHub Desktop.
Save sleepyfox/4c5abf71f04fd0695f7e5aa15cc2cd02 to your computer and use it in GitHub Desktop.
Value, Productivity and Metrics

Value, Productivity and Metrics

author: @sleepyfox
title: Value, Productivity and Metrics
date: 24-Jun-2011

This is a response that I made on the Software Engineering Productivity forum of LinkedIn, on the topic "How do you measure (software) engineering productivity?"

The question was defined:

Ultimately productivity has to be defined in terms of the dollar value created. Organizations or groups that can map their contribution to a project to the company’s bottom-line are usually found to be highly productive.

In other words, measure a group's productivity by the profits generated and the business opportunities created.

You can find the whole thread on LinkedIn, and long-story short I'd like to highlight my response in terms of the statement:

Productivity should be defined in terms of profit

This statement seems to be accepted as a God-given truth in most business and project management circles and whilst I think that there is a certain amount of merit in this approach the manufacturing world is quite different to the software world, a fact that is often overlooked.

My response

The problem with using the measure 'profit' in order to calculate productivity of a team (or anything else) is that you are now in the realm of Accountancy, and as any decent accountant will tell you, there are many different ways of measuring profit, and even a 'simple' to measure "revenue minus cost of sale" may not be a very good measure of "value to the business".

Leaving aside for a moment the selection bias present in the choosing of "profit" as a measure (it is possible for a business to be bankrupt even if profitable, as cash-flow is often more important), it turns out that the two components of the measure: 'revenue' and 'cost of sale' are actually a bit more difficult to measure than you might at first imagine. For example:

Revenue

  • Do you only count the money that the customer pays you up front?
  • Do you count any service agreement amount?
  • How is this amortised over the duration of the service agreement?
    • All up front?
    • Evenly over the course of the contract?
    • Only accounted for on contract completion?
    • Discounted over time on a risk-profiled basis?
  • Are you taking into account TVM coefficients?
  • What about repeat work? (as the cost of acquiring a new customer is often many times higher than selling to an existing customer)
  • Are you factoring in the value-add that producing a high-quality project will have in getting repeat business?
  • If so then how are you calculating this?
  • How do you measure quality and customer satisfaction?
  • Over what time period is it necessary to wait for a customer to make another order in order that it is counted as a 'repeat sale' and hence factored into the calculation of business value for the previous project, rather than a new project? ...

Cost of sale

  • Are pre-sales activities factored into cost-of-sale?
  • Are general business expenses factored into cost of sale (e.g. business rates, payroll cost etc.)?
    • If they are, then how are the CapEx and OpEx split between different projects?
    • Evenly per project?
    • Proportional to final value?
    • If so then how is final value calculated?
  • If you have projects that re-use components from other projects (and this may be learning and knowledge, rather than hard code for instance e.g. product training), then how is this accounted for in your cost-of-sale calculation?
    • If this is a sale into an existing customer, how much of the cost-of-sale value is accounted for as being due to the successful outcome of a previous sale, and therefore shared between the projects?
    • If not, then how do you compensate for the artificial inflation of 'first sale' project costs? Are we taking into account taxes? (i.e. difference between EBITDA - Earnings Before Interest, Tax, Depreciation and Amortization, and NOPAT - Net Operating Profit After Tax)
    • If NOPAT then if a project spans accountancy periods, how do you determine which period it is included in in order to determine what it's tax liabilities are? ...

This is just skimming the surface of what corporate accountants deal with every day. The reality is that 'profit' can mean pretty much whatever you want it to mean, and every answer to every question above affects how it is determined, and how your projects will stack up against one another. The reality of running a business is that you can never truly know the exact state of the accounts until the business is wound up, everything else is surrounded by guesstimates (e.g. deal closure rates), assumptions (e.g. tax banding by operating profit on next fiscal year's books) and fudge factors (e.g. payment default rates and average invoice payment delay).

My message here is really: "Think very very carefully before suggesting metrics like 'profit', because although they seem simple to calculate to the lay observer, the reality is very very different" -- The Foxy Thinker

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment