Hi, Jack

It still works fine for the decisions that have to be made. Changing the %
complete basis is an unnecessaqry detail and complication. One of those things
that people have to "get over", like driving to task dates or worrying how to
compute % complete within tasks.

Keep in mind that actual control comes from two other sources, both of which
work from TASK buffer impact, not the worst buffer impact for the project.
Neither relies on % complete. They are:
1. Multiproject prioritized task list, for each Task Manager to determine which
task to assign resources to next, and
2. Project chain view, which sorts all tasks in the project by buffer impact, to
plan buffer recovery.

Regards,
Larry Leach

--- In CriticalChain@yahoogroups.com, "Jack Vinson" <jackvinson@...> wrote:
>
> I assume the vertical axis is %buffer consumption.
>
> Interesting take on using Task Complete vs. just remaining duration (RDU).
> What happens when another chain becomes longer than the original critical
> chain? Realization use longest penetrating chain / original critical chain
> for the percent complete metric.
>
> Jack
>
> -----Original Message-----
> From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
> On Behalf Of Lawrence
> Sent: Tuesday, July 14, 2009 3:21 PM
> To: CriticalChain@yahoogroups.com
> Subject: [CriticalChain] Re: Buffer Penetration
>
> Hi, Jack
>
> Well, if there is something hidden, it is by poor communication, not by
> intent.
>
> I understand most people on this list do not understand the use of task
> buffer penetration as the tool to create prioritized task lists for Task
> Managers and resources, despite my best efforts to preach it. It is a very
> powerful approach. I learned it from the Realization folks.
>
> Actually, I think of the tasks as going up and down on the fever chart. I
> have chosen with my software to plot the fever chart vs. % critical chain
> COMPLETE, so changing the RDU on a task does not affect the points
> horizontal position: it isn't complete. So, that's an unstated assumption,
> anyway.
>
> Regards,
> Larry Leach
>