Note on the publishing date: This post first appeared on 2013/02/25 as part of the now defunct leannovation blog header, which died because it happened to coincide with the name of an unrelated existing company.
Since I joined my first non-corporate software development team a few years back I have seen plenty of examples of product development organizations trying to do too much in parallel. I’m not talking about the usual peak of activity here or there, but about a constant stretch to higher utilization levels or to a bigger number of projects crawling through the development life-cycle.
I am bringing one particular example as an illustration. It was maybe an exaggerated case which, fortunately enough, I have only witnessed but never been a part of. The organization in question was a software development department within the IT division of a mid-sized corporation. By then they usually bought most of their software “in-a-box” or through externally contracted development projects so the department was not very big. Most of their developers were allocated to multiple projects; the most demanded ones to as many as 10 projects. Teams didn’t last long enough to gel and individual allocations were “calculated” through some pretty sophisticated resource management techniques, considering several variables like title, occupation, availability (in chunks of 5%) and even cost.