Robert -- Thanks for inviting me into this thread. I've been trying to come up with an approach to enter it without my usual knee-jerk provocative denigration of estimate accuracy as an oxymoron, since my intuition was telling me there was something worthwhile in John Kerrs control chart approach to learning, and your post helped me temper my words.
Estimates are obviously necessary to make promises, and if those promises are based on single-number estimates of tasks, then estimate accuracy can be justified as a virtue.
Now I'm usually a proponent of a "good enough" attitude toward estimates, relying on range estimating to develop buffered Critical Chain schedules. So I was struggling with why John Kerr's approach to learning about his capabilities had an appeal to me.
After getting over my surprise (and my suspicion that the appeal was based in my early career as a statndard-obsesed Industrial Engineer), and with the help of Robert's question, I realized that what John offered was an excellent tool for task estimating, although not necessarily necessary for initial planning estimates, but eminently applicable to current task status estimates used during project execution. (As a reminder for those not familar with CC, task updates during execution in that approach are a simple matter of estimates of duration to completion of the task at hand.)
Kerr's approach of doing his analysis concurrent with the task itself can help both that process as well as contribute to future learning for refinements of planning estimates. For those refinements, the range of performance indicated by his control charts would provide a nice starting point for thinking about the range estimates limited by the safe and the aggressive -- the CC approach to dealing with what Robert refers to as the confidence limit.
Now regarding how bad an estimate has to be to invalidate a project buffer...I'm not sure. I've never run into a situation where there wasn't enough intuition in a project team to develop a CC schedule that proved to be unmanageable, or one in which a surprising amount of remaining buffer at the end of the project couldn't be explained by new "relay race" behaviors supported by the CC approach.
Keep in mind that the original promise -- the original schedule, buffered or not -- is only a model of possible expectations. The inevitability of changing circumstance, the unknowable unknowns, and the general variability in task performace that is the nature of project work allows only a rough level of confidence in promises, unless they are managed in a way that suboptimizes performance so that actuals are driven to match estimates. Project success and promise keeping is much more a matter of managing execution than one of making the elusive accurate promise.
That in mind, I'd like to reiterate my appreciation for Kerr's control charts as a tool for dealing with estimating tasks similar to past work during execution.
