Mutually Assured Lateness
At the TOCE Upgrade for Critical Chain Project Management this week (January 9, 2007) and some of the discussions after the class have reminded me of issues and problems that I had experienced in my “past life” at GM. One of the terms we used there reflects a common problem seen in the CCPM world. The term is “Mutually Assured Lateness.”
Mutually Assured Lateness dictates that no matter how early or late you submitted a task to a constraint (or a resource on the Critical Chain), it would be released late by that resource by a fairly constant amount. In other words, if you delivered a task two weeks early to the resource or two weeks late, the task would always come out 4 weeks late.
The key to understanding why this occurs is the impact of multi-tasking. The resource itself was reacting to how it was being measured, rewarded, and punished. If the task came in early, then the resource reasoned that it could afford to wait, especially with the large number of tasks that it had to work on that were already late. Calls from the project manager could be easily deflected: "I have a lot of work that is much later than your stuff – it will have to wait – unless you can convince another PM to give up their spot on my To Do list to you. Which, by the way, has never happened since I took this job."
After this conversation, the project manager may elevate the issue. But his boss faces the same issue when trying to resolve the problem: "Hey, if you want to give up some of the extra budget or headcount to help out the other department, let me know." That’s a lose-lose scenario – if you had enough extra budget and/or headcount to begin with, you probably have been hiding that “fat”somewhere in your department, and can afford to lose even more in the future.
More importantly, everyone now has a viable deflection shield: "Hey, the constraint can’t seem to run his area well, nor can his boss. It’s not my fault if they can’t run their area as effectively as I can." Thus, the early tasks end up waiting in the queue.
The late tasks are already in trouble, and how late they are gives them some leverage on the constrained resource. Often the PM on this late project, since it has lasted several years, has already been replaced, with a professional “Squeaky Wheel,” who calls the resource every day (or more often) to get his or her work done. While this task is not completed early, it probably ends up happening earlier that other late tasks. The early task, if the PM is not as aggressive as the Squeaky Wheel, may just have been passed!
In the end, each of the tasks ends up being late by about the same amount – which resulted in the term – “mutually assured lateness.”
