PRODUCTIVITY, THROUGHPUT, AND WIP IN IT

kasper-octI 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.

More information

Kasper-de-BoerKasper 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.

 

Autor: qanewsblog

Sogeti es una compañía tecnológica perteneciente al Grupo Capgemini y especialista en: Testing y Calidad de Software; Soluciones Microsoft y High Tech Consulting. En Sogeti entendemos la importancia de obtener el máximo valor empresarial de sus sistemas de IT, por ello somos líderes mundiales en Testing & QA. Somos creadores de las metodologías estándar del mercado: TMap® (Test Management Approach) y TPI® (Test Process Improvement). ¡Nuestro compromiso es el Testing!

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s