Productivity, Throughput, and WIP in IT

productivityI once worked in the IT department of a large Insurance company and the running joke was that if IT were asked to produce an application that simply displayed “Hello World” on the screen, this would take IT at least 6 months to deliver. In general, IT is not typically described as an area of the company that is all that “productive”: Things get delivered that no one can remember having asked for, and they are produced too slowly.

Actually measuring productivity in IT can get complicated. For one, you probably need a function point expert to be able to objectively count the “stuff” that IT produces. Since this is hard and not all that meaningful with regard to the productivity of the labor involved (a function point in a modern CRM system is a lot easier to produce than that same function point on the AS/400) we usually stick with overall indicators such as IT spend/revenue or IT staff/total staff etc.

Metrics you seldom hear being discussed in IT are “work-in-process (WIP)” and “throughput”. And yet, these are highly indicative of IT productivity almost in the same way that they are in a supply chain. High work-in-process means high cost tied up in projects that do not produce benefits, and low throughput means projects take longer than necessary to deliver. If both are true (and they often are because they are related), you have low productivity.

Let me illustrate this with an example derived from real numbers from one of my clients:

The IT department of Example Company has about 65 people in their development group able to produce about 10,000 hours of labor per month. They run roughly 30 projects simultaneously at any given time, partially allocating resources to multiple projects. Each project (on average) is about 4000 hours of effort (EAC). Throughput for Example Company would be 12 months (i.e. on average it will take the IT department 12 months to complete a given project: 10,000/30 = 333 hours of labor per month per project; 4000/333 = 12 months project duration). WIP will likely average around 6 months of labor, assuming projects are in different stages. And 30 projects can be completed in a year (120,000 hours of labor).

If Example Company ran only 10 projects concurrently instead of 30; throughput would be reduced to 4 months (10,000/10 = 1000 hours per project per month; 4000/1000 = 4 months per project). Three times faster delivery!! And WIP would be reduced to roughly 2 months worth of labor (one third!), even though still the same 30 projects would be delivered in the year.

In both cases 30 projects are delivered in the year. However, the total cost in the second case is dramatically lower, since less capital is tied up in WIP. And benefits are greater, since 8 month of productive use can be gained for each project put in production. So, the IT department is made a lot more productive simply by reducing the number of projects they work on at a given time. Interestingly, if Example Company actually did this, it would likely see that individual productivity would go up as well and not 30 but 31 or 32 projects can now be done, because of dramatic reductions in project overhead and task switching embedded in the multiple project model.

For those of you who think this is not something encountered in real IT departments, I would suggest that indeed this is something that applies to most IT departments. So, for CIO’s out there who run a classic job-shop: check how many projects you have going on, how much WIP, and see what happens to productivity if you cut the number of active projects in half.

One final thought: Reflect on this for a moment and you’ll realize that this is the essence of Agile Transformation. Forget Scrum, Stand-up meetings, Sprints, Burn-down charts, Backlogs, etc. etc. These are all mechanisms to improve throughput and reduce WIP and hence improve IT productivity.

Kasper de Boer


Kasper de Boer is a Vice President in Sogeti US, where he is currently responsible for the Infrastructure Practice. Kasper has 25 years experience in IT Consulting and is particularly interested in IT organizations and how to make these more efficient and effective. He advises clients on how to reduce the on-going maintenance burden of IT systems and technology, achieve better alignment between IT capabilities and business needs, increase speed-to-market of IT solutions, and increase the overall responsiveness of IT.

More on Kasper de Boer.

Related Posts

Your email address will not be published. Required fields are marked *

6 + 6 =

  1. Jos Punter September 8, 2014 Reply

    Well i dont agree with your final thought. If you only focus on WIP you could get enormous productivity, yes. But what about quality and business value ? The situation you will create now is, features will be rushed to get a higher WIP and throughput resulting in utterly useless functionality because the quality hasn’t been looked at. Also the easiest things will get priority, by the developers, cause they are done the quickest. Resulting in higher WIP. So be carefull what you wish for. More productivity but less happy customers will result in less productivity eventually.
    What do you think ?

    • Kasper de Boer September 9, 2014 Reply

      First, let me be clear that I am not arguing to ONLY focus on WIP. As far as quality is concerned, the assumption is that testing procedures etc. are built into the process, just like in manufacturing. So, also testing processes are subject to WIP thinking. This is not a matter of “rushing things through”, but rather a systematic process of pushing things through the appropriate software engineering steps in the most efficient way. And that includes testing. As far as priorities are concerned, these are not set by IT, but by the business, as is customary in Agile. So, in fact, this results in MORE happy customers, because they can constantly make sure IT is working on the most pressing projects, and each of these projects is done faster. What’s not to like?

  2. Jos Punter September 11, 2014 Reply

    thanks for your reply. Makes it more clearer. And i agree