Efficiency versus Effectiveness

January 30, 2011 at 3:44 pm | Posted in Agile | 10 Comments

I work as a consultant for companies that want to introduce Agile Software Development as a way to improve their software process. During an intake interview I always ask what they expect to gain from that and more often than not (about 90 % of the time) the customer’s first answer is that they want to improve the productivity of their IT department. Second in line is almost invariably the need for higher quality. But let’s stick with higher productivity first, because that is where the fun (please don’t interpret this as disrespect for my work or customers) starts.

My first reaction is pretty straightforward: “so what is your current productivity?”. I have never had an answer to that question apart from “we don’t know exactly, but it is not high enough” followed by remarks like “You are the expert, maybe you can do a baseline measurement.” My second question is mostly along the lines of “It’s ok that you don’t know your current productivity, but can you explain what you mean by productivity?”. And again I never get a clear answer. Sometimes a department has set goals like doing the same amount of work with less people: 20 % less people means 20 % productivity improvement to them.

The interesting thing is that when you talk to customers about productivity, they almost always talk about improving efficiency: more work done with less people, projects within time, budget and scope, etc. In other words, they mostly tend to talk about the costs, not about the benefits. From a historic perspective this makes sense: IT departments are often seen as cost centers. So the cheaper you can run your IT department, the better. This attitude ignores a couple of issues: firstly, IT is not just production work. It is about handling knowledge, interaction between people, etc. In his book ‘Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency’ Tom DeMarco argues that it doesn’t make sense to drive people up to 100 % efficiency.

But equally important, efficiency really isn’t that relevant. What really matters is effectiveness. How much money do you really get out of every dollar or euro you invest in IT. Cranking out more code per person month might not improve this at all. Productivity is all about the business value you can deliver. The interesting part is that there is a strong relationship between this definition of productivity (effectiveness) and efficiency. For three different types of companies I have shown this in the next graph:

If your IT department does standard production work then you can aim at high efficiency. Just like MacDonalds has an optimized process to produce hamburgers, you might do the same thing with your software. For example if you produce webshops in a limited amount of variations, you might want to go for 90 % efficiency. Higher than this hardly makes sense since you will always need some flexibility.

On the other side of the spectrum, if you are a start-up company or part of an R&D department, you need flexibility. By definition you need to trade a lot of your efficiency for the ability to handle risks (big opportunities and large risks come hand in hand). In this situation you should care about results, not that much about costs.

After the start-up phase, a company enters its maturing or consolidation phase. Efficiency can increase but you still want to maintain agility. Most IT-departments will have to handle this situation. Here you should go for 70 – 80 % efficiency and use the rest to handle risks, improve your effectiveness. In other words: concentrate on delivering business value at the cost of 20 – 30 % efficiency. An example of where I see this failing: many larger organizations have ‘optimized’ their software release process. Their IT department only releases twice a year because that minimizes the amount of work involved (never releasing would even be better, but that obviously doesn’t work 😉 ).

These graphs have helped me many times while discussing productivity with customers. In putting this in my blog I hope they will be useful for others as well. Please let me know if you have improvements, criticism or other feedback!