R& D departments have to live with uncertainty because they are always doing new things. High uncertainty is difficult enough to handle in a single project but becomes much worse in a department running several projects, perhaps with staff or facilities shared between them. You might say it’s a recipe for chaos, and perhaps it is literally so.
I was speaking to a friend in R&D the other day and he was moaning about how his CEO, a technical enthusiast, was forever loading new projects into R&D. “It just fouls things up”, he said, “The more we try and take on, the less actually gets done”.
Exceeding Reynolds number reduces flow
It reminded me of what happens when you try and pump fluid too fast down a pipe and exceed the Reynolds number: the flow goes turbulent so that you get less through. Could some analogous situation occur in R&D pipeline?
I don’t know of any formal study of this but I can think of a number of pointers to what can happen in an overloaded department. One is from Wheelwright and Clark’s book ‘Revolutionising Product Development’ (1992) showing the reduction in efficiency of engineers who had to share their time between a number of projects:
This is only a single example and no doubt the actual numbers will depend on the type of project.
But it must surely be true that while having more than one project in hand would allow people to make good use of time that might otherwise be spent waiting for something, multiplexing between too many projects can get very wasteful.
I certainly know of departments where engineers are supposed to handle 5 or more projects at a time.
Sharing requests increases efficiency
Another aspect of the problem is queuing. We are all familiar with how the random arrival of cars at a toll booth can lead to queues, but the magnitudes involved may be surprising.
When requests for service come in randomly to a single server they can cause a queue that doubles the service time even though on average the server is idle a third of the time. And that is for jobs that all take the same time; random lengths make things worse still, as figure 2 shows.
In R&D departments projects often have to share facilities, be it test equipment, help from legal or IT specialists, or advice from scarce scientific experts.
Figure 2 Queuing for service from a single server
When queues build up people naturally try to get round the problem by negotiating for more resources or changed priorities; or by switching to other projects while they wait.
What is wasting your time?
A few years ago an MSc student of mine, Sean Morrisroe, surveyed engineers in several R&D departments asking what were the causes of time-wasting for them.
According to them half of all their time-wasting came from problems with resourcing and 40% from changes of direction or priority. Perhaps one can damp out these turbulences in some way.
If there is queuing one can improve matters by smoothing out the randomness of the flow or by sharing scarce facilities more widely.
Two toll booths can handle more than twice the traffic of one without increasing the queue because there is a better chance that at least one will be free when a new demand arrives. It’s called Trunking in telephony.
Does Reynolds number exist in R&D?
All of this seems to indicate that turbulence in the flow of projects through an R&D department may set in at much lower levels of load than one might imagine. If some analogue of the Reynolds number does exist in R&D, I wonder what it depends on and how we might affect it?
If anybody reading this has ideas or experiences to share, we’d be very pleased to hear from you. Let’s start a conversation.
Post by Rick Mitchell. April 2017