In a Sesame Street game of “Which one of these is like the other,” you can be certain no one would put freeway traffic jams and MSPs together. But there is a fascinating physics that connects the two.
Traffic jams are created when a driver taps on their brakes, slowing their car down. The car behind this first car is also forced to press on their brakes, especially if the distance between the cars is not that large. Similarly, the car behind the second car is forced to also press their brakes in order to avoid rear ending the car in front of them. This continues down the road. Now, because of human reaction times, each successive driver has to press a bit harder on their brakes to stop from hitting the car in front of them. This leads eventually to cars coming to a standstill, leading to a traffic jam on the freeway – all because of one initial small change by one driver. Physicists who have studied traffic jams have observed they occur in waves (which they call “jamitrons”1) no differently from other physical phenomena in nature where one small change ripples and amplifies through the system.
The good news is physicists have found there are a couple of ways to prevent traffic jams from happening. First, you could remove the human driver from the picture since it is the accumulation of their (increasing) reaction times that leads to traffic jams. Secondly, and perhaps more practically until all cars are driverless, is to increase the distance between cars on the road. It is this distance that is explains why traffic jams happen only when cars reach a certain density on the roads and the distance between them drops below a critical level.
So, what does this have to do with MSPs?
MSPs deliver their services via a calendar of scheduled projects presented in a Gannt chart (as shown below).
Now imagine what happens if in one of these projects, something changes as so often happens. Perhaps the change is the project taking longer than expected. Or perhaps the client requests a start date later than the original one. From a project management perspective, one answer might be to keep the project with the same resource but move all downstream projects based on what the changed projects allows. If its’ duration changed by a week, then move all downstream projects assigned to that resource by a week. The problem with this solution is that moving downstream projects out may break customer commitments. So, to avoid this, another solution might be to move one or more of the downstream projects from one resource to another. This can work if the newly assigned resource has both availability and the required skills. But what if their schedule is also full? It may not be possible to move projects without affecting commitments to those customers already assigned to the resource. To avoid reneging on customer commitments, the MSP project manager may decide to juggle a few projects, moving them from one resource to another to minimize the impact on customer commitments. This leads to scheduling chaos, all because one project changed its duration.
Coming back to the traffic jam solutions, is there something similar for managing change in MSP project management? Just as distance between cars can be used to prevent jams, one possibility is to use time buffers between projects so that a change in one does not affect downstream projects. The difference, though, is that distance between cars is costless, but creating buffer times in MSP project management reduces utilization and reduces both revenue and profit. What this leads to is a question. If buffers are a way of reducing scheduling chaos and maintaining customer commitments, but are costly in terms of utilization, revenue and profit, what is the right tradeoff? How much of a buffer should MSPs retain between their projects?
It is exactly this sort of question that motivates us here at Red Swift. If you’d like to learn more, let us know.
{{ c.body }}