Recently, I was reminded of a computer networking concept called congestion collapse (or congestive collapse according to Wikipedia). The basic theory, which has been proven in practice, is that something counter-intuitive happens when the amount of data being sent reaches the limits of the network device and more requests are continuously made. The amount of data that can be processed does not flat line at the top of the curve, but instead it completely collapses (see my graph).
This is an oversimplification, of course. Briefly, for the non-computer types in the audience, the network device referred to is usually a specific piece of hardware, such as a network router or switch. The data I refer to are TCP packets. The reason the useful work nosedives is that the network hardware starts to get overloaded once it reaches maximum capacity. It then starts dropping (forgetting) packets because it can neither process them nor store them in memory (in networking this is a full buffer or queue). The hardware starts then requesting that the packets be resent. This requires more processing power to make these requests and as the amount of requests come in for processing, it drops more, has to do more resubmit requests and starts being unable to send out packets it has not dropped. And so on…. Which leads to the amount of useful work collapses.
What does this have to do with project intake? In my experience, project based areas tend to stumble and fall under the strain of many, many requests. Generally, I see this in IT areas specifically as they are very project intensive with feature requests, break-fix work and a variety of major software / hardware installations. They start the year with a (relatively) clean slate of known project work that they need to manage. They make a plan to complete that work and it all looks great. Yet, as the year continues on, they begin to struggle, fall behind and get complaints of not being communicative. Why?
I believe that similar to a networking congestion collapse situation, a project team without an intake process or a centralized project portfolio management area, such as a PMO, will start to do things similar to that poor, helpless network device mentioned above. As the amount of work requests increase close to capacity, the team starts to spend more and more time on non-work tasks. Communication needs to increase as more people ask for updates, status, and to make changes, etc. As the team gets drawn into more and more project meetings for a wider variety of projects, mistakes get made and useful work declines. The negative impact of more people requiring communication can be seen in Fred Brook’s classic work, The Mythical Man-Month. That impact from the group intercommunication formula alone can destroy productivity.
Therefore, I think any project area requires some kind of intake process, gatekeeper or some kind of congestion control (again, another networking term). Intuitively I believe it makes sense, but I may explore the proofs around this in future posts.