I've not listened to this yet ...


http://800ceoread.com/podcasts/archives/008823.html

In this podcast, Jack Covert talks to Jeff Cox about how he got involved in
co-authoring the book *The
Goal*<http://800ceoread.com/products/?ISBN=9780884271789> --
a parable about the Theory of Constraints, and how people can overcome
barriers to make more money. Enlightening and revolutionary still today, the
book itself sold over 2 million copies. Listen to the podcast to hear about
some of the idea gems found in the book.
This book is one of the books in Jack and Todd's book The 100 Best Business
Books of All Time <http://100bestbiz.com/>.

---
Clarke Ching -
1.  Author of "Rolling Rocks Downhill" ... a business novel about software
development; coming soon from the Pragmatic Bookshelf.
2.  Author of "Rocks Into Gold" ... a biztech parable for developers who
want to THRIVE during the recession.  www.RocksIntoGold.com
www.clarkeching.com
Phone: 079 2011 4893


[Non-text portions of this message have been removed]

Hi, All

Good video. I wonder if the interviewer realized her question was not exactly
answered?

http://www.youtube.com/watch?v=0XqU-4dVkBE

Regards,
Larry

Larry,

I was agreeing with you and Tony. I agreed with your point about content,
and with Tony's point about poor project plans. Not everyone has weak
content, and not everyone has poor project plans. May I suggest discussing
with Tony precisely how bad project plans are, and who has them?

My focus is on content, and I found it particularly insightful that in a
chapter you contributed to a book on project management (I don't have that
book with me; perhaps you can supply the reference?) you specifically
mentioned that having a great plan, and delivering on time and on budget,
does not assure the project charter is satisfied (or that the business goals
for the project are met). Yes, I'm paraphrasing here, so I am open to
corrections.

As for ToC, in [modern] production settings content is not an issue - the
customer has already ordered want they want. Our task is to make it and get
it to them.

But for most project settings, it is quite possible to get the content
wrong, deliver it on time, and thoroughly dissatisfy the customer. CC PM
absolutely allows us to deliver on time (and gives us the time to get the
content right, if we have the wherewithal to do so). But both traditional PM
and CC PM need help, on those projects where the content is not dictated up
front. That's where I find QFD invaluable.

So what other complimentary practices have folks found helpful ?



Regards, Richard E. Zultner



[Non-text portions of this message have been removed]

Hi, Folks

Over the years, most of us have experienced skeptical questions or assertions
from our audiances. What say you about sharing some, and discuss how to handle
them in a way that might help the poor souls?

Here is one from last week, "We have to use due dates. If we don't use due dates
on tasks, nothing will ever get finished!"

My response to this one was to first assure them (there were two supporting each
other), that given the strength of their stated belief, the chances that
anything I said would influence their belief is much less than a
Christin/Jew/Muslim converting one of the others to their faith.

I pointed out that we hadn't yet gotten to how this would be accomplished
through buffer management; a powerful feedback mechanism that would enlist the
social forces of the whole team to compelte tasks ASAP.

I then assured them that even while it may be possible in their case they could
never achieve the desired effect, it has by now been achieved in hundreds of
companies and thousands of projects.

I concluded with the famous Henry Ford quote (possibly paraphrased), "If you
believe you can do it, or if you believe you can not do it, you are right!"

Want to share other ways to handle this one, or other ones?

(PS: I am pretty sure I did not convince them.)

Regards,
Larry Leach

Hi, Richard

Yes, I was delighted to agree with you on this. Actually, I know we agree on
most things, and usually just discuss here the ones we do not agree on.

I suspect the book you are referring to is:

Levine, H. (2005). Project Portfolio Management. San Francisco: Jossey Bass.

I did section 8.1: Applying the Theory of Constraints to Project Portfolio
Management (pp. 357-390)

It spends a lot of time on CC background, as I thought this audiance would be
fairly clueless on it. I promoted using estimates of variation when selecting
projects, and providing a corporate level measurement of project benefit
actually obtained. So far, I have not seen anyone do that. (IMHO, most claimes
"savings" from 6 sigma and Lean projects are fantasies...they don't really
happen. To my knowledge, they do not use metrics to track if the claims actually
affect the bottom line.)

Regards,
Larry Leach






--- In CriticalChain@yahoogroups.com, "Richard Zultner" <Richard@...> wrote:
>
> Larry,
>
> I was agreeing with you and Tony. I agreed with your point about content,
> and with Tony's point about poor project plans. Not everyone has weak
> content, and not everyone has poor project plans. May I suggest discussing
> with Tony precisely how bad project plans are, and who has them?
>
> My focus is on content, and I found it particularly insightful that in a
> chapter you contributed to a book on project management (I don't have that
> book with me; perhaps you can supply the reference?) you specifically
> mentioned that having a great plan, and delivering on time and on budget,
> does not assure the project charter is satisfied (or that the business goals
> for the project are met). Yes, I'm paraphrasing here, so I am open to
> corrections.
>
> As for ToC, in [modern] production settings content is not an issue - the
> customer has already ordered want they want. Our task is to make it and get
> it to them.
>
> But for most project settings, it is quite possible to get the content
> wrong, deliver it on time, and thoroughly dissatisfy the customer. CC PM
> absolutely allows us to deliver on time (and gives us the time to get the
> content right, if we have the wherewithal to do so). But both traditional PM
> and CC PM need help, on those projects where the content is not dictated up
> front. That's where I find QFD invaluable.
>
> So what other complimentary practices have folks found helpful ?
>
>
>
> Regards, Richard E. Zultner
>
>
>
> [Non-text portions of this message have been removed]
>

Great subject.



I have addressed these types of questions by throwing them back and asking,
"What would have to be true in your work environment for (issue) to work
here?" Then lead a conversation (fantasy?) about what would have to be true
for using the tools, or any other solution, to work in their environment. I
acknowledge that every group is different and although I can provide a
method, I cannot provide a solution. Once they voice what would have to be
true, then have them seek out the conflicts they face and bring them back to
the evaporating cloud. I have never done this for the question you propose,
but I have used this approach for many issues where the answer is "that
won't work here." It often works, but sometimes it's as you describe, a
religious issue. The person proposing the obstacle has no interest in
changing it. However, that shows up quickly in their responses. When I sense
this, I shift tactics and attempt to draw out why they personally don't want
to change.



From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Lawrence
Sent: Sunday, May 03, 2009 4:21 PM
To: CriticalChain@yahoogroups.com
Subject: [CriticalChain] Common Skeptical Questions or Comments








Hi, Folks

Over the years, most of us have experienced skeptical questions or
assertions from our audiances. What say you about sharing some, and discuss
how to handle them in a way that might help the poor souls?

Here is one from last week, "We have to use due dates. If we don't use due
dates on tasks, nothing will ever get finished!"

My response to this one was to first assure them (there were two supporting
each other), that given the strength of their stated belief, the chances
that anything I said would influence their belief is much less than a
Christin/Jew/Muslim converting one of the others to their faith.

I pointed out that we hadn't yet gotten to how this would be accomplished
through buffer management; a powerful feedback mechanism that would enlist
the social forces of the whole team to compelte tasks ASAP.

I then assured them that even while it may be possible in their case they
could never achieve the desired effect, it has by now been achieved in
hundreds of companies and thousands of projects.

I concluded with the famous Henry Ford quote (possibly paraphrased), "If you
believe you can do it, or if you believe you can not do it, you are right!"

Want to share other ways to handle this one, or other ones?

(PS: I am pretty sure I did not convince them.)

Regards,
Larry Leach





__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4050 (20090503) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



[Non-text portions of this message have been removed]

I do an exercise, with the manager.  I put the manager in the role of
a resource with three tasks before her.  I play the role of resource-
manager.  The new "resource" and I agree that all three tasks must be
completed correctly and quickly.  I then tell the "resource" to begin
working, and a few seconds after she begins, I remove two of the three
tasks.  When she looks up at me with surprise, I pretend to look at my
watch (I don't wear one).

The point is that a resource has only to choices, when properly
managed: The first choice is to work on the only task that the
managers instructs the resource to complete.  The second choice is not
to work on the task that the manager instructs the resource to
complete.  Ninety-nine people out of a hundred make the first choice,
as does the replacement of the hundredth.

Tony Rizzo
tony.rizzo@...
+1 908 264 8520 desk
+1 908 230 5348 mobile







On May 3, 2009, at 7:21 PM, Lawrence wrote:

>
>
> Hi, Folks
>
> Over the years, most of us have experienced skeptical questions or
> assertions from our audiances. What say you about sharing some, and
> discuss how to handle them in a way that might help the poor souls?
>
> Here is one from last week, "We have to use due dates. If we don't
> use due dates on tasks, nothing will ever get finished!"
>
> My response to this one was to first assure them (there were two
> supporting each other), that given the strength of their stated
> belief, the chances that anything I said would influence their
> belief is much less than a Christin/Jew/Muslim converting one of the
> others to their faith.
>
> I pointed out that we hadn't yet gotten to how this would be
> accomplished through buffer management; a powerful feedback
> mechanism that would enlist the social forces of the whole team to
> compelte tasks ASAP.
>
> I then assured them that even while it may be possible in their case
> they could never achieve the desired effect, it has by now been
> achieved in hundreds of companies and thousands of projects.
>
> I concluded with the famous Henry Ford quote (possibly paraphrased),
> "If you believe you can do it, or if you believe you can not do it,
> you are right!"
>
> Want to share other ways to handle this one, or other ones?
>
> (PS: I am pretty sure I did not convince them.)
>
> Regards,
> Larry Leach
>
>
>



[Non-text portions of this message have been removed]

You're crafty.



From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Anthony Rizzo
Sent: Sunday, May 03, 2009 11:09 PM
To: CriticalChain@yahoogroups.com
Subject: Re: [CriticalChain] Common Skeptical Questions or Comments








I do an exercise, with the manager. I put the manager in the role of
a resource with three tasks before her. I play the role of resource-
manager. The new "resource" and I agree that all three tasks must be
completed correctly and quickly. I then tell the "resource" to begin
working, and a few seconds after she begins, I remove two of the three
tasks. When she looks up at me with surprise, I pretend to look at my
watch (I don't wear one).

The point is that a resource has only to choices, when properly
managed: The first choice is to work on the only task that the
managers instructs the resource to complete. The second choice is not
to work on the task that the manager instructs the resource to
complete. Ninety-nine people out of a hundred make the first choice,
as does the replacement of the hundredth.

Tony Rizzo
tony.rizzo@... <mailto:tony.rizzo%40pdinstitute.com>
+1 908 264 8520 desk
+1 908 230 5348 mobile

On May 3, 2009, at 7:21 PM, Lawrence wrote:

>
>
> Hi, Folks
>
> Over the years, most of us have experienced skeptical questions or
> assertions from our audiances. What say you about sharing some, and
> discuss how to handle them in a way that might help the poor souls?
>
> Here is one from last week, "We have to use due dates. If we don't
> use due dates on tasks, nothing will ever get finished!"
>
> My response to this one was to first assure them (there were two
> supporting each other), that given the strength of their stated
> belief, the chances that anything I said would influence their
> belief is much less than a Christin/Jew/Muslim converting one of the
> others to their faith.
>
> I pointed out that we hadn't yet gotten to how this would be
> accomplished through buffer management; a powerful feedback
> mechanism that would enlist the social forces of the whole team to
> compelte tasks ASAP.
>
> I then assured them that even while it may be possible in their case
> they could never achieve the desired effect, it has by now been
> achieved in hundreds of companies and thousands of projects.
>
> I concluded with the famous Henry Ford quote (possibly paraphrased),
> "If you believe you can do it, or if you believe you can not do it,
> you are right!"
>
> Want to share other ways to handle this one, or other ones?
>
> (PS: I am pretty sure I did not convince them.)
>
> Regards,
> Larry Leach
>
>
>

[Non-text portions of this message have been removed]





__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4050 (20090503) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



[Non-text portions of this message have been removed]

Larry -
Interesting post. Their comment is probably true in their world.

I think it's important to point out that there's a huge difference --
paradigm shift, if you will -- between  trying to get everything done on
time, and trying to get things as early as possible. Most people don't
appreciate how significant this shift is. It's not hard to talk about how
due dates are self-reinforcing and lead to problems they probably
experience, including multitasking. (This is a central theme of "The
Billion Dollar Solution.") And it's not possible for one person in a large
organization to change this by themselves.

On the other hand, I suggest that in any such situation, telling people
that they're not going to believe you won't help your cause.

Rob

Rob Newbold
CEO
ProChain Solutions, Inc.
www.prochain.com
www.billiondollarsolution.com

Common Skeptical Questions or Comments
Posted by: "Lawrence" lawrence_leach@... lawrence_leach
Date: Sun May 3, 2009 4:22 pm ((PDT))

Hi, Folks

Over the years, most of us have experienced skeptical questions or
assertions from our audiances. What say you about sharing some, and discuss
how to handle them in a way that might help the poor souls?

Here is one from last week, "We have to use due dates. If we don't use due
dates on tasks, nothing will ever get finished!"

My response to this one was to first assure them (there were two supporting
each other), that given the strength of their stated belief, the chances
that anything I said would influence their belief is much less than a
Christin/Jew/Muslim converting one of the others to their faith.

I pointed out that we hadn't yet gotten to how this would be accomplished
through buffer management; a powerful feedback mechanism that would enlist
the social forces of the whole team to compelte tasks ASAP.

I then assured them that even while it may be possible in their case they
could never achieve the desired effect, it has by now been achieved in
hundreds of companies and thousands of projects.

I concluded with the famous Henry Ford quote (possibly paraphrased), "If
you believe you can do it, or if you believe you can not do it, you are
right!"

Want to share other ways to handle this one, or other ones?

(PS: I am pretty sure I did not convince them.)

Regards,
Larry Leach
<

Hi, Allan

OOOOHHHH...I like that!

Thanks.

Larry Leach



--- In CriticalChain@yahoogroups.com, "Allan" <aelder@...> wrote:
>
> Great subject.
>
>
>
> I have addressed these types of questions by throwing them back and asking,
> "What would have to be true in your work environment for (issue) to work
> here?" Then lead a conversation (fantasy?) about what would have to be true
> for using the tools, or any other solution, to work in their environment. I
> acknowledge that every group is different and although I can provide a
> method, I cannot provide a solution. Once they voice what would have to be
> true, then have them seek out the conflicts they face and bring them back to
> the evaporating cloud. I have never done this for the question you propose,
> but I have used this approach for many issues where the answer is "that
> won't work here." It often works, but sometimes it's as you describe, a
> religious issue. The person proposing the obstacle has no interest in
> changing it. However, that shows up quickly in their responses. When I sense
> this, I shift tactics and attempt to draw out why they personally don't want
> to change.
>
>
>
> From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
> On Behalf Of Lawrence
> Sent: Sunday, May 03, 2009 4:21 PM
> To: CriticalChain@yahoogroups.com
> Subject: [CriticalChain] Common Skeptical Questions or Comments
>
>
>
>
>
>
>
>
> Hi, Folks
>
> Over the years, most of us have experienced skeptical questions or
> assertions from our audiances. What say you about sharing some, and discuss
> how to handle them in a way that might help the poor souls?
>
> Here is one from last week, "We have to use due dates. If we don't use due
> dates on tasks, nothing will ever get finished!"
>
> My response to this one was to first assure them (there were two supporting
> each other), that given the strength of their stated belief, the chances
> that anything I said would influence their belief is much less than a
> Christin/Jew/Muslim converting one of the others to their faith.
>
> I pointed out that we hadn't yet gotten to how this would be accomplished
> through buffer management; a powerful feedback mechanism that would enlist
> the social forces of the whole team to compelte tasks ASAP.
>
> I then assured them that even while it may be possible in their case they
> could never achieve the desired effect, it has by now been achieved in
> hundreds of companies and thousands of projects.
>
> I concluded with the famous Henry Ford quote (possibly paraphrased), "If you
> believe you can do it, or if you believe you can not do it, you are right!"
>
> Want to share other ways to handle this one, or other ones?
>
> (PS: I am pretty sure I did not convince them.)
>
> Regards,
> Larry Leach
>
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature
> database 4050 (20090503) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> [Non-text portions of this message have been removed]
>

Hi, Tony

OOOHHHH....I like that too!

Larry

--- In CriticalChain@yahoogroups.com, Anthony Rizzo <Tony.Rizzo@...> wrote:
>
> I do an exercise, with the manager.  I put the manager in the role of
> a resource with three tasks before her.  I play the role of resource-
> manager.  The new "resource" and I agree that all three tasks must be
> completed correctly and quickly.  I then tell the "resource" to begin
> working, and a few seconds after she begins, I remove two of the three
> tasks.  When she looks up at me with surprise, I pretend to look at my
> watch (I don't wear one).
>
> The point is that a resource has only to choices, when properly
> managed: The first choice is to work on the only task that the
> managers instructs the resource to complete.  The second choice is not
> to work on the task that the manager instructs the resource to
> complete.  Ninety-nine people out of a hundred make the first choice,
> as does the replacement of the hundredth.
>
> Tony Rizzo
> tony.rizzo@...
> +1 908 264 8520 desk
> +1 908 230 5348 mobile
>
>
>
>
>
>
>
> On May 3, 2009, at 7:21 PM, Lawrence wrote:
>
> >
> >
> > Hi, Folks
> >
> > Over the years, most of us have experienced skeptical questions or
> > assertions from our audiances. What say you about sharing some, and
> > discuss how to handle them in a way that might help the poor souls?
> >
> > Here is one from last week, "We have to use due dates. If we don't
> > use due dates on tasks, nothing will ever get finished!"
> >
> > My response to this one was to first assure them (there were two
> > supporting each other), that given the strength of their stated
> > belief, the chances that anything I said would influence their
> > belief is much less than a Christin/Jew/Muslim converting one of the
> > others to their faith.
> >
> > I pointed out that we hadn't yet gotten to how this would be
> > accomplished through buffer management; a powerful feedback
> > mechanism that would enlist the social forces of the whole team to
> > compelte tasks ASAP.
> >
> > I then assured them that even while it may be possible in their case
> > they could never achieve the desired effect, it has by now been
> > achieved in hundreds of companies and thousands of projects.
> >
> > I concluded with the famous Henry Ford quote (possibly paraphrased),
> > "If you believe you can do it, or if you believe you can not do it,
> > you are right!"
> >
> > Want to share other ways to handle this one, or other ones?
> >
> > (PS: I am pretty sure I did not convince them.)
> >
> > Regards,
> > Larry Leach
> >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>

Hi, Folks

Some great ideas on that one!

I was hoping for more issues/questions/assertions.

OK, let me try a couple more. This is actually the most common one,

"No resources will buy cutting their tasks in half!"

A somewhat related one is,

"I know how long the task takes. X days. No exceptions."

I have lots more, but would like to hear from others.

Larry Leach



--- In CriticalChain@yahoogroups.com, "Lawrence" <lawrence_leach@...> wrote:
>
> Hi, Tony
>
> OOOHHHH....I like that too!
>
> Larry
>
> --- In CriticalChain@yahoogroups.com, Anthony Rizzo <Tony.Rizzo@> wrote:
> >
> > I do an exercise, with the manager.  I put the manager in the role of
> > a resource with three tasks before her.  I play the role of resource-
> > manager.  The new "resource" and I agree that all three tasks must be
> > completed correctly and quickly.  I then tell the "resource" to begin
> > working, and a few seconds after she begins, I remove two of the three
> > tasks.  When she looks up at me with surprise, I pretend to look at my
> > watch (I don't wear one).
> >
> > The point is that a resource has only to choices, when properly
> > managed: The first choice is to work on the only task that the
> > managers instructs the resource to complete.  The second choice is not
> > to work on the task that the manager instructs the resource to
> > complete.  Ninety-nine people out of a hundred make the first choice,
> > as does the replacement of the hundredth.
> >
> > Tony Rizzo
> > tony.rizzo@
> > +1 908 264 8520 desk
> > +1 908 230 5348 mobile
> >
> >
> >
> >
> >
> >
> >
> > On May 3, 2009, at 7:21 PM, Lawrence wrote:
> >
> > >
> > >
> > > Hi, Folks
> > >
> > > Over the years, most of us have experienced skeptical questions or
> > > assertions from our audiances. What say you about sharing some, and
> > > discuss how to handle them in a way that might help the poor souls?
> > >
> > > Here is one from last week, "We have to use due dates. If we don't
> > > use due dates on tasks, nothing will ever get finished!"
> > >
> > > My response to this one was to first assure them (there were two
> > > supporting each other), that given the strength of their stated
> > > belief, the chances that anything I said would influence their
> > > belief is much less than a Christin/Jew/Muslim converting one of the
> > > others to their faith.
> > >
> > > I pointed out that we hadn't yet gotten to how this would be
> > > accomplished through buffer management; a powerful feedback
> > > mechanism that would enlist the social forces of the whole team to
> > > compelte tasks ASAP.
> > >
> > > I then assured them that even while it may be possible in their case
> > > they could never achieve the desired effect, it has by now been
> > > achieved in hundreds of companies and thousands of projects.
> > >
> > > I concluded with the famous Henry Ford quote (possibly paraphrased),
> > > "If you believe you can do it, or if you believe you can not do it,
> > > you are right!"
> > >
> > > Want to share other ways to handle this one, or other ones?
> > >
> > > (PS: I am pretty sure I did not convince them.)
> > >
> > > Regards,
> > > Larry Leach
> > >
> > >
> > >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the CriticalChain
group.

   File        : /Reduce_WIP.pdf
   Uploaded by : lawrence_leach <lawrence_leach@...>
   Description : Little's Law and WIP Reduction

You can access this file at the URL:
http://groups.yahoo.com/group/CriticalChain/files/Reduce_WIP.pdf

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

lawrence_leach <lawrence_leach@...>

Hi, Folks

Returning to Little's Law. Some of you may remember my dissatisfaction with it
following a presentation I heard last fall. I was not able to reconcile the
implication that increasing WIP increased T, when I knew the inverse to be true.

Well, I have achieved harmony with it.

I'd appreciate comments on the little FRT posted in the files area: Reduce_WIP.

Regards,
Larry Leach

Ummm, I wouldn't expect resources to buy into cutting their tasks in half,
nor would I approach finalizing the validity of the schedule by recommending
such action.



   _____

From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Lawrence
Sent: Monday, May 04, 2009 5:45 PM
To: CriticalChain@yahoogroups.com
Subject: [CriticalChain] Re: Common Skeptical Questions or Comments



Hi, Folks

Some great ideas on that one!

I was hoping for more issues/questions/assertions.

OK, let me try a couple more. This is actually the most common one,

"No resources will buy cutting their tasks in half!"

A somewhat related one is,

"I know how long the task takes. X days. No exceptions."

I have lots more, but would like to hear from others.

Larry Leach

--- In CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com, "Lawrence" <lawrence_leach@...> wrote:





[Non-text portions of this message have been removed]

Ok...I will bite...why not?

John Loucks CMA MBA
Managing Partner
Visual Results

905 301-0643

Visual Consulting Since 2002
Member of the "Theory of Constraints International Certification
Organization"


________________________________

From: CriticalChain@yahoogroups.com
[mailto:CriticalChain@yahoogroups.com] On Behalf Of Michael Kasiak
Sent: Monday, May 04, 2009 7:10 PM
To: CriticalChain@yahoogroups.com
Subject: RE: [CriticalChain] Re: Common Skeptical Questions or Comments





Ummm, I wouldn't expect resources to buy into cutting their tasks in
half,
nor would I approach finalizing the validity of the schedule by
recommending
such action.

_____

From: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
[mailto:CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> ]
On Behalf Of Lawrence
Sent: Monday, May 04, 2009 5:45 PM
To: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
Subject: [CriticalChain] Re: Common Skeptical Questions or Comments

Hi, Folks

Some great ideas on that one!

I was hoping for more issues/questions/assertions.

OK, let me try a couple more. This is actually the most common one,

"No resources will buy cutting their tasks in half!"

A somewhat related one is,

"I know how long the task takes. X days. No exceptions."

I have lots more, but would like to hear from others.

Larry Leach

--- In CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com, "Lawrence" <lawrence_leach@...> wrote:

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

John Loucks writes:

  >: Ok...I will bite...why not?


... because the very managers who would cut in half the estimates of
duration provided by the resources quite probably have responded with
a reprimand or with some sort of punitive action in the past, when
resources have been unable to complete tasks within the managers'
already crammed window of expectation.  It's that human-intelligence
thing. Damned stuff always gets in the way of progress, don't it?


Tony Rizzo
tony.rizzo@...
+1 908 264 8520 desk
+1 908 230 5348 mobile







On May 4, 2009, at 11:31 PM, John Loucks wrote:

>
>
> Ok...I will bite...why not?
>
> John Loucks CMA MBA
> Managing Partner
> Visual Results
>
> 905 301-0643
>
> Visual Consulting Since 2002
> Member of the "Theory of Constraints International Certification
> Organization"
>
>
> ________________________________
>
> From: CriticalChain@yahoogroups.com
> [mailto:CriticalChain@yahoogroups.com] On Behalf Of Michael Kasiak
> Sent: Monday, May 04, 2009 7:10 PM
> To: CriticalChain@yahoogroups.com
> Subject: RE: [CriticalChain] Re: Common Skeptical Questions or
> Comments
>
> Ummm, I wouldn't expect resources to buy into cutting their tasks in
> half,
> nor would I approach finalizing the validity of the schedule by
> recommending
> such action.
>
> _____
>
> From: CriticalChain@yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com>
> [mailto:CriticalChain@yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com> ]
> On Behalf Of Lawrence
> Sent: Monday, May 04, 2009 5:45 PM
> To: CriticalChain@yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com>
> Subject: [CriticalChain] Re: Common Skeptical Questions or Comments
>
> Hi, Folks
>
> Some great ideas on that one!
>
> I was hoping for more issues/questions/assertions.
>
> OK, let me try a couple more. This is actually the most common one,
>
> "No resources will buy cutting their tasks in half!"
>
> A somewhat related one is,
>
> "I know how long the task takes. X days. No exceptions."
>
> I have lots more, but would like to hear from others.
>
> Larry Leach
>
> --- In CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
> yahoogroups.com, "Lawrence" <lawrence_leach@...> wrote:
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>



[Non-text portions of this message have been removed]

Glad it's helpful. I actually got the idea from reading the book "Loving
What Is" and modifying her approach a little.



She asks three questions: (1) Is that true? (2) How can you know that's
true? And (3) Who would you be without that thought. Doesn't seem related, I
know. But the questions got me to thinking.



From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Lawrence
Sent: Monday, May 04, 2009 2:40 PM
To: CriticalChain@yahoogroups.com
Subject: [CriticalChain] Re: Common Skeptical Questions or Comments








Hi, Allan

OOOOHHHH...I like that!

Thanks.

Larry Leach

--- In CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> , "Allan" <aelder@...> wrote:
>
> Great subject.
>
>
>
> I have addressed these types of questions by throwing them back and
asking,
> "What would have to be true in your work environment for (issue) to work
> here?" Then lead a conversation (fantasy?) about what would have to be
true
> for using the tools, or any other solution, to work in their environment.
I
> acknowledge that every group is different and although I can provide a
> method, I cannot provide a solution. Once they voice what would have to be
> true, then have them seek out the conflicts they face and bring them back
to
> the evaporating cloud. I have never done this for the question you
propose,
> but I have used this approach for many issues where the answer is "that
> won't work here." It often works, but sometimes it's as you describe, a
> religious issue. The person proposing the obstacle has no interest in
> changing it. However, that shows up quickly in their responses. When I
sense
> this, I shift tactics and attempt to draw out why they personally don't
want
> to change.
>
>
>
> From: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
[mailto:CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> ]
> On Behalf Of Lawrence
> Sent: Sunday, May 03, 2009 4:21 PM
> To: CriticalChain@yahoogroups.com <mailto:CriticalChain%40yahoogroups.com>

> Subject: [CriticalChain] Common Skeptical Questions or Comments
>
>
>
>
>
>
>
>
> Hi, Folks
>
> Over the years, most of us have experienced skeptical questions or
> assertions from our audiances. What say you about sharing some, and
discuss
> how to handle them in a way that might help the poor souls?
>
> Here is one from last week, "We have to use due dates. If we don't use due
> dates on tasks, nothing will ever get finished!"
>
> My response to this one was to first assure them (there were two
supporting
> each other), that given the strength of their stated belief, the chances
> that anything I said would influence their belief is much less than a
> Christin/Jew/Muslim converting one of the others to their faith.
>
> I pointed out that we hadn't yet gotten to how this would be accomplished
> through buffer management; a powerful feedback mechanism that would enlist
> the social forces of the whole team to compelte tasks ASAP.
>
> I then assured them that even while it may be possible in their case they
> could never achieve the desired effect, it has by now been achieved in
> hundreds of companies and thousands of projects.
>
> I concluded with the famous Henry Ford quote (possibly paraphrased), "If
you
> believe you can do it, or if you believe you can not do it, you are
right!"
>
> Want to share other ways to handle this one, or other ones?
>
> (PS: I am pretty sure I did not convince them.)
>
> Regards,
> Larry Leach
>
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
signature
> database 4050 (20090503) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> [Non-text portions of this message have been removed]
>





__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4052 (20090504) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



[Non-text portions of this message have been removed]

Sorry I forgot the discussion was about common objections rather than
surmountable issues. In the context of the question it makes sense
thanks.

John Loucks CMA MBA
Managing Partner
Visual Results

905 301-0643

Visual Consulting Since 2002
Member of the "Theory of Constraints International Certification
Organization"


________________________________

From: CriticalChain@yahoogroups.com
[mailto:CriticalChain@yahoogroups.com] On Behalf Of Anthony Rizzo
Sent: Tuesday, May 05, 2009 1:30 AM
To: CriticalChain@yahoogroups.com
Subject: Re: [CriticalChain] Re: Common Skeptical Questions or Comments





John Loucks writes:

>: Ok...I will bite...why not?

... because the very managers who would cut in half the estimates of
duration provided by the resources quite probably have responded with
a reprimand or with some sort of punitive action in the past, when
resources have been unable to complete tasks within the managers'
already crammed window of expectation. It's that human-intelligence
thing. Damned stuff always gets in the way of progress, don't it?

Tony Rizzo
tony.rizzo@... <mailto:tony.rizzo%40pdinstitute.com>
+1 908 264 8520 desk
+1 908 230 5348 mobile

On May 4, 2009, at 11:31 PM, John Loucks wrote:

>
>
> Ok...I will bite...why not?
>
> John Loucks CMA MBA
> Managing Partner
> Visual Results
>
> 905 301-0643
>
> Visual Consulting Since 2002
> Member of the "Theory of Constraints International Certification
> Organization"
>
>
> ________________________________
>
> From: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
> [mailto:CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> ] On Behalf Of Michael Kasiak
> Sent: Monday, May 04, 2009 7:10 PM
> To: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
> Subject: RE: [CriticalChain] Re: Common Skeptical Questions or
> Comments
>
> Ummm, I wouldn't expect resources to buy into cutting their tasks in
> half,
> nor would I approach finalizing the validity of the schedule by
> recommending
> such action.
>
> _____
>
> From: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
> <mailto:CriticalChain%40yahoogroups.com>
> [mailto:CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
> <mailto:CriticalChain%40yahoogroups.com> ]
> On Behalf Of Lawrence
> Sent: Monday, May 04, 2009 5:45 PM
> To: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
> <mailto:CriticalChain%40yahoogroups.com>
> Subject: [CriticalChain] Re: Common Skeptical Questions or Comments
>
> Hi, Folks
>
> Some great ideas on that one!
>
> I was hoping for more issues/questions/assertions.
>
> OK, let me try a couple more. This is actually the most common one,
>
> "No resources will buy cutting their tasks in half!"
>
> A somewhat related one is,
>
> "I know how long the task takes. X days. No exceptions."
>
> I have lots more, but would like to hear from others.
>
> Larry Leach
>
> --- In CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
> yahoogroups.com, "Lawrence" <lawrence_leach@...> wrote:
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

Why not? Well, for me it's about building a culture of trust in the
organization. That includes developing good communication between various
levels of management. Just cutting a task time in half doesn't help anyone
communicate what's really involved in the task execution-and in my
experience, this is necessary to gain greater understanding of the overall
project and avoids problems developing later on.



Of course, it takes a bit longer to build the project plan. But for me it
builds a more solid foundation that is more likely to last. It also takes
proper education to bring the company to the point of being able to
communicate well about the project.



I suppose cutting task times in half could work, though. I've never tried
it. I've heard people who have done it. I just don't operate that way.



Also, if task times are arbitrarily cut in half, I wouldn't be confident in
the critical chain, or the overall project duration. It could also affect
your resource loading projections in a way that is too far from reality.





   _____

From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of John Loucks
Sent: Monday, May 04, 2009 11:31 PM
To: CriticalChain@yahoogroups.com
Subject: RE: [CriticalChain] Re: Common Skeptical Questions or Comments



Ok...I will bite...why not?

John Loucks CMA MBA
Managing Partner
Visual Results

905 301-0643

Visual Consulting Since 2002
Member of the "Theory of Constraints International Certification
Organization"


________________________________

From: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com
[mailto:CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com] On Behalf Of Michael Kasiak
Sent: Monday, May 04, 2009 7:10 PM
To: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com> yahoogroups.com
Subject: RE: [CriticalChain] Re: Common Skeptical Questions or Comments

Ummm, I wouldn't expect resources to buy into cutting their tasks in
half,
nor would I approach finalizing the validity of the schedule by
recommending
such action.

_____

From: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
[mailto:CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> ]
On Behalf Of Lawrence
Sent: Monday, May 04, 2009 5:45 PM
To: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com> yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
Subject: [CriticalChain] Re: Common Skeptical Questions or Comments

Hi, Folks

Some great ideas on that one!

I was hoping for more issues/questions/assertions.

OK, let me try a couple more. This is actually the most common one,

"No resources will buy cutting their tasks in half!"

A somewhat related one is,

"I know how long the task takes. X days. No exceptions."

I have lots more, but would like to hear from others.

Larry Leach






[Non-text portions of this message have been removed]

Another good point, Tony.



As a resource myself, I witnessed management demand all sorts of impossible,
idiotic things. What would keep me from laughing at them if they cut task
times in half? I need them to understand my work from my point of view, and
sympathize with my reality. Those are the kinds of things that begin to
build long-term trust in the organization.



   _____

From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Anthony Rizzo
Sent: Tuesday, May 05, 2009 1:30 AM
To: CriticalChain@yahoogroups.com
Subject: Re: [CriticalChain] Re: Common Skeptical Questions or Comments



John Loucks writes:

>: Ok...I will bite...why not?

... because the very managers who would cut in half the estimates of
duration provided by the resources quite probably have responded with
a reprimand or with some sort of punitive action in the past, when
resources have been unable to complete tasks within the managers'
already crammed window of expectation. It's that human-intelligence
thing. Damned stuff always gets in the way of progress, don't it?

Tony Rizzo
tony.rizzo@pdinstit <mailto:tony.rizzo%40pdinstitute.com> ute.com
+1 908 264 8520 desk
+1 908 230 5348 mobile

On May 4, 2009, at 11:31 PM, John Loucks wrote:

>
>
> Ok...I will bite...why not?
>
> John Loucks CMA MBA
> Managing Partner
> Visual Results
>
> 905 301-0643
>
> Visual Consulting Since 2002
> Member of the "Theory of Constraints International Certification
> Organization"
>
>
> ________________________________
>
> From: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com
> [mailto:CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com] On Behalf Of Michael Kasiak
> Sent: Monday, May 04, 2009 7:10 PM
> To: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com
> Subject: RE: [CriticalChain] Re: Common Skeptical Questions or
> Comments
>
> Ummm, I wouldn't expect resources to buy into cutting their tasks in
> half,
> nor would I approach finalizing the validity of the schedule by
> recommending
> such action.
>
> _____
>
> From: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com>
> [mailto:CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com> ]
> On Behalf Of Lawrence
> Sent: Monday, May 04, 2009 5:45 PM
> To: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com>
> Subject: [CriticalChain] Re: Common Skeptical Questions or Comments
>
> Hi, Folks
>
> Some great ideas on that one!
>
> I was hoping for more issues/questions/assertions.
>
> OK, let me try a couple more. This is actually the most common one,
>
> "No resources will buy cutting their tasks in half!"
>
> A somewhat related one is,
>
> "I know how long the task takes. X days. No exceptions."
>
> I have lots more, but would like to hear from others.
>
> Larry Leach
>





[Non-text portions of this message have been removed]

Hi, Folks

Posted a little better diagram under the title "Reduce WIP".

Larry

--- In CriticalChain@yahoogroups.com, "Lawrence" <lawrence_leach@...> wrote:
>
> Hi, Folks
>
> Returning to Little's Law. Some of you may remember my dissatisfaction with it
following a presentation I heard last fall. I was not able to reconcile the
implication that increasing WIP increased T, when I knew the inverse to be true.
>
> Well, I have achieved harmony with it.
>
> I'd appreciate comments on the little FRT posted in the files area:
Reduce_WIP.
>
> Regards,
> Larry Leach
>

Hi, Michael

"Just cutting task times in half" and "arbitrary" are your characterizations. I
don't know anyone who does exactly either of those for the final schedule. The
statement and approach are short cuts. More often than not, the actual cuts
needed are much more than half.

Most people are quite happy with the simplified approach for most tasks, once
they understand that buffering means that they actually have more time for all
tasks. It is usually just a noisy few that object.

I suggest if you do not have anothter basis (and most do not), since we want to
move from low risk estimates to mean estimates, you must first reduce the task
duration to get the driving resource to (at least) 100%, and then one way to
estimate the mean duration from that is to use one half of that estimate. It
often results in cutting durations by dividing by five or ten. Most are OK with
that. Some go nuts.

Some tasks do not get cut at all, because it makes no sense to do so; e.g.
generations of mice or patient exposure times; aka "oven" tasks. Then they do
not figure into the buffer, either.

Asking people for mean estimates rarely works. I have tried it many times (slow
learner), back when we used to use two estimates. Most think the mean is no less
than 2/3 of the 90% estimate, and some insist it is at most 5% less. That comes
about for several pschological reasons.

If you do not cut the estimates substantially from past history, anchoring
ensures that your actual durations are not cut much, either. If you have data
otherwise, I'd love to see it.

The real understanding is that it should not matter at all to the performing
resource what the initial task estimate is, other than as a member of the team
trying to get a valid overall schedule. They need to get over the attachment to
"MY" task estimate. Yes, that usually does involve a new level of trust.

However, to the point at hand, no logical argument matters, because it is an
emotional objection for the few who go nuts. So we are back to the point of how
to respond to such objections.

Regards,
Larry Leach




--- In CriticalChain@yahoogroups.com, "Michael Kasiak" <msk779@...> wrote:
>
> Why not? Well, for me it's about building a culture of trust in the
> organization. That includes developing good communication between various
> levels of management. Just cutting a task time in half doesn't help anyone
> communicate what's really involved in the task execution-and in my
> experience, this is necessary to gain greater understanding of the overall
> project and avoids problems developing later on.
>
>
>
> Of course, it takes a bit longer to build the project plan. But for me it
> builds a more solid foundation that is more likely to last. It also takes
> proper education to bring the company to the point of being able to
> communicate well about the project.
>
>
>
> I suppose cutting task times in half could work, though. I've never tried
> it. I've heard people who have done it. I just don't operate that way.
>
>
>
> Also, if task times are arbitrarily cut in half, I wouldn't be confident in
> the critical chain, or the overall project duration. It could also affect
> your resource loading projections in a way that is too far from reality.
>

Mike writes:

  >: Well, for me it's about building a culture of trust....


Hear!  Hear!

The practice of cutting estimates also puts the primary system of a
business on a process of ongoing degradation:  The mangers cut.  The
resources observe the cuts.  The resources adjust the subsequent
estimates accordingly.  The managers observes the adjustment of the
subsequent estimates.  The managers cut by more.  The resources adjust
by more.  The managers cut by more.  ... and more.  ... and more.

A far superior approach is to inform the senior executive and the
managers that the initial new models of projects are going to be every
bit as wrong as their old models, with respect to duration.
Consequently, the managers should respond with one statement and one
statement alone, to the first new model (plan) from every team: "Thank
you for your help!"

"Thank you" is the only acceptable response, particularly from the
most senior person, for two reasons:  First, with this response the
leadership and the managers afford themselves the opportunity to shape
the behavior not only of the first few teams but also that of every
other team, through the experiences of the first few.

Second, if the resources of a primary system are managed properly,
logistical performance ceases to be a function of all calculations of
duration, and the plans begin to be perceived and used for what they
really are:  Plans are models with which we calculate estimates of
duration to completion, and that's all that they are.

The jerk-response of blurting out "The plan's too long.  It's
unacceptable.  Make it shorter," often kills the entire improvement
effort immediately.  It squanders the vast amount of additional
performance (logistical and financial) that the effort can bring
within reach.  Any action on the part of an executive or a manager,
which jeopardizes all that cash for the sake of creating a few
fictitious pictures of short projects, isn't merely a damned stupid
thing to do.  It's an act of criminal negligence.  It's also damned
stupid from the perspective of the those executives inclined to
provide such a jerk-response, because all too often it prevents them
from earning additional megabucks in bonuses.

The massive amounts of wasted money are precisely the reason why the
focus must be, first, last, forever, and to an overwhelming degree, on
creating the mechanism of speed, rather than creating "critical-chain
plans" that look short and pretty.

I'll say this until I'm ready for my grave:  Plans are nothing more
than predictive models of physical systems.  All predictive models
first and foremost must reflect the important characteristics of the
physical systems that they represent.  Therefore, until the behaviors
exist widely within an organization, which behaviors enable an
improved level of performance for the primary system, no one has any
business building a plan that assumes behaviors other than the rotten
behaviors that prevail at the time that the plan is in use.

Tony Rizzo
tony.rizzo@...
+1 908 264 8520 desk
+1 908 230 5348 mobile







On May 5, 2009, at 7:54 AM, Michael Kasiak wrote:

>
>
> Why not? Well, for me it's about building a culture of trust in the
> organization. That includes developing good communication between
> various
> levels of management. Just cutting a task time in half doesn't help
> anyone
> communicate what's really involved in the task execution-and in my
> experience, this is necessary to gain greater understanding of the
> overall
> project and avoids problems developing later on.
>
> Of course, it takes a bit longer to build the project plan. But for
> me it
> builds a more solid foundation that is more likely to last. It also
> takes
> proper education to bring the company to the point of being able to
> communicate well about the project.
>
> I suppose cutting task times in half could work, though. I've never
> tried
> it. I've heard people who have done it. I just don't operate that way.
>
> Also, if task times are arbitrarily cut in half, I wouldn't be
> confident in
> the critical chain, or the overall project duration. It could also
> affect
> your resource loading projections in a way that is too far from
> reality.
>
> _____
>
> From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com
> ]
> On Behalf Of John Loucks
> Sent: Monday, May 04, 2009 11:31 PM
> To: CriticalChain@yahoogroups.com
> Subject: RE: [CriticalChain] Re: Common Skeptical Questions or
> Comments
>
> Ok...I will bite...why not?
>
> John Loucks CMA MBA
> Managing Partner
> Visual Results
>
> 905 301-0643
>
> Visual Consulting Since 2002
> Member of the "Theory of Constraints International Certification
> Organization"
>
> ________________________________
>
> From: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
> yahoogroups.com
> [mailto:CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
> yahoogroups.com] On Behalf Of Michael Kasiak
> Sent: Monday, May 04, 2009 7:10 PM
> To: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
> yahoogroups.com
> Subject: RE: [CriticalChain] Re: Common Skeptical Questions or
> Comments
>
> Ummm, I wouldn't expect resources to buy into cutting their tasks in
> half,
> nor would I approach finalizing the validity of the schedule by
> recommending
> such action.
>
> _____
>
> From: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
> yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com>
> [mailto:CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
> yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com> ]
> On Behalf Of Lawrence
> Sent: Monday, May 04, 2009 5:45 PM
> To: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
> yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com>
> Subject: [CriticalChain] Re: Common Skeptical Questions or Comments
>
> Hi, Folks
>
> Some great ideas on that one!
>
> I was hoping for more issues/questions/assertions.
>
> OK, let me try a couple more. This is actually the most common one,
>
> "No resources will buy cutting their tasks in half!"
>
> A somewhat related one is,
>
> "I know how long the task takes. X days. No exceptions."
>
> I have lots more, but would like to hear from others.
>
> Larry Leach
>
> [Non-text portions of this message have been removed]
>
>
>



[Non-text portions of this message have been removed]

Hi, Tony

I agree fully with your penultimate paragrpah.

As a practical matter, I don't understand how people know what to task to work
on without project schedules. For me, that is actually the primary function of
the schedules; with the end date being secondary.

Regards,
Larry Leach

--- In CriticalChain@yahoogroups.com, Anthony Rizzo <Tony.Rizzo@...> wrote:
>
> Mike writes:
>
>  >: Well, for me it's about building a culture of trust....
>
>
> Hear!  Hear!
>
> The practice of cutting estimates also puts the primary system of a
> business on a process of ongoing degradation:  The mangers cut.  The
> resources observe the cuts.  The resources adjust the subsequent
> estimates accordingly.  The managers observes the adjustment of the
> subsequent estimates.  The managers cut by more.  The resources adjust
> by more.  The managers cut by more.  ... and more.  ... and more.
>
> A far superior approach is to inform the senior executive and the
> managers that the initial new models of projects are going to be every
> bit as wrong as their old models, with respect to duration.
> Consequently, the managers should respond with one statement and one
> statement alone, to the first new model (plan) from every team: "Thank
> you for your help!"
>
> "Thank you" is the only acceptable response, particularly from the
> most senior person, for two reasons:  First, with this response the
> leadership and the managers afford themselves the opportunity to shape
> the behavior not only of the first few teams but also that of every
> other team, through the experiences of the first few.
>
> Second, if the resources of a primary system are managed properly,
> logistical performance ceases to be a function of all calculations of
> duration, and the plans begin to be perceived and used for what they
> really are:  Plans are models with which we calculate estimates of
> duration to completion, and that's all that they are.
>
> The jerk-response of blurting out "The plan's too long.  It's
> unacceptable.  Make it shorter," often kills the entire improvement
> effort immediately.  It squanders the vast amount of additional
> performance (logistical and financial) that the effort can bring
> within reach.  Any action on the part of an executive or a manager,
> which jeopardizes all that cash for the sake of creating a few
> fictitious pictures of short projects, isn't merely a damned stupid
> thing to do.  It's an act of criminal negligence.  It's also damned
> stupid from the perspective of the those executives inclined to
> provide such a jerk-response, because all too often it prevents them
> from earning additional megabucks in bonuses.
>
> The massive amounts of wasted money are precisely the reason why the
> focus must be, first, last, forever, and to an overwhelming degree, on
> creating the mechanism of speed, rather than creating "critical-chain
> plans" that look short and pretty.
>
> I'll say this until I'm ready for my grave:  Plans are nothing more
> than predictive models of physical systems.  All predictive models
> first and foremost must reflect the important characteristics of the
> physical systems that they represent.  Therefore, until the behaviors
> exist widely within an organization, which behaviors enable an
> improved level of performance for the primary system, no one has any
> business building a plan that assumes behaviors other than the rotten
> behaviors that prevail at the time that the plan is in use.
>
> Tony Rizzo
> tony.rizzo@...
> +1 908 264 8520 desk
> +1 908 230 5348 mobile

> As a practical matter, I don't understand how people know what to
> task to work on without project schedules. For me, that is actually
> the primary function of the schedules; with the end date being
> secondary.

The network-diagram, which shows the activities, the assigned
resources, and the relationships among the activities, certainly must
exist.  This is how we know which tasks should be active at any point
of a project.  However, any calculation of duration-to-completion has
no basis, when an organization's history consists of nothing but
widespread multitasking.

The hierarchical criteria for a good plan are:

	 1) accuracy w.r.t. tangible deliverables (this is the "destination")
	 2) accuracy w.r.t. logistics (this is the itinerary)
	 3) accuracy w.r.t. duration to completion (this criterion can't be
met initially - no data)
	 4) accuracy w.r.t. variable cost (data for this usually is available
readily)

A good process for planning at the very least must start with a list
of tangible deliverables that satisfies item 1 and provides an output
that satisfies item 2.  However, item 3 requires data.  No such data
is available to any organization initially, which reflects an
operation with properly managed resources.  Therefore, no credible
calculation of duration-to-completion is possible initially.

Tony Rizzo
tony.rizzo@...
+1 908 264 8520 desk
+1 908 230 5348 mobile







On May 5, 2009, at 12:52 PM, Lawrence wrote:

>
>
> Hi, Tony
>
> I agree fully with your penultimate paragrpah.
>
> As a practical matter, I don't understand how people know what to
> task to work on without project schedules. For me, that is actually
> the primary function of the schedules; with the end date being
> secondary.
>
> Regards,
> Larry Leach
>
> --- In CriticalChain@yahoogroups.com, Anthony Rizzo <Tony.Rizzo@...>
> wrote:
> >
> > Mike writes:
> >
> > >: Well, for me it's about building a culture of trust....
> >
> >
> > Hear! Hear!
> >
> > The practice of cutting estimates also puts the primary system of a
> > business on a process of ongoing degradation: The mangers cut. The
> > resources observe the cuts. The resources adjust the subsequent
> > estimates accordingly. The managers observes the adjustment of the
> > subsequent estimates. The managers cut by more. The resources adjust
> > by more. The managers cut by more. ... and more. ... and more.
> >
> > A far superior approach is to inform the senior executive and the
> > managers that the initial new models of projects are going to be
> every
> > bit as wrong as their old models, with respect to duration.
> > Consequently, the managers should respond with one statement and one
> > statement alone, to the first new model (plan) from every team:
> "Thank
> > you for your help!"
> >
> > "Thank you" is the only acceptable response, particularly from the
> > most senior person, for two reasons: First, with this response the
> > leadership and the managers afford themselves the opportunity to
> shape
> > the behavior not only of the first few teams but also that of every
> > other team, through the experiences of the first few.
> >
> > Second, if the resources of a primary system are managed properly,
> > logistical performance ceases to be a function of all calculations
> of
> > duration, and the plans begin to be perceived and used for what they
> > really are: Plans are models with which we calculate estimates of
> > duration to completion, and that's all that they are.
> >
> > The jerk-response of blurting out "The plan's too long. It's
> > unacceptable. Make it shorter," often kills the entire improvement
> > effort immediately. It squanders the vast amount of additional
> > performance (logistical and financial) that the effort can bring
> > within reach. Any action on the part of an executive or a manager,
> > which jeopardizes all that cash for the sake of creating a few
> > fictitious pictures of short projects, isn't merely a damned stupid
> > thing to do. It's an act of criminal negligence. It's also damned
> > stupid from the perspective of the those executives inclined to
> > provide such a jerk-response, because all too often it prevents them
> > from earning additional megabucks in bonuses.
> >
> > The massive amounts of wasted money are precisely the reason why the
> > focus must be, first, last, forever, and to an overwhelming
> degree, on
> > creating the mechanism of speed, rather than creating "critical-
> chain
> > plans" that look short and pretty.
> >
> > I'll say this until I'm ready for my grave: Plans are nothing more
> > than predictive models of physical systems. All predictive models
> > first and foremost must reflect the important characteristics of the
> > physical systems that they represent. Therefore, until the behaviors
> > exist widely within an organization, which behaviors enable an
> > improved level of performance for the primary system, no one has any
> > business building a plan that assumes behaviors other than the
> rotten
> > behaviors that prevail at the time that the plan is in use.
> >
> > Tony Rizzo
> > tony.rizzo@...
> > +1 908 264 8520 desk
> > +1 908 230 5348 mobile
>
>
>



[Non-text portions of this message have been removed]

I know of three types of knowledge-work processes:

1) Transformational - a process of this type works directly and only
upon its inputs of semantic information, to transform the inputs into
outputs.  Example: the ideas that one document may express in, say,
Japanese are expressed in English.

2) Combinatorial - a process of this type combines its inputs of
semantic information with additional semantic information that may be
contained already within the process.  Example: an author of a
technical document combines several ideas from other authors with some
of her own and presents the combination as her conclusion.

3) Discovery - a process of this type uses its inputs of semantic
information as keys, with which to discover additional information.
Example: information about external loads, boundary-conditions,
material, and geometry enables calculations that reveal if a component
is likely to fail while in use.

Does anyone know of additional knowledge-work processes that are not
combinations of these three types?  If so, can you point me to
references?

Tony Rizzo
tony.rizzo@...
+1 908 264 8520 desk
+1 908 230 5348 mobile









[Non-text portions of this message have been removed]

Tony,

Some kinds of software development would seem to be a combination of #2 and #3.

That is, in software, we often take ideas of our own, and combine them with the
ideas of others, and yet we are also often on a "journey of discovery," where
certain requirements are discovered in the process of doing the work.

Thoughts?

Thanks,

John




________________________________
From: Anthony Rizzo <Tony.Rizzo@...>
To: criticalchain@yahoogroups.com
Sent: Tuesday, May 5, 2009 11:20:51 AM
Subject: [CriticalChain] I know of three types.  Do you know of others?





I know of three types of knowledge-work processes:

1) Transformational - a process of this type works directly and only
upon its inputs of semantic information, to transform the inputs into
outputs.  Example: the ideas that one document may express in, say,
Japanese are expressed in English.

2) Combinatorial - a process of this type combines its inputs of
semantic information with additional semantic information that may be
contained already within the process.  Example: an author of a
technical document combines several ideas from other authors with some
of her own and presents the combination as her conclusion.

3) Discovery - a process of this type uses its inputs of semantic
information as keys, with which to discover additional information.
Example: information about external loads, boundary-conditions ,
material, and geometry enables calculations that reveal if a component
is likely to fail while in use.

Does anyone know of additional knowledge-work processes that are not
combinations of these three types?  If so, can you point me to
references?

Tony Rizzo
tony.rizzo@pdinstit ute.com
+1 908 264 8520 desk
+1 908 230 5348 mobile

[Non-text portions of this message have been removed]




[Non-text portions of this message have been removed]

Thanks John.

The development of new products inevitably involves the discovery of
new information and often also mere transformations (recoding).

Tony Rizzo
tony.rizzo@...
+1 908 264 8520 desk
+1 908 230 5348 mobile







On May 5, 2009, at 2:57 PM, John Sambrook wrote:

>
>
> Tony,
>
> Some kinds of software development would seem to be a combination of
> #2 and #3.
>
> That is, in software, we often take ideas of our own, and combine
> them with the ideas of others, and yet we are also often on a
> "journey of discovery," where certain requirements are discovered in
> the process of doing the work.
>
> Thoughts?
>
> Thanks,
>
> John
>
> ________________________________
> From: Anthony Rizzo <Tony.Rizzo@...>
> To: criticalchain@yahoogroups.com
> Sent: Tuesday, May 5, 2009 11:20:51 AM
> Subject: [CriticalChain] I know of three types. Do you know of others?
>
> I know of three types of knowledge-work processes:
>
> 1) Transformational - a process of this type works directly and only
> upon its inputs of semantic information, to transform the inputs into
> outputs. Example: the ideas that one document may express in, say,
> Japanese are expressed in English.
>
> 2) Combinatorial - a process of this type combines its inputs of
> semantic information with additional semantic information that may be
> contained already within the process. Example: an author of a
> technical document combines several ideas from other authors with some
> of her own and presents the combination as her conclusion.
>
> 3) Discovery - a process of this type uses its inputs of semantic
> information as keys, with which to discover additional information.
> Example: information about external loads, boundary-conditions ,
> material, and geometry enables calculations that reveal if a component
> is likely to fail while in use.
>
> Does anyone know of additional knowledge-work processes that are not
> combinations of these three types? If so, can you point me to
> references?
>
> Tony Rizzo
> tony.rizzo@pdinstit ute.com
> +1 908 264 8520 desk
> +1 908 230 5348 mobile
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>



[Non-text portions of this message have been removed]

Hi, Tony

Of course the initial task duration estimates usually entail large variation.
Nonetheless, the schedules  need initial duration estimates to prioritize tasks
and thereby synchronize the flow of work by resource across multiple projects.
Otherwise there is no way for a Task Manager with resources supporting multiple
projects to know which task to assign a resource to next.

I know you agree that tasks do not need specific start and finish dates, because
all such single point dates have a probability of zero. But that is another
matter.

I disagree that there is "no data". Most organizations have past data, even if
only what they are used to using in estimates. Many also have actuals data; on
both work (time cards) and duration (actual schedules). They often do not know
how to use it. Yes, of course it is from a particular way of working, fraught
with date driven behaviors, atc. and therefore often not directly useful.
Sometimes it is surprisingly so, though. I at least always ask.

That is not to say organizations cannot start immediately to improve the flow of
work; i.e. before they create CC schedules. They can by just having the
supervisors lead their resoruces to work on one task at a time, and help them
when they get stuck. That will sometimes lead to working on tasks in the "wrong"
sequence, but that still yields a far better result than multitasking. Senior
management can help by prioritizing projects, and dealing with escalated stuck
tasks. I think this 'behavior first' approach is something we have all learned
over time with implementations.

It is sometimes very difficult to keep organizations from falling into business
as usual until they have all the projects into a scheduling system. I have one
stuck there now, and just cannot seem to move them out of the ditch.

Regards,
Larry Leach




--- In CriticalChain@yahoogroups.com, Anthony Rizzo <Tony.Rizzo@...> wrote:
>
> > As a practical matter, I don't understand how people know what to
> > task to work on without project schedules. For me, that is actually
> > the primary function of the schedules; with the end date being
> > secondary.
>
> The network-diagram, which shows the activities, the assigned
> resources, and the relationships among the activities, certainly must
> exist.  This is how we know which tasks should be active at any point
> of a project.  However, any calculation of duration-to-completion has
> no basis, when an organization's history consists of nothing but
> widespread multitasking.
>
> The hierarchical criteria for a good plan are:
>
>  1) accuracy w.r.t. tangible deliverables (this is the "destination")
>  2) accuracy w.r.t. logistics (this is the itinerary)
>  3) accuracy w.r.t. duration to completion (this criterion can't be
> met initially - no data)
>  4) accuracy w.r.t. variable cost (data for this usually is available
> readily)
>
> A good process for planning at the very least must start with a list
> of tangible deliverables that satisfies item 1 and provides an output
> that satisfies item 2.  However, item 3 requires data.  No such data
> is available to any organization initially, which reflects an
> operation with properly managed resources.  Therefore, no credible
> calculation of duration-to-completion is possible initially.
>
> Tony Rizzo
> tony.rizzo@...
> +1 908 264 8520 desk
> +1 908 230 5348 mobile
>
>
>
>
>
>
>
> On May 5, 2009, at 12:52 PM, Lawrence wrote:
>
> >
> >
> > Hi, Tony
> >
> > I agree fully with your penultimate paragrpah.
> >
> > As a practical matter, I don't understand how people know what to
> > task to work on without project schedules. For me, that is actually
> > the primary function of the schedules; with the end date being
> > secondary.
> >
> > Regards,
> > Larry Leach
> >
> > --- In CriticalChain@yahoogroups.com, Anthony Rizzo <Tony.Rizzo@>
> > wrote:
> > >
> > > Mike writes:
> > >
> > > >: Well, for me it's about building a culture of trust....
> > >
> > >
> > > Hear! Hear!
> > >
> > > The practice of cutting estimates also puts the primary system of a
> > > business on a process of ongoing degradation: The mangers cut. The
> > > resources observe the cuts. The resources adjust the subsequent
> > > estimates accordingly. The managers observes the adjustment of the
> > > subsequent estimates. The managers cut by more. The resources adjust
> > > by more. The managers cut by more. ... and more. ... and more.
> > >
> > > A far superior approach is to inform the senior executive and the
> > > managers that the initial new models of projects are going to be
> > every
> > > bit as wrong as their old models, with respect to duration.
> > > Consequently, the managers should respond with one statement and one
> > > statement alone, to the first new model (plan) from every team:
> > "Thank
> > > you for your help!"
> > >
> > > "Thank you" is the only acceptable response, particularly from the
> > > most senior person, for two reasons: First, with this response the
> > > leadership and the managers afford themselves the opportunity to
> > shape
> > > the behavior not only of the first few teams but also that of every
> > > other team, through the experiences of the first few.
> > >
> > > Second, if the resources of a primary system are managed properly,
> > > logistical performance ceases to be a function of all calculations
> > of
> > > duration, and the plans begin to be perceived and used for what they
> > > really are: Plans are models with which we calculate estimates of
> > > duration to completion, and that's all that they are.
> > >
> > > The jerk-response of blurting out "The plan's too long. It's
> > > unacceptable. Make it shorter," often kills the entire improvement
> > > effort immediately. It squanders the vast amount of additional
> > > performance (logistical and financial) that the effort can bring
> > > within reach. Any action on the part of an executive or a manager,
> > > which jeopardizes all that cash for the sake of creating a few
> > > fictitious pictures of short projects, isn't merely a damned stupid
> > > thing to do. It's an act of criminal negligence. It's also damned
> > > stupid from the perspective of the those executives inclined to
> > > provide such a jerk-response, because all too often it prevents them
> > > from earning additional megabucks in bonuses.
> > >
> > > The massive amounts of wasted money are precisely the reason why the
> > > focus must be, first, last, forever, and to an overwhelming
> > degree, on
> > > creating the mechanism of speed, rather than creating "critical-
> > chain
> > > plans" that look short and pretty.
> > >
> > > I'll say this until I'm ready for my grave: Plans are nothing more
> > > than predictive models of physical systems. All predictive models
> > > first and foremost must reflect the important characteristics of the
> > > physical systems that they represent. Therefore, until the behaviors
> > > exist widely within an organization, which behaviors enable an
> > > improved level of performance for the primary system, no one has any
> > > business building a plan that assumes behaviors other than the
> > rotten
> > > behaviors that prevail at the time that the plan is in use.
> > >
> > > Tony Rizzo
> > > tony.rizzo@
> > > +1 908 264 8520 desk
> > > +1 908 230 5348 mobile
> >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>