Thursday, April 27, 2006



Whenever I hear the word thrashing, one prominent image come to mind: that of a fish in a bucket or a shallow pool – flopping spasmodically, trying to fling itself back into deeper water.  This is thrashing.  You know that the probability of success is going to be very small and it tugs on your heart strings.  Even if you were the one who put that beautiful creature into the bucket in the first place, you still feel bad.
Some times even the most perfect project gets into a state where it thrashes.  Many times, the organization and the project manager hyper focus on the thrashing and damping it that they lose sight of the goal.  This becomes a text book case of solving for the local optima rather than global.  
Much of the time, thrashing becomes more evident when priorities change.  In plan driven projects that have well defined schedules and flows, all priority changes are represented by flurries of Change Requests.  Judicious use of the Change Order process can damp the oscillations; however, as you can imagine, they take a while to all damp out.  Though there is a sizeable impact on the project’s productivity during this damping effort, there is a larger one on the moral of the staff.  It is frequently during these cycles that I see the greatest organizational defection rates – reflective of the dramatic morale and stress changes.
As Jerry pointed out in the comment to the last post, think of the impact this type of behavior has at the portfolio level, if priorities of individual projects is allowed to vacillate.  Unfortunately, what would happen is digression into total instability grinding not only the projects to a halt, but the elimination of most if not all forward momentum of the organization itself.   Not a good thing to happen at all.
So, what about it?
Well, remember local versus global optima.  Think of the organization as a single line manufacturing plant.  The organization manufactures value (ok, I know it is too ephemeral, but go with it for now).  There are a bunch of complex looking machines down there on the floor that make up the line – they have cool names like Project A, Project B, and so forth.  Because we have a single line in our simple example, there is at least one dependency on each of the machines – some times they are resource dependencies, and sometimes they are input or output dependencies.  If we allow the priorities of each machine to fluctuate, the amount of work they can do changes as does the inventory buffer awaiting processing as well as the output pile on the other side (some other machine’s input buffer).  Thrashing can potentially get so bad that inventory dries up and the machines sit idle (the projects stall for lack of resources).  
As you can imagine, when you have tied all the projects/machines together by their dependencies, thrashing can have a very disruptive effect to the whole line.  
OK, so what about thrashing?
Well, rather than figure out how to mitigate the effects of the thrashing on the line, it would be far more valuable to understand what causes the thrashing to start.  If it indeed is started by reprioritizing one of the machines; rather than accommodating the change, the justification for the change ought to be sought first.  Can you answer the question why are we changing the priority on machine “Project D”?  Most of the time, you can, but the answer is shallow and will not answer the far more important question “How does changing the priority on machine “Project D” help us better achieve our organizational goal?


Post a Comment

<< Home