I can bet you are familiar with this one, but not its consequences, in product development: you’ve seen project managers in product development teams express frustration at not being able to keep the development on track, on time and on budget. I had earlier written about the kind of expectations people have of product development and its perils – but this problem of project management is worse. In response to delays, project managers begin to get even more hyper. They start asking for more detailed plans, better definitions of deliverables, tighter schedules, better time and resource utilization and more frequent reviews (ouch!). That’s natural. That’s what project managers are born to do. Except, in the product development context, this approach is just not applicable. It’s a great approach in manufacturing and service environments where assets are under performing and people need to tighten their process management. But in product development, this can all but kill the development.
Product development and shop floors are very different – to start with code being developed can be in several places at the same time, in the hands of different people, undergoing several changes (and becoming altogether new products!). This just can’t happen in a manufacturing scenario. A copper pipe being manufactured can only be at one place on the shop floor. A car being manufactured can only be at one point on the assembly belt.
The difference is crucial. And well worth appreciating. Product development managers can’t afford to have their teams ticking at 100% utilization. Not even at 90%. It can cause untold harm. In development, busy does not necessarily translate into productive. Reason? Nothing is predictable in product development (again, I hark back to my older post on the topic at http://pn.ispirt.in/the-weight-of-expectation/). Development thrives in chaos. No one is certain how long a task in development will require – or should take. Unlike in manufacturing and services, where there are well-set benchmarks for most processes, in development there are practically none. Teams should be given leeway to make unpredictable changes, and start from scratch. And starting from scratch does mean low people and process utilization.
Bringing order to development is futile. Okay, I’ll take that back and rephrase it a bit: Bringing order to development is not recommended. This is because the process of development has large variances and reducing those variances can take up considerable resources, adding to project costs. In a world of shrinking resources, that’s a trade-off few will opt for. Or am I in a minority in thinking this?
