English | EN Productivity, Throughput, and WIP in IT
Sep 8, 2014
I 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.
About the author
