Hi Larry,

Here's a starting point:

http://mashable.com/2009/05/28/google-wave-guide/

You can find a lot more, of course, with a little googling.

I'll ask on the SEA-TOC-SIG wave if we can get you an invite.  I'm currently
out, but I'll bet some other folks might have some.

John




________________________________
From: lawrence_leach <lawrence_leach@...>
To: CriticalChain@yahoogroups.com
Sent: Sun, January 31, 2010 7:25:51 PM
Subject: [CriticalChain] Re: Follow the SEA-TOC-SIG on Google Wave ...


Hi, John

What's a wave? I think I may need to ride one...

Larry

--- In CriticalChain@ yahoogroups. com, John Sambrook <john_sambrook@ ...>
wrote:
>
> Done.  Welcome, Tathagat!
>
>
>
> ----- Original Message ----
> From: Tathagat Varma <tathagat.varma@ ...>
> To: CriticalChain@ yahoogroups. com
> Sent: Fri, January 29, 2010 7:20:02 PM
> Subject: Re: [CriticalChain] Follow the SEA-TOC-SIG on Google Wave ...
>
> John, I am on wave. How could I join the SIG wave, or alternately, could you
> add me (tathagat.varma@ ...). Thanks.
>
> regards,
> Tathagat
>
> http://managewell. net
>
>
> On Sat, Jan 30, 2010 at 12:24 AM, John Sambrook <john_sambrook@ ...>wrote:
>
> >
> >
> > Hello,
> >
> > I have a few Google Wave invites left (maybe I'll get more when I use them
> > up, I don't know.) I'm starting a wave associated with the SEA-TOC-SIG
> > meetings I have once a month. We usually have some pretty interesting stuff.
> > Good presentation by Mike Round this morning.
> >
> > At any rate, if you'd like to try Google Wave, ask me for an invite and you
> > can join the SEA-TOC-SIG wave.
> >
> > On a related note, SEA-TOC-SIG is now using GotoMeeting. com as well as
> > Skype. What can I say? I update the technology as I have time.
> >
> > Yours in TOC,
> >
> > John Sambrook
> > Common Sense Systems, Inc.
> >
> > ____________ _________ _________ __
> > From: Clarence Maday <cmaday@... <cmaday%40nc. rr.com>>
> > To: CriticalChain@ yahoogroups. com <CriticalChain% 40yahoogroups. com>
> > Sent: Sun, February 7, 2010 11:27:35 AM
> > Subject: Re: [CriticalChain] Re: 2008 System Dynamics Applications Award
> >
> > ..
> > Hi Larrry,
> >
> > ....a leap....?
> >
> > A very big lea!!! For Fluor sized projects the System Dynamics model
> > contains 1,000's of lines of code. I strongly recommend Sterman's Business
> > Dynamics for insight into the process.
> >
> > Whatever, the message of the paper is the assessment of secondary impacts
> > of change. It's as much as dealing with change as mitigating or preventing
> > change.
> >
> > Cheers,
> >
> > Clare
> >
> > ----- Original Message -----
> > From: lawrence_leach
> > To: CriticalChain@ yahoogroups. com
> > Sent: Tuesday, January 05, 2010 7:07 PM
> > Subject: [CriticalChain] Re: 2008 System Dynamics Applications Award
> >
> > Hi, Clare
> >
> > "a step"?
> >
> > Larry
> >
> > --- In CriticalChain@ yahoogroups. com, "Clarence Maday" <cmaday@>
> > wrote:
> > >
> > > Mario,
> > >
> > > Thanks for the reference. As you know, Forrester got System Dynamics
> > underway at MIT. He is also one of the original inventors of random access
> > memory which enriched MIT by tens of millions, or so I've been told. I
> > reread parts of Industrial Dynamics at times and continue to be in awe at
> > Forrester's insights and contributions. They withstand the test of time.John
> > Sterman now heads up the operation. His Foreword in the paper by Cooper and
> > Lee is spot on. The paper is built around Change Impact Assessment (CIA)
> > used very successfully. BTW, Sterman is interested in our work. He answers
> > emails promptly. As Larry pointed out, this may be the step beyond Critical
> > Chain.
> > >
> > > Cheers,
> > >
> > > Clare
> > > ----- Original Message -----
> > > From: Mario López de Ávila Muñoz
> > > To: CriticalChain@ yahoogroups. com
> > > Sent: Wednesday, December 30, 2009 3:51 AM
> > > Subject: [CriticalChain] 2008 System Dynamics Applications Award
> > >
> > >
> > >
> > > Hello all,
> > >
> > > This is not Critical Chain, so I apologize in advance for the
> > "off-topic",
> > > but it is certainly Project Management at its best.
> > >
> > > Following this link:
> > >
> > > http://bit.ly/7S27bV
> > >
> > > You can find the System Dynamics Society (SDS) award winning paper of
> > 2008,
> > > written by Ken Cooper and Greg Lee.
> > >
> > > They designed, built, test and implemented a model-based system to aid
> > > project management at Fluor Corp.
> > >
> > > The system developed rapidly tailors a model to simulate each engineering
> > > and construction project. Each model is then used to foresee future cost
> > > and schedule impacts of project changes, and most important, test ways to
> > > avoid the impacts. This Change Impact Assesment system has now been used
> > on
> > > over 100 different projects. the cost savings identified for Fluor.
> > amounts
> > > to hundreds of millions of dollars.
> > >
> > > Enjoy it J
> > >
> > > And happy, prosperous, new year 2010.
> > >
> > > Mario
> > >
> > > [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]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------ --------- --------- ------
>
> To unsubscribe from this discussion, send an email to:
> CriticalChain- unsubscribe@ egroups.com
> Any administrative comments or questions should be sent to:
> CriticalChain- owner@egroups. com
> Yahoo! Groups Links
>




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

hi,

On Sun, Jan 31, 2010 at 7:22 PM, lawrence_leach
<lawrence_leach@...> wrote:
> The next Lean project might put in automatic spinklers for the trees; albeit
at much larger investment.

re: the tress + above vs. underground pipe: is that about Lean, or
about ToC? apologies for being dense. would ToC suggest converting
over to underground pipe?

thanks.

I have, for if anyone needs.  If so, email me privately please.

Cordially yours,

On 1 February 2010 09:44, John Sambrook <john_sambrook@...> wrote:

>
>
> Hi Larry,
>
> Here's a starting point:
>
> http://mashable.com/2009/05/28/google-wave-guide/
>
> You can find a lot more, of course, with a little googling.
>
> I'll ask on the SEA-TOC-SIG wave if we can get you an invite. I'm currently
> out, but I'll bet some other folks might have some.
>
> John
>
> ________________________________
> From: lawrence_leach <lawrence_leach@...<lawrence_leach%40hotmail.com>
> >
> To: CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>
> Sent: Sun, January 31, 2010 7:25:51 PM
> Subject: [CriticalChain] Re: Follow the SEA-TOC-SIG on Google Wave ...
>
>
> Hi, John
>
> What's a wave? I think I may need to ride one...
>
> Larry
>
> --- In CriticalChain@ yahoogroups. com, John Sambrook <john_sambrook@ ...>
> wrote:
> >
> > Done. Welcome, Tathagat!
> >
> >
> >
> > ----- Original Message ----
> > From: Tathagat Varma <tathagat.varma@ ...>
> > To: CriticalChain@ yahoogroups. com
> > Sent: Fri, January 29, 2010 7:20:02 PM
> > Subject: Re: [CriticalChain] Follow the SEA-TOC-SIG on Google Wave ...
> >
> > John, I am on wave. How could I join the SIG wave, or alternately, could
> you
> > add me (tathagat.varma@ ...). Thanks.
> >
> > regards,
> > Tathagat
> >
> > http://managewell. net
> >
> >
> > On Sat, Jan 30, 2010 at 12:24 AM, John Sambrook <john_sambrook@...>wrote:
> >
> > >
> > >
> > > Hello,
> > >
> > > I have a few Google Wave invites left (maybe I'll get more when I use
> them
> > > up, I don't know.) I'm starting a wave associated with the SEA-TOC-SIG
> > > meetings I have once a month. We usually have some pretty interesting
> stuff.
> > > Good presentation by Mike Round this morning.
> > >
> > > At any rate, if you'd like to try Google Wave, ask me for an invite and
> you
> > > can join the SEA-TOC-SIG wave.
> > >
> > > On a related note, SEA-TOC-SIG is now using GotoMeeting. com as well as
> > > Skype. What can I say? I update the technology as I have time.
> > >
> > > Yours in TOC,
> > >
> > > John Sambrook
> > > Common Sense Systems, Inc.
> > >
> > > ____________ _________ _________ __
> > > From: Clarence Maday <cmaday@... <cmaday%40nc. rr.com>>
> > > To: CriticalChain@ yahoogroups. com <CriticalChain% 40yahoogroups.
> com>
> > > Sent: Sun, February 7, 2010 11:27:35 AM
> > > Subject: Re: [CriticalChain] Re: 2008 System Dynamics Applications
> Award
> > >
> > > ..
> > > Hi Larrry,
> > >
> > > ....a leap....?
> > >
> > > A very big lea!!! For Fluor sized projects the System Dynamics model
> > > contains 1,000's of lines of code. I strongly recommend Sterman's
> Business
> > > Dynamics for insight into the process.
> > >
> > > Whatever, the message of the paper is the assessment of secondary
> impacts
> > > of change. It's as much as dealing with change as mitigating or
> preventing
> > > change.
> > >
> > > Cheers,
> > >
> > > Clare
> > >
> > > ----- Original Message -----
> > > From: lawrence_leach
> > > To: CriticalChain@ yahoogroups. com
> > > Sent: Tuesday, January 05, 2010 7:07 PM
> > > Subject: [CriticalChain] Re: 2008 System Dynamics Applications Award
> > >
> > > Hi, Clare
> > >
> > > "a step"?
> > >
> > > Larry
> > >
> > > --- In CriticalChain@ yahoogroups. com, "Clarence Maday" <cmaday@>
> > > wrote:
> > > >
> > > > Mario,
> > > >
> > > > Thanks for the reference. As you know, Forrester got System Dynamics
> > > underway at MIT. He is also one of the original inventors of random
> access
> > > memory which enriched MIT by tens of millions, or so I've been told. I
> > > reread parts of Industrial Dynamics at times and continue to be in awe
> at
> > > Forrester's insights and contributions. They withstand the test of
> time.John
> > > Sterman now heads up the operation. His Foreword in the paper by Cooper
> and
> > > Lee is spot on. The paper is built around Change Impact Assessment
> (CIA)
> > > used very successfully. BTW, Sterman is interested in our work. He
> answers
> > > emails promptly. As Larry pointed out, this may be the step beyond
> Critical
> > > Chain.
> > > >
> > > > Cheers,
> > > >
> > > > Clare
> > > > ----- Original Message -----
> > > > From: Mario L�pez de �vila Mu�oz
> > > > To: CriticalChain@ yahoogroups. com
> > > > Sent: Wednesday, December 30, 2009 3:51 AM
> > > > Subject: [CriticalChain] 2008 System Dynamics Applications Award
> > > >
> > > >
> > > >
> > > > Hello all,
> > > >
> > > > This is not Critical Chain, so I apologize in advance for the
> > > "off-topic",
> > > > but it is certainly Project Management at its best.
> > > >
> > > > Following this link:
> > > >
> > > > http://bit.ly/7S27bV
> > > >
> > > > You can find the System Dynamics Society (SDS) award winning paper of
> > > 2008,
> > > > written by Ken Cooper and Greg Lee.
> > > >
> > > > They designed, built, test and implemented a model-based system to
> aid
> > > > project management at Fluor Corp.
> > > >
> > > > The system developed rapidly tailors a model to simulate each
> engineering
> > > > and construction project. Each model is then used to foresee future
> cost
> > > > and schedule impacts of project changes, and most important, test
> ways to
> > > > avoid the impacts. This Change Impact Assesment system has now been
> used
> > > on
> > > > over 100 different projects. the cost savings identified for Fluor.
> > > amounts
> > > > to hundreds of millions of dollars.
> > > >
> > > > Enjoy it J
> > > >
> > > > And happy, prosperous, new year 2010.
> > > >
> > > > Mario
> > > >
> > > > [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]
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------ --------- --------- ------
> >
> > To unsubscribe from this discussion, send an email to:
> > CriticalChain- unsubscribe@ egroups.com
> > Any administrative comments or questions should be sent to:
> > CriticalChain- owner@egroups. com
> > Yahoo! Groups Links
> >
>
> [Non-text portions of this message have been removed]
>
>
>



--
__________________________________
Santiago Vel�squez Mart�nez

"Life is a constant word problem" - Michael Owen


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

Ah, I see the potential conflict now.  Thanks for the rewording.

I think the general rule is still the same:  Release enough work into the
system to ensure the constraint always has something to do BUT not too much.
Just like in DBR there is a balance between too much and too little, and
just like in DBR I think there is a wide zone that constitutes "just right."
In other words, constant tweaking isn't going to help either.

There also has to be a prioritization mechanism at the constraint, so they
know what work to process first if they finish one task and have several
sitting there.  That is the buffer statistics of DBR or CCPM, isn't it?  In
DBR (and more so in S-DBR), the manager of the plant / drum is given the
information about what is expected at the drum and their priorities.  And
then local decisions about which work to process when is left to them to
take into account changeovers and sequencing and other aspects that most DBR
implementations leave out.  Can the same thing work in CCPM to overcome this
concern?

There is still the concern about knowledge work that that human nature
pushes people to do SOMETHING with tasks that are sitting in front of them.
This is a key assumption (fact?) that leads to a potential way to break the
cloud.  If we can establish a mechanism and practice to reduce multitasking
at the local level, will that be sufficient to break the cloud and ensure
there is still a (reasonably sized) queue at the constraint?

Best-

Jack Vinson



-----Original Message-----
From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of lawrence_leach
Sent: Sunday, 31 January 2010 9:50 PM
To: CriticalChain@yahoogroups.com
Subject: [CriticalChain] Re: Discussion Cloud

Hi, Jack

It came up with some DBR people. There, you deliberately keep a queue for
the drum so as to not starve it. You then use the size of the queue to
trigger release of work into the system. Usually that won't work with
projects because there is a substantial time delay between release of a
project and drum work on it. And it can vary for every project.

In CC, the primary way to exploit the drum is to eliminate multitasking. A
queue puts pressure on  the drum to multitask. Queue time also adds directly
to cycle time. Cycle time relates inversely to Throughput through Little's
law.

So it certainly appears to be a conflict to me.

Larry

--- In CriticalChain@yahoogroups.com, "Jack Vinson" <jackvinson@...> wrote:
>
> Same with questions I've had.  It didn't catch anyone's eye / excitement.
>
> I wonder if "queue time" doesn't quite make sense in the Project
> environment?  (The terminology, not the concept.)  Maybe it should be
> work-in-process (WIP) or "active tasks" for the constraint?  In that
light,
> the cloud is that we want to maximize throughput by minimizing cycle time
> AND not starve the drum.  We believe the cycle time is important because
> faster projects = happy customers, faster $$.  We believe that we don't
want
> to starve the drum because "an hour lost on the constraint is lost
forever."
> In order to minimize cycle time, we don't want to release work into the
> system before the system can handle the work.  And in order to not starve
> the drum, we need to release enough work into the system to keep a queue /
> work in front of the drum.
>
> The way I am thinking of "D," I am not sure if there is a conflict.  Sure,
> we could get even faster turnaround time, but at the expense of starving
the
> drum from time to time.  So release work into the system such that the
drum
> is expected to be active on project work all the time.  And then focus on
> "road runner" in all the tasks and monitor the drum.  If it is starved
"too
> often," then there is room for more projects or the constraint has moved.

>
> Yes? No?  Were you thinking along a different line?
>
> Jack
>

Hi Larry,

You said: "A queue puts pressure on the drum to multitask."

Can you expand on the cause-effect logic of this statement? I'm not clear
about it.

David


On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...> wrote:

>
>
> Hi, Jack
>
> It came up with some DBR people. There, you deliberately keep a queue for
> the drum so as to not starve it. You then use the size of the queue to
> trigger release of work into the system. Usually that won't work with
> projects because there is a substantial time delay between release of a
> project and drum work on it. And it can vary for every project.
>
> In CC, the primary way to exploit the drum is to eliminate multitasking. A
> queue puts pressure on the drum to multitask. Queue time also adds directly
> to cycle time. Cycle time relates inversely to Throughput through Little's
> law.
>
> So it certainly appears to be a conflict to me.
>
> Larry
>
>
> --- In CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>,
> "Jack Vinson" <jackvinson@...> wrote:
> >
> > Same with questions I've had. It didn't catch anyone's eye / excitement.
> >
> > I wonder if "queue time" doesn't quite make sense in the Project
> > environment? (The terminology, not the concept.) Maybe it should be
> > work-in-process (WIP) or "active tasks" for the constraint? In that
> light,
> > the cloud is that we want to maximize throughput by minimizing cycle time
> > AND not starve the drum. We believe the cycle time is important because
> > faster projects = happy customers, faster $$. We believe that we don't
> want
> > to starve the drum because "an hour lost on the constraint is lost
> forever."
> > In order to minimize cycle time, we don't want to release work into the
> > system before the system can handle the work. And in order to not starve
> > the drum, we need to release enough work into the system to keep a queue
> /
> > work in front of the drum.
> >
> > The way I am thinking of "D," I am not sure if there is a conflict. Sure,
> > we could get even faster turnaround time, but at the expense of starving
> the
> > drum from time to time. So release work into the system such that the
> drum
> > is expected to be active on project work all the time. And then focus on
> > "road runner" in all the tasks and monitor the drum. If it is starved
> "too
> > often," then there is room for more projects or the constraint has moved.
>
> >
> > Yes? No? Were you thinking along a different line?
> >
> > Jack
> >
>
>
>


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

Someone just asked me a question offline that made me rethink this
discussion.

Is there a large queue of work for the constraint resource, if you are doing
multi-project CCPM and gauging the release of projects based on the capacity
of that constraint?  There is a queue of unreleased projects.  And most CCPM
will use a capacity buffer to add time between projects (increase the cycle
time) in order to ensure variation within projects does not impinge on other
projects.

As I suggested before, the size of this capacity buffer can be debated, but
there is probably plenty of room for wiggle, and whether you have too much
or too little capacity buffer should appear from your project buffer
management statistics.

Jack Vinson

Hi, David

Sure. If people have a visible list of many tasks, they often feel that as
pressure. They feel that they have to show that they are working on something
for each customer.

Larry

--- In CriticalChain@yahoogroups.com, David Peterson <david@...> wrote:
>
> Hi Larry,
>
> You said: "A queue puts pressure on the drum to multitask."
>
> Can you expand on the cause-effect logic of this statement? I'm not clear
> about it.
>
> David
>
>
> On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...> wrote:
>
> >
> >
> > Hi, Jack
> >
> > It came up with some DBR people. There, you deliberately keep a queue for
> > the drum so as to not starve it. You then use the size of the queue to
> > trigger release of work into the system. Usually that won't work with
> > projects because there is a substantial time delay between release of a
> > project and drum work on it. And it can vary for every project.
> >
> > In CC, the primary way to exploit the drum is to eliminate multitasking. A
> > queue puts pressure on the drum to multitask. Queue time also adds directly
> > to cycle time. Cycle time relates inversely to Throughput through Little's
> > law.
> >
> > So it certainly appears to be a conflict to me.
> >
> > Larry
> >
> >
> > --- In CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>,
> > "Jack Vinson" <jackvinson@> wrote:
> > >
> > > Same with questions I've had. It didn't catch anyone's eye / excitement.
> > >
> > > I wonder if "queue time" doesn't quite make sense in the Project
> > > environment? (The terminology, not the concept.) Maybe it should be
> > > work-in-process (WIP) or "active tasks" for the constraint? In that
> > light,
> > > the cloud is that we want to maximize throughput by minimizing cycle time
> > > AND not starve the drum. We believe the cycle time is important because
> > > faster projects = happy customers, faster $$. We believe that we don't
> > want
> > > to starve the drum because "an hour lost on the constraint is lost
> > forever."
> > > In order to minimize cycle time, we don't want to release work into the
> > > system before the system can handle the work. And in order to not starve
> > > the drum, we need to release enough work into the system to keep a queue
> > /
> > > work in front of the drum.
> > >
> > > The way I am thinking of "D," I am not sure if there is a conflict. Sure,
> > > we could get even faster turnaround time, but at the expense of starving
> > the
> > > drum from time to time. So release work into the system such that the
> > drum
> > > is expected to be active on project work all the time. And then focus on
> > > "road runner" in all the tasks and monitor the drum. If it is starved
> > "too
> > > often," then there is room for more projects or the constraint has moved.
> >
> > >
> > > Yes? No? Were you thinking along a different line?
> > >
> > > Jack
> > >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

>:  ...most will use a capacity buffer to add time between

>:  projects (increase the cycle time)



This is false.



Project-duration is measured from start to finish.  By spacing projects on
the timeline, with a capacity-buffer, we do not delay the start of each
project beyond the release-time that corresponds to a JIT arrival at the
bottleneck.  We simply prevent the damagingly early release of each project,
thereby blocking the false perceptions of urgency that force multitasking to
happen.



Using the capacity-buffer does not increase project-duration.  Rather, it
causes the smallest practicable values of project-duration, and, more
importantly, it increases the rate of flow through the primary system,
causing significantly greater productivity without requiring one cent of
additional expense.

Tony Rizzo

+1.908.322.1840 desk
+1.908.930.0411 mobile
  <mailto:tony.rizzo@...> tony.rizzo@...



From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Jack Vinson
Sent: Tuesday, February 02, 2010 5:53 PM
To: CriticalChain@yahoogroups.com
Subject: RE: [CriticalChain] Re: Discussion Cloud





Someone just asked me a question offline that made me rethink this
discussion.

Is there a large queue of work for the constraint resource, if you are doing
multi-project CCPM and gauging the release of projects based on the capacity
of that constraint? There is a queue of unreleased projects. And most CCPM
will use a capacity buffer to add time between projects (increase the cycle
time) in order to ensure variation within projects does not impinge on other
projects.

As I suggested before, the size of this capacity buffer can be debated, but
there is probably plenty of room for wiggle, and whether you have too much
or too little capacity buffer should appear from your project buffer
management statistics.

Jack Vinson





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

I wrote that just before going to sleep.  I should have just gone to sleep.


By the reference to cycle time, I mean the cycle time on the constraint.
You are correct that it will not increase the duration of the projects
overall - it just affects the spacing of the projects.  Increasing the size
of the capacity will increase the time between work on one project and work
on the next.  Decreasing the cycle time too far _can_ have a damaging impact
on projects due to too-early release and potential for variability to
cascade into other projects.

Jack

-----Original Message-----
From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Tony Rizzo
Sent: Tuesday, 02 February 2010 11:54 PM
To: CriticalChain@yahoogroups.com
Subject: RE: [CriticalChain] Re: Discussion Cloud

>:  ...most will use a capacity buffer to add time between

>:  projects (increase the cycle time)



This is false.



Project-duration is measured from start to finish.  By spacing projects on
the timeline, with a capacity-buffer, we do not delay the start of each
project beyond the release-time that corresponds to a JIT arrival at the
bottleneck.  We simply prevent the damagingly early release of each project,
thereby blocking the false perceptions of urgency that force multitasking to
happen.



Using the capacity-buffer does not increase project-duration.  Rather, it
causes the smallest practicable values of project-duration, and, more
importantly, it increases the rate of flow through the primary system,
causing significantly greater productivity without requiring one cent of
additional expense.

Tony Rizzo

+1.908.322.1840 desk
+1.908.930.0411 mobile
  <mailto:tony.rizzo@...> tony.rizzo@...



From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Jack Vinson
Sent: Tuesday, February 02, 2010 5:53 PM
To: CriticalChain@yahoogroups.com
Subject: RE: [CriticalChain] Re: Discussion Cloud





Someone just asked me a question offline that made me rethink this
discussion.

Is there a large queue of work for the constraint resource, if you are doing
multi-project CCPM and gauging the release of projects based on the capacity
of that constraint? There is a queue of unreleased projects. And most CCPM
will use a capacity buffer to add time between projects (increase the cycle
time) in order to ensure variation within projects does not impinge on other
projects.

As I suggested before, the size of this capacity buffer can be debated, but
there is probably plenty of room for wiggle, and whether you have too much
or too little capacity buffer should appear from your project buffer
management statistics.

Jack Vinson





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



------------------------------------

To unsubscribe from this discussion, send an email to:
CriticalChain-unsubscribe@egroups.com
Any administrative comments or questions should be sent to:
CriticalChain-owner@egroups.com
Yahoo! Groups Links

OK, so the assumption is that multi-tasking will give better service to the
customers, which as we know is wrong, wrong, wrong. It seems like a fairly
easy cloud to evaporate...

- Have strict visible WIP limits. E.g. using Kanban tokens.
- Hide the queue. E.g. with a good receptionist, the doctor can focus on one
patient at a time and never see the queue of people in the waiting room.
- Educate the customers.
- Reduce the size of the items to reduce the cycle time.
- Have clear policies about expediting.
- Just ignore the queue. You know you'll get through the queue quicker if
you single-task, so don't worry about it.

Or am I missing something?

David


On 3 February 2010 00:48, lawrence_leach <lawrence_leach@...> wrote:

>
>
> Hi, David
>
> Sure. If people have a visible list of many tasks, they often feel that as
> pressure. They feel that they have to show that they are working on
> something for each customer.
>
> Larry
>
>
> --- In CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>,
> David Peterson <david@...> wrote:
> >
> > Hi Larry,
> >
> > You said: "A queue puts pressure on the drum to multitask."
> >
> > Can you expand on the cause-effect logic of this statement? I'm not clear
> > about it.
> >
> > David
> >
> >
> > On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...> wrote:
> >
> > >
> > >
> > > Hi, Jack
> > >
> > > It came up with some DBR people. There, you deliberately keep a queue
> for
> > > the drum so as to not starve it. You then use the size of the queue to
> > > trigger release of work into the system. Usually that won't work with
> > > projects because there is a substantial time delay between release of a
> > > project and drum work on it. And it can vary for every project.
> > >
> > > In CC, the primary way to exploit the drum is to eliminate
> multitasking. A
> > > queue puts pressure on the drum to multitask. Queue time also adds
> directly
> > > to cycle time. Cycle time relates inversely to Throughput through
> Little's
> > > law.
> > >
> > > So it certainly appears to be a conflict to me.
> > >
> > > Larry
> > >
> > >
> > > --- In CriticalChain@yahoogroups.com
<CriticalChain%40yahoogroups.com><CriticalChain%
> 40yahoogroups.com>,
>
> > > "Jack Vinson" <jackvinson@> wrote:
> > > >
> > > > Same with questions I've had. It didn't catch anyone's eye /
> excitement.
> > > >
> > > > I wonder if "queue time" doesn't quite make sense in the Project
> > > > environment? (The terminology, not the concept.) Maybe it should be
> > > > work-in-process (WIP) or "active tasks" for the constraint? In that
> > > light,
> > > > the cloud is that we want to maximize throughput by minimizing cycle
> time
> > > > AND not starve the drum. We believe the cycle time is important
> because
> > > > faster projects = happy customers, faster $$. We believe that we
> don't
> > > want
> > > > to starve the drum because "an hour lost on the constraint is lost
> > > forever."
> > > > In order to minimize cycle time, we don't want to release work into
> the
> > > > system before the system can handle the work. And in order to not
> starve
> > > > the drum, we need to release enough work into the system to keep a
> queue
> > > /
> > > > work in front of the drum.
> > > >
> > > > The way I am thinking of "D," I am not sure if there is a conflict.
> Sure,
> > > > we could get even faster turnaround time, but at the expense of
> starving
> > > the
> > > > drum from time to time. So release work into the system such that the
> > > drum
> > > > is expected to be active on project work all the time. And then focus
> on
> > > > "road runner" in all the tasks and monitor the drum. If it is starved
> > > "too
> > > > often," then there is room for more projects or the constraint has
> moved.
> > >
> > > >
> > > > Yes? No? Were you thinking along a different line?
> > > >
> > > > Jack
> > > >
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>


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

Good stuff David. I think the thing you may be missing is the power of
the voices of a kazillion customers in the queue shouting or nagging
"me me me" and the others shouting "goodbye" as they leave taking
their money with them.

I know i do a lot of things i consider unimportant just to stop the
nicer-word-than-nagging from my (lovely) wife ...

Clarke Ching


On 3 Feb 2010, at 12:39 PM, David Peterson <david@...> wrote:

> OK, so the assumption is that multi-tasking will give better service
> to the
> customers, which as we know is wrong, wrong, wrong. It seems like a
> fairly
> easy cloud to evaporate...
>
> - Have strict visible WIP limits. E.g. using Kanban tokens.
> - Hide the queue. E.g. with a good receptionist, the doctor can
> focus on one
> patient at a time and never see the queue of people in the waiting
> room.
> - Educate the customers.
> - Reduce the size of the items to reduce the cycle time.
> - Have clear policies about expediting.
> - Just ignore the queue. You know you'll get through the queue
> quicker if
> you single-task, so don't worry about it.
>
> Or am I missing something?
>
> David
>
>
> On 3 February 2010 00:48, lawrence_leach
> <lawrence_leach@...> wrote:
>
>>
>>
>> Hi, David
>>
>> Sure. If people have a visible list of many tasks, they often feel
>> that as
>> pressure. They feel that they have to show that they are working on
>> something for each customer.
>>
>> Larry
>>
>>
>> --- In CriticalChain@yahoogroups.com <CriticalChain
>> %40yahoogroups.com>,
>> David Peterson <david@...> wrote:
>>>
>>> Hi Larry,
>>>
>>> You said: "A queue puts pressure on the drum to multitask."
>>>
>>> Can you expand on the cause-effect logic of this statement? I'm
>>> not clear
>>> about it.
>>>
>>> David
>>>
>>>
>>> On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...> wrote:
>>>
>>>>
>>>>
>>>> Hi, Jack
>>>>
>>>> It came up with some DBR people. There, you deliberately keep a
>>>> queue
>> for
>>>> the drum so as to not starve it. You then use the size of the
>>>> queue to
>>>> trigger release of work into the system. Usually that won't work
>>>> with
>>>> projects because there is a substantial time delay between
>>>> release of a
>>>> project and drum work on it. And it can vary for every project.
>>>>
>>>> In CC, the primary way to exploit the drum is to eliminate
>> multitasking. A
>>>> queue puts pressure on the drum to multitask. Queue time also adds
>> directly
>>>> to cycle time. Cycle time relates inversely to Throughput through
>> Little's
>>>> law.
>>>>
>>>> So it certainly appears to be a conflict to me.
>>>>
>>>> Larry
>>>>
>>>>
>>>> --- In CriticalChain@yahoogroups.com <CriticalChain
>>>> %40yahoogroups.com><CriticalChain%
>> 40yahoogroups.com>,
>>
>>>> "Jack Vinson" <jackvinson@> wrote:
>>>>>
>>>>> Same with questions I've had. It didn't catch anyone's eye /
>> excitement.
>>>>>
>>>>> I wonder if "queue time" doesn't quite make sense in the Project
>>>>> environment? (The terminology, not the concept.) Maybe it should
>>>>> be
>>>>> work-in-process (WIP) or "active tasks" for the constraint? In
>>>>> that
>>>> light,
>>>>> the cloud is that we want to maximize throughput by minimizing
>>>>> cycle
>> time
>>>>> AND not starve the drum. We believe the cycle time is important
>> because
>>>>> faster projects = happy customers, faster $$. We believe that we
>> don't
>>>> want
>>>>> to starve the drum because "an hour lost on the constraint is lost
>>>> forever."
>>>>> In order to minimize cycle time, we don't want to release work
>>>>> into
>> the
>>>>> system before the system can handle the work. And in order to not
>> starve
>>>>> the drum, we need to release enough work into the system to keep a
>> queue
>>>> /
>>>>> work in front of the drum.
>>>>>
>>>>> The way I am thinking of "D," I am not sure if there is a
>>>>> conflict.
>> Sure,
>>>>> we could get even faster turnaround time, but at the expense of
>> starving
>>>> the
>>>>> drum from time to time. So release work into the system such
>>>>> that the
>>>> drum
>>>>> is expected to be active on project work all the time. And then
>>>>> focus
>> on
>>>>> "road runner" in all the tasks and monitor the drum. If it is
>>>>> starved
>>>> "too
>>>>> often," then there is room for more projects or the constraint has
>> moved.
>>>>
>>>>>
>>>>> Yes? No? Were you thinking along a different line?
>>>>>
>>>>> Jack
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To unsubscribe from this discussion, send an email to:
> CriticalChain-unsubscribe@egroups.com
> Any administrative comments or questions should be sent to:
> CriticalChain-owner@egroups.com
> Yahoo! Groups Links
>
>
>

Does it actually stop the nicer-word-than-nagging? Or is it like removing a
bottleneck - there's always another one. I have suspicions that wives
secretly love "reminding" their husbands and if husbands kept dropping what
they were doing to attend to their wives every need, it would take all the
fun out of it. And, maybe not in Scotland, but in England, queuing and
moaning are our nation's favourite pastimes. A long queue wouldn't put us
off. We'd just see it as a wonderful opportunity to huff and puff. :)

David



On 3 February 2010 13:26, Clarke Ching <clarke.ching@...> wrote:

>
>
> Good stuff David. I think the thing you may be missing is the power of
> the voices of a kazillion customers in the queue shouting or nagging
> "me me me" and the others shouting "goodbye" as they leave taking
> their money with them.
>
> I know i do a lot of things i consider unimportant just to stop the
> nicer-word-than-nagging from my (lovely) wife ...
>
> Clarke Ching
>
>
> On 3 Feb 2010, at 12:39 PM, David Peterson
<david@...<david%40crowdsoft.com>>
> wrote:
>
> > OK, so the assumption is that multi-tasking will give better service
> > to the
> > customers, which as we know is wrong, wrong, wrong. It seems like a
> > fairly
> > easy cloud to evaporate...
> >
> > - Have strict visible WIP limits. E.g. using Kanban tokens.
> > - Hide the queue. E.g. with a good receptionist, the doctor can
> > focus on one
> > patient at a time and never see the queue of people in the waiting
> > room.
> > - Educate the customers.
> > - Reduce the size of the items to reduce the cycle time.
> > - Have clear policies about expediting.
> > - Just ignore the queue. You know you'll get through the queue
> > quicker if
> > you single-task, so don't worry about it.
> >
> > Or am I missing something?
> >
> > David
> >
> >
> > On 3 February 2010 00:48, lawrence_leach
> > <lawrence_leach@... <lawrence_leach%40hotmail.com>> wrote:
> >
> >>
> >>
> >> Hi, David
> >>
> >> Sure. If people have a visible list of many tasks, they often feel
> >> that as
> >> pressure. They feel that they have to show that they are working on
> >> something for each customer.
> >>
> >> Larry
> >>
> >>
> >> --- In CriticalChain@yahoogroups.com
<CriticalChain%40yahoogroups.com><CriticalChain
> >> %40yahoogroups.com>,
>
> >> David Peterson <david@...> wrote:
> >>>
> >>> Hi Larry,
> >>>
> >>> You said: "A queue puts pressure on the drum to multitask."
> >>>
> >>> Can you expand on the cause-effect logic of this statement? I'm
> >>> not clear
> >>> about it.
> >>>
> >>> David
> >>>
> >>>
> >>> On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...> wrote:
> >>>
> >>>>
> >>>>
> >>>> Hi, Jack
> >>>>
> >>>> It came up with some DBR people. There, you deliberately keep a
> >>>> queue
> >> for
> >>>> the drum so as to not starve it. You then use the size of the
> >>>> queue to
> >>>> trigger release of work into the system. Usually that won't work
> >>>> with
> >>>> projects because there is a substantial time delay between
> >>>> release of a
> >>>> project and drum work on it. And it can vary for every project.
> >>>>
> >>>> In CC, the primary way to exploit the drum is to eliminate
> >> multitasking. A
> >>>> queue puts pressure on the drum to multitask. Queue time also adds
> >> directly
> >>>> to cycle time. Cycle time relates inversely to Throughput through
> >> Little's
> >>>> law.
> >>>>
> >>>> So it certainly appears to be a conflict to me.
> >>>>
> >>>> Larry
> >>>>
> >>>>
> >>>> --- In
CriticalChain@yahoogroups.com<CriticalChain%40yahoogroups.com><CriticalChain
> >>>> %40yahoogroups.com><CriticalChain%
>
> >> 40yahoogroups.com>,
> >>
> >>>> "Jack Vinson" <jackvinson@> wrote:
> >>>>>
> >>>>> Same with questions I've had. It didn't catch anyone's eye /
> >> excitement.
> >>>>>
> >>>>> I wonder if "queue time" doesn't quite make sense in the Project
> >>>>> environment? (The terminology, not the concept.) Maybe it should
> >>>>> be
> >>>>> work-in-process (WIP) or "active tasks" for the constraint? In
> >>>>> that
> >>>> light,
> >>>>> the cloud is that we want to maximize throughput by minimizing
> >>>>> cycle
> >> time
> >>>>> AND not starve the drum. We believe the cycle time is important
> >> because
> >>>>> faster projects = happy customers, faster $$. We believe that we
> >> don't
> >>>> want
> >>>>> to starve the drum because "an hour lost on the constraint is lost
> >>>> forever."
> >>>>> In order to minimize cycle time, we don't want to release work
> >>>>> into
> >> the
> >>>>> system before the system can handle the work. And in order to not
> >> starve
> >>>>> the drum, we need to release enough work into the system to keep a
> >> queue
> >>>> /
> >>>>> work in front of the drum.
> >>>>>
> >>>>> The way I am thinking of "D," I am not sure if there is a
> >>>>> conflict.
> >> Sure,
> >>>>> we could get even faster turnaround time, but at the expense of
> >> starving
> >>>> the
> >>>>> drum from time to time. So release work into the system such
> >>>>> that the
> >>>> drum
> >>>>> is expected to be active on project work all the time. And then
> >>>>> focus
> >> on
> >>>>> "road runner" in all the tasks and monitor the drum. If it is
> >>>>> starved
> >>>> "too
> >>>>> often," then there is room for more projects or the constraint has
> >> moved.
> >>>>
> >>>>>
> >>>>> Yes? No? Were you thinking along a different line?
> >>>>>
> >>>>> Jack
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> [Non-text portions of this message have been removed]
> >>>
> >>
> >>
> >>
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
>
> >
> > To unsubscribe from this discussion, send an email to:
> >
CriticalChain-unsubscribe@egroups.com<CriticalChain-unsubscribe%40egroups.com>
> > Any administrative comments or questions should be sent to:
> > CriticalChain-owner@egroups.com <CriticalChain-owner%40egroups.com>
> > Yahoo! Groups Links
> >
> >
> >
>
>
>


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

Here in Scotland they're less obsessed with queues and more obsessed
with moaning about you English folk and what your kings did centuries
ago. I generlise ...

One thing about queues which I think we sometimes forget: queues
indicate scarcity and popularity. According to limited understanding
of marketing both scarcity and popularity are very powerful
influencing tools. I'm think of nightclubs which gave a queue soooooo
people join it (contrasted with one with no queue which no one wants
to go into). I'm thinking of the skin cream which sold out here in the
uk last year and suddenly became very popular because it was scarce.
I'm thinking of Ryan air which charges extra to jump the boarding
queues.  I'm thinking of farm economics where price elasticity means
they cn earn more money by reducing supply - even if it means not
selling everything they sell.

Perhaps external queues mean we hve something people want to buy?

I wonder how else we could exploit queues to charge more or otherwise
mke more money. Any thoughts?

Clarke Ching


On 3 Feb 2010, at 02:18 PM, David Peterson <david@...> wrote:

> Does it actually stop the nicer-word-than-nagging? Or is it like
> removing a
> bottleneck - there's always another one. I have suspicions that wives
> secretly love "reminding" their husbands and if husbands kept
> dropping what
> they were doing to attend to their wives every need, it would take
> all the
> fun out of it. And, maybe not in Scotland, but in England, queuing and
> moaning are our nation's favourite pastimes. A long queue wouldn't
> put us
> off. We'd just see it as a wonderful opportunity to huff and puff. :)
>
> David
>
>
>
> On 3 February 2010 13:26, Clarke Ching <clarke.ching@...> wrote:
>
>>
>>
>> Good stuff David. I think the thing you may be missing is the power
>> of
>> the voices of a kazillion customers in the queue shouting or nagging
>> "me me me" and the others shouting "goodbye" as they leave taking
>> their money with them.
>>
>> I know i do a lot of things i consider unimportant just to stop the
>> nicer-word-than-nagging from my (lovely) wife ...
>>
>> Clarke Ching
>>
>>
>> On 3 Feb 2010, at 12:39 PM, David Peterson
>> <david@...<david%40crowdsoft.com>>
>> wrote:
>>
>>> OK, so the assumption is that multi-tasking will give better service
>>> to the
>>> customers, which as we know is wrong, wrong, wrong. It seems like a
>>> fairly
>>> easy cloud to evaporate...
>>>
>>> - Have strict visible WIP limits. E.g. using Kanban tokens.
>>> - Hide the queue. E.g. with a good receptionist, the doctor can
>>> focus on one
>>> patient at a time and never see the queue of people in the waiting
>>> room.
>>> - Educate the customers.
>>> - Reduce the size of the items to reduce the cycle time.
>>> - Have clear policies about expediting.
>>> - Just ignore the queue. You know you'll get through the queue
>>> quicker if
>>> you single-task, so don't worry about it.
>>>
>>> Or am I missing something?
>>>
>>> David
>>>
>>>
>>> On 3 February 2010 00:48, lawrence_leach
>>> <lawrence_leach@... <lawrence_leach%40hotmail.com>> wrote:
>>>
>>>>
>>>>
>>>> Hi, David
>>>>
>>>> Sure. If people have a visible list of many tasks, they often feel
>>>> that as
>>>> pressure. They feel that they have to show that they are working on
>>>> something for each customer.
>>>>
>>>> Larry
>>>>
>>>>
>>>> --- In CriticalChain@yahoogroups.com <CriticalChain
>>>> %40yahoogroups.com><CriticalChain
>>>> %40yahoogroups.com>,
>>
>>>> David Peterson <david@...> wrote:
>>>>>
>>>>> Hi Larry,
>>>>>
>>>>> You said: "A queue puts pressure on the drum to multitask."
>>>>>
>>>>> Can you expand on the cause-effect logic of this statement? I'm
>>>>> not clear
>>>>> about it.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Hi, Jack
>>>>>>
>>>>>> It came up with some DBR people. There, you deliberately keep a
>>>>>> queue
>>>> for
>>>>>> the drum so as to not starve it. You then use the size of the
>>>>>> queue to
>>>>>> trigger release of work into the system. Usually that won't work
>>>>>> with
>>>>>> projects because there is a substantial time delay between
>>>>>> release of a
>>>>>> project and drum work on it. And it can vary for every project.
>>>>>>
>>>>>> In CC, the primary way to exploit the drum is to eliminate
>>>> multitasking. A
>>>>>> queue puts pressure on the drum to multitask. Queue time also
>>>>>> adds
>>>> directly
>>>>>> to cycle time. Cycle time relates inversely to Throughput through
>>>> Little's
>>>>>> law.
>>>>>>
>>>>>> So it certainly appears to be a conflict to me.
>>>>>>
>>>>>> Larry
>>>>>>
>>>>>>
>>>>>> --- In CriticalChain@yahoogroups.com<CriticalChain
>>>>>> %40yahoogroups.com><CriticalChain
>>>>>> %40yahoogroups.com><CriticalChain%
>>
>>>> 40yahoogroups.com>,
>>>>
>>>>>> "Jack Vinson" <jackvinson@> wrote:
>>>>>>>
>>>>>>> Same with questions I've had. It didn't catch anyone's eye /
>>>> excitement.
>>>>>>>
>>>>>>> I wonder if "queue time" doesn't quite make sense in the Project
>>>>>>> environment? (The terminology, not the concept.) Maybe it should
>>>>>>> be
>>>>>>> work-in-process (WIP) or "active tasks" for the constraint? In
>>>>>>> that
>>>>>> light,
>>>>>>> the cloud is that we want to maximize throughput by minimizing
>>>>>>> cycle
>>>> time
>>>>>>> AND not starve the drum. We believe the cycle time is important
>>>> because
>>>>>>> faster projects = happy customers, faster $$. We believe that we
>>>> don't
>>>>>> want
>>>>>>> to starve the drum because "an hour lost on the constraint is
>>>>>>> lost
>>>>>> forever."
>>>>>>> In order to minimize cycle time, we don't want to release work
>>>>>>> into
>>>> the
>>>>>>> system before the system can handle the work. And in order to
>>>>>>> not
>>>> starve
>>>>>>> the drum, we need to release enough work into the system to
>>>>>>> keep a
>>>> queue
>>>>>> /
>>>>>>> work in front of the drum.
>>>>>>>
>>>>>>> The way I am thinking of "D," I am not sure if there is a
>>>>>>> conflict.
>>>> Sure,
>>>>>>> we could get even faster turnaround time, but at the expense of
>>>> starving
>>>>>> the
>>>>>>> drum from time to time. So release work into the system such
>>>>>>> that the
>>>>>> drum
>>>>>>> is expected to be active on project work all the time. And then
>>>>>>> focus
>>>> on
>>>>>>> "road runner" in all the tasks and monitor the drum. If it is
>>>>>>> starved
>>>>>> "too
>>>>>>> often," then there is room for more projects or the constraint
>>>>>>> has
>>>> moved.
>>>>>>
>>>>>>>
>>>>>>> Yes? No? Were you thinking along a different line?
>>>>>>>
>>>>>>> Jack
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> [Non-text portions of this message have been removed]
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>>
>>>
>>> ------------------------------------
>>
>>>
>>> To unsubscribe from this discussion, send an email to:
>>> CriticalChain-unsubscribe@egroups.com<CriticalChain-unsubscribe
>>> %40egroups.com>
>>> Any administrative comments or questions should be sent to:
>>> CriticalChain-owner@egroups.com <CriticalChain-owner%40egroups.com>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To unsubscribe from this discussion, send an email to:
> CriticalChain-unsubscribe@egroups.com
> Any administrative comments or questions should be sent to:
> CriticalChain-owner@egroups.com
> Yahoo! Groups Links
>
>
>

I love paying to jump the queue with Ryanair. I think they could segment
their market further by allowing people to bid for their place in the queue.
I guess that would be too complicated to manage at the gates.

The queues I hate are the ones where you think you're nearing the front only
to find that you've been queuing to get into the real queue inside. The
Eiffel tower did that to me. If I'd have known how far back I was, I
wouldn't have bothered. But once I'd got that far I decided to carry on. So
maybe there are some tactics for concealing the queue from customers -
especially if it's a single transaction rather than a relationship.

The queues I like are the ones where they give you a pager and you can go
and have a cup of coffee and they buzz you when it's your turn. Or failing
that, a take-a-number system where you know it's fair and can quickly gauge
how long you're going to be waiting.

Corey Ladas talks about software teams striking a different bargain with the
business<http://leansoftwareengineering.com/2007/09/10/striking-a-different-barg\
ain-with-the-business/>
-
instead of developing many features simultaneously, the teams develop one
feature at a time and until work begins on a feature, the business are free
to change their minds about which feature comes next. By limiting WIP, the
lead times become consistent enough that the development team can almost
guarantee a level of service - e.g. if the business submit a feature this
week, the feature will be delivered to them within 30 days. There's only one
queue and the business have to collaborate and decide together what goes in
it and specifically what gets selected next.

David


On 3 February 2010 14:52, Clarke Ching <clarke.ching@...> wrote:

>
>
> Here in Scotland they're less obsessed with queues and more obsessed
> with moaning about you English folk and what your kings did centuries
> ago. I generlise ...
>
> One thing about queues which I think we sometimes forget: queues
> indicate scarcity and popularity. According to limited understanding
> of marketing both scarcity and popularity are very powerful
> influencing tools. I'm think of nightclubs which gave a queue soooooo
> people join it (contrasted with one with no queue which no one wants
> to go into). I'm thinking of the skin cream which sold out here in the
> uk last year and suddenly became very popular because it was scarce.
> I'm thinking of Ryan air which charges extra to jump the boarding
> queues. I'm thinking of farm economics where price elasticity means
> they cn earn more money by reducing supply - even if it means not
> selling everything they sell.
>
> Perhaps external queues mean we hve something people want to buy?
>
> I wonder how else we could exploit queues to charge more or otherwise
> mke more money. Any thoughts?
>
> Clarke Ching
>
>
> On 3 Feb 2010, at 02:18 PM, David Peterson
<david@...<david%40crowdsoft.com>>
> wrote:
>
> > Does it actually stop the nicer-word-than-nagging? Or is it like
> > removing a
> > bottleneck - there's always another one. I have suspicions that wives
> > secretly love "reminding" their husbands and if husbands kept
> > dropping what
> > they were doing to attend to their wives every need, it would take
> > all the
> > fun out of it. And, maybe not in Scotland, but in England, queuing and
> > moaning are our nation's favourite pastimes. A long queue wouldn't
> > put us
> > off. We'd just see it as a wonderful opportunity to huff and puff. :)
> >
> > David
> >
> >
> >
> > On 3 February 2010 13:26, Clarke Ching
<clarke.ching@...<clarke.ching%40gmail.com>>
> wrote:
> >
> >>
> >>
> >> Good stuff David. I think the thing you may be missing is the power
> >> of
> >> the voices of a kazillion customers in the queue shouting or nagging
> >> "me me me" and the others shouting "goodbye" as they leave taking
> >> their money with them.
> >>
> >> I know i do a lot of things i consider unimportant just to stop the
> >> nicer-word-than-nagging from my (lovely) wife ...
> >>
> >> Clarke Ching
> >>
> >>
> >> On 3 Feb 2010, at 12:39 PM, David Peterson
> >> <david@... <david%40crowdsoft.com><david%40crowdsoft.com>>
>
> >> wrote:
> >>
> >>> OK, so the assumption is that multi-tasking will give better service
> >>> to the
> >>> customers, which as we know is wrong, wrong, wrong. It seems like a
> >>> fairly
> >>> easy cloud to evaporate...
> >>>
> >>> - Have strict visible WIP limits. E.g. using Kanban tokens.
> >>> - Hide the queue. E.g. with a good receptionist, the doctor can
> >>> focus on one
> >>> patient at a time and never see the queue of people in the waiting
> >>> room.
> >>> - Educate the customers.
> >>> - Reduce the size of the items to reduce the cycle time.
> >>> - Have clear policies about expediting.
> >>> - Just ignore the queue. You know you'll get through the queue
> >>> quicker if
> >>> you single-task, so don't worry about it.
> >>>
> >>> Or am I missing something?
> >>>
> >>> David
> >>>
> >>>
> >>> On 3 February 2010 00:48, lawrence_leach
> >>> <lawrence_leach@... <lawrence_leach%40hotmail.com><lawrence_leach%
> 40hotmail.com>> wrote:
> >>>
> >>>>
> >>>>
> >>>> Hi, David
> >>>>
> >>>> Sure. If people have a visible list of many tasks, they often feel
> >>>> that as
> >>>> pressure. They feel that they have to show that they are working on
> >>>> something for each customer.
> >>>>
> >>>> Larry
> >>>>
> >>>>
> >>>> --- In
CriticalChain@yahoogroups.com<CriticalChain%40yahoogroups.com><CriticalChain
> >>>> %40yahoogroups.com><CriticalChain
>
> >>>> %40yahoogroups.com>,
> >>
> >>>> David Peterson <david@...> wrote:
> >>>>>
> >>>>> Hi Larry,
> >>>>>
> >>>>> You said: "A queue puts pressure on the drum to multitask."
> >>>>>
> >>>>> Can you expand on the cause-effect logic of this statement? I'm
> >>>>> not clear
> >>>>> about it.
> >>>>>
> >>>>> David
> >>>>>
> >>>>>
> >>>>> On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi, Jack
> >>>>>>
> >>>>>> It came up with some DBR people. There, you deliberately keep a
> >>>>>> queue
> >>>> for
> >>>>>> the drum so as to not starve it. You then use the size of the
> >>>>>> queue to
> >>>>>> trigger release of work into the system. Usually that won't work
> >>>>>> with
> >>>>>> projects because there is a substantial time delay between
> >>>>>> release of a
> >>>>>> project and drum work on it. And it can vary for every project.
> >>>>>>
> >>>>>> In CC, the primary way to exploit the drum is to eliminate
> >>>> multitasking. A
> >>>>>> queue puts pressure on the drum to multitask. Queue time also
> >>>>>> adds
> >>>> directly
> >>>>>> to cycle time. Cycle time relates inversely to Throughput through
> >>>> Little's
> >>>>>> law.
> >>>>>>
> >>>>>> So it certainly appears to be a conflict to me.
> >>>>>>
> >>>>>> Larry
> >>>>>>
> >>>>>>
> >>>>>> --- In CriticalChain@yahoogroups.com<CriticalChain%40yahoogroups.com>
> <CriticalChain
> >>>>>> %40yahoogroups.com><CriticalChain
> >>>>>> %40yahoogroups.com><CriticalChain%
> >>
> >>>> 40yahoogroups.com>,
> >>>>
> >>>>>> "Jack Vinson" <jackvinson@> wrote:
> >>>>>>>
> >>>>>>> Same with questions I've had. It didn't catch anyone's eye /
> >>>> excitement.
> >>>>>>>
> >>>>>>> I wonder if "queue time" doesn't quite make sense in the Project
> >>>>>>> environment? (The terminology, not the concept.) Maybe it should
> >>>>>>> be
> >>>>>>> work-in-process (WIP) or "active tasks" for the constraint? In
> >>>>>>> that
> >>>>>> light,
> >>>>>>> the cloud is that we want to maximize throughput by minimizing
> >>>>>>> cycle
> >>>> time
> >>>>>>> AND not starve the drum. We believe the cycle time is important
> >>>> because
> >>>>>>> faster projects = happy customers, faster $$. We believe that we
> >>>> don't
> >>>>>> want
> >>>>>>> to starve the drum because "an hour lost on the constraint is
> >>>>>>> lost
> >>>>>> forever."
> >>>>>>> In order to minimize cycle time, we don't want to release work
> >>>>>>> into
> >>>> the
> >>>>>>> system before the system can handle the work. And in order to
> >>>>>>> not
> >>>> starve
> >>>>>>> the drum, we need to release enough work into the system to
> >>>>>>> keep a
> >>>> queue
> >>>>>> /
> >>>>>>> work in front of the drum.
> >>>>>>>
> >>>>>>> The way I am thinking of "D," I am not sure if there is a
> >>>>>>> conflict.
> >>>> Sure,
> >>>>>>> we could get even faster turnaround time, but at the expense of
> >>>> starving
> >>>>>> the
> >>>>>>> drum from time to time. So release work into the system such
> >>>>>>> that the
> >>>>>> drum
> >>>>>>> is expected to be active on project work all the time. And then
> >>>>>>> focus
> >>>> on
> >>>>>>> "road runner" in all the tasks and monitor the drum. If it is
> >>>>>>> starved
> >>>>>> "too
> >>>>>>> often," then there is room for more projects or the constraint
> >>>>>>> has
> >>>> moved.
> >>>>>>
> >>>>>>>
> >>>>>>> Yes? No? Were you thinking along a different line?
> >>>>>>>
> >>>>>>> Jack
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> [Non-text portions of this message have been removed]
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> [Non-text portions of this message have been removed]
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>
> >>>
> >>> To unsubscribe from this discussion, send an email to:
> >>>
CriticalChain-unsubscribe@egroups.com<CriticalChain-unsubscribe%40egroups.com>
> <CriticalChain-unsubscribe
> >>> %40egroups.com>
>
> >>> Any administrative comments or questions should be sent to:
> >>> CriticalChain-owner@egroups.com
<CriticalChain-owner%40egroups.com><CriticalChain-owner%
> 40egroups.com>
> >>> Yahoo! Groups Links
>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > To unsubscribe from this discussion, send an email to:
> >
CriticalChain-unsubscribe@egroups.com<CriticalChain-unsubscribe%40egroups.com>
> > Any administrative comments or questions should be sent to:
> > CriticalChain-owner@egroups.com <CriticalChain-owner%40egroups.com>
> > Yahoo! Groups Links
> >
> >
> >
>
>
>


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

Hi David

Here is something that might be missing:

http://www.ted.com/talks/sendhil_mullainathan.html

I think one of the biggest disservices Eli G has done to the TOC world is to
pose his "layers of resistance" model. It is sad to see how many uncritically
accept his untested, and I believe incorrect, hypothesis. We have plenty of
research confirming that people do not behave according to such "logic". We can
use that knowledge to help them behave in ways that are better for themselves,
and in the video, their children.

We need to think for ourselves, and apply the scientific method to such
problems.

What you are missing is one of Deming's four points of Profound Knowledge:
Psychology. You can use it and the scientific method (Another of Deming's SoPK:
theory of knowledge) to test each of the solutions you hypothesize, and to
invent others, to get the desired result.

Regards,
Larry Leach




--- In CriticalChain@yahoogroups.com, David Peterson <david@...> wrote:
>
> OK, so the assumption is that multi-tasking will give better service to the
> customers, which as we know is wrong, wrong, wrong. It seems like a fairly
> easy cloud to evaporate...
>
> - Have strict visible WIP limits. E.g. using Kanban tokens.
> - Hide the queue. E.g. with a good receptionist, the doctor can focus on one
> patient at a time and never see the queue of people in the waiting room.
> - Educate the customers.
> - Reduce the size of the items to reduce the cycle time.
> - Have clear policies about expediting.
> - Just ignore the queue. You know you'll get through the queue quicker if
> you single-task, so don't worry about it.
>
> Or am I missing something?
>
> David
>
>
> On 3 February 2010 00:48, lawrence_leach <lawrence_leach@...> wrote:
>
> >
> >
> > Hi, David
> >
> > Sure. If people have a visible list of many tasks, they often feel that as
> > pressure. They feel that they have to show that they are working on
> > something for each customer.
> >
> > Larry
> >
> >
> > --- In CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>,
> > David Peterson <david@> wrote:
> > >
> > > Hi Larry,
> > >
> > > You said: "A queue puts pressure on the drum to multitask."
> > >
> > > Can you expand on the cause-effect logic of this statement? I'm not clear
> > > about it.
> > >
> > > David
> > >
> > >
> > > On 1 February 2010 02:49, lawrence_leach <lawrence_leach@> wrote:
> > >
> > > >
> > > >
> > > > Hi, Jack
> > > >
> > > > It came up with some DBR people. There, you deliberately keep a queue
> > for
> > > > the drum so as to not starve it. You then use the size of the queue to
> > > > trigger release of work into the system. Usually that won't work with
> > > > projects because there is a substantial time delay between release of a
> > > > project and drum work on it. And it can vary for every project.
> > > >
> > > > In CC, the primary way to exploit the drum is to eliminate
> > multitasking. A
> > > > queue puts pressure on the drum to multitask. Queue time also adds
> > directly
> > > > to cycle time. Cycle time relates inversely to Throughput through
> > Little's
> > > > law.
> > > >
> > > > So it certainly appears to be a conflict to me.
> > > >
> > > > Larry
> > > >
> > > >
> > > > --- In CriticalChain@yahoogroups.com
<CriticalChain%40yahoogroups.com><CriticalChain%
> > 40yahoogroups.com>,
> >
> > > > "Jack Vinson" <jackvinson@> wrote:
> > > > >
> > > > > Same with questions I've had. It didn't catch anyone's eye /
> > excitement.
> > > > >
> > > > > I wonder if "queue time" doesn't quite make sense in the Project
> > > > > environment? (The terminology, not the concept.) Maybe it should be
> > > > > work-in-process (WIP) or "active tasks" for the constraint? In that
> > > > light,
> > > > > the cloud is that we want to maximize throughput by minimizing cycle
> > time
> > > > > AND not starve the drum. We believe the cycle time is important
> > because
> > > > > faster projects = happy customers, faster $$. We believe that we
> > don't
> > > > want
> > > > > to starve the drum because "an hour lost on the constraint is lost
> > > > forever."
> > > > > In order to minimize cycle time, we don't want to release work into
> > the
> > > > > system before the system can handle the work. And in order to not
> > starve
> > > > > the drum, we need to release enough work into the system to keep a
> > queue
> > > > /
> > > > > work in front of the drum.
> > > > >
> > > > > The way I am thinking of "D," I am not sure if there is a conflict.
> > Sure,
> > > > > we could get even faster turnaround time, but at the expense of
> > starving
> > > > the
> > > > > drum from time to time. So release work into the system such that the
> > > > drum
> > > > > is expected to be active on project work all the time. And then focus
> > on
> > > > > "road runner" in all the tasks and monitor the drum. If it is starved
> > > > "too
> > > > > often," then there is room for more projects or the constraint has
> > moved.
> > > >
> > > > >
> > > > > Yes? No? Were you thinking along a different line?
> > > > >
> > > > > Jack
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

Hi, Raoul

Oh, the pipe to the hydrants is underground.

Larry


--- In CriticalChain@yahoogroups.com, Raoul Duke <raould@...> wrote:
>
> hi,
>
> On Sun, Jan 31, 2010 at 7:22 PM, lawrence_leach
> <lawrence_leach@...> wrote:
> > The next Lean project might put in automatic spinklers for the trees; albeit
at much larger investment.
>
> re: the tress + above vs. underground pipe: is that about Lean, or
> about ToC? apologies for being dense. would ToC suggest converting
> over to underground pipe?
>
> thanks.
>

Hi, Raoul

The Goal is live trees. The humans are the constraint to the system. They just
aren't very reliable. (Six sigma problem?) Sometimes they go on vacation, etc.
We exploit them by reducing the time they have to spend; i.e. putting in the
hydrants. But then we need move on to elevate; in this case replace them
(mostly) by the automatic sprinklers.

The humans are still a necessary condition, of course. They need to maintain the
system, and turn it on before they leave on vaction.

Regards,
Larry Leach


--- In CriticalChain@yahoogroups.com, Raoul Duke <raould@...> wrote:
>
> hi,
>
> On Sun, Jan 31, 2010 at 7:22 PM, lawrence_leach
> <lawrence_leach@...> wrote:
> > The next Lean project might put in automatic spinklers for the trees; albeit
at much larger investment.
>
> re: the tress + above vs. underground pipe: is that about Lean, or
> about ToC? apologies for being dense. would ToC suggest converting
> over to underground pipe?
>
> thanks.
>

Hi, Jack

One of the ways that works in multiproject CC is take the queues away from the
workers, and give queue management to the supervisors. In some cases, we assign
a separate queue manager for the "non'project work"; i.e. the work tasks that
are not in the project pipeline. Use skills as the resources for the projects
that are in the Pipeline, linked to a Task Manager that will, in real time,
release only one project task at a time to the performing resources, as they
complete a task. The Task Managers are allowed to take tasks from the
non-project queue only when there are no "red" tasks in the project tasks queue,
if that is your rule, or only when authorized by the non-project queue manager,
if that is your rule.

This works very well when the work is physical; e.g. trades. In some knowledge
work environments, this is a problem as the knowledge workers are too
self-important to allow their supervisor such a role. It takes some psycholocal
work to make it a go in those cases.

Regards,
Larry Leach



--- In CriticalChain@yahoogroups.com, "Jack Vinson" <jackvinson@...> wrote:
>
> Ah, I see the potential conflict now.  Thanks for the rewording.
>
> I think the general rule is still the same:  Release enough work into the
> system to ensure the constraint always has something to do BUT not too much.
> Just like in DBR there is a balance between too much and too little, and
> just like in DBR I think there is a wide zone that constitutes "just right."
> In other words, constant tweaking isn't going to help either.
>
> There also has to be a prioritization mechanism at the constraint, so they
> know what work to process first if they finish one task and have several
> sitting there.  That is the buffer statistics of DBR or CCPM, isn't it?  In
> DBR (and more so in S-DBR), the manager of the plant / drum is given the
> information about what is expected at the drum and their priorities.  And
> then local decisions about which work to process when is left to them to
> take into account changeovers and sequencing and other aspects that most DBR
> implementations leave out.  Can the same thing work in CCPM to overcome this
> concern?
>
> There is still the concern about knowledge work that that human nature
> pushes people to do SOMETHING with tasks that are sitting in front of them.
> This is a key assumption (fact?) that leads to a potential way to break the
> cloud.  If we can establish a mechanism and practice to reduce multitasking
> at the local level, will that be sufficient to break the cloud and ensure
> there is still a (reasonably sized) queue at the constraint?
>
> Best-
>
> Jack Vinson
>
>
>
> -----Original Message-----
> From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
> On Behalf Of lawrence_leach
> Sent: Sunday, 31 January 2010 9:50 PM
> To: CriticalChain@yahoogroups.com
> Subject: [CriticalChain] Re: Discussion Cloud
>
> Hi, Jack
>
> It came up with some DBR people. There, you deliberately keep a queue for
> the drum so as to not starve it. You then use the size of the queue to
> trigger release of work into the system. Usually that won't work with
> projects because there is a substantial time delay between release of a
> project and drum work on it. And it can vary for every project.
>
> In CC, the primary way to exploit the drum is to eliminate multitasking. A
> queue puts pressure on  the drum to multitask. Queue time also adds directly
> to cycle time. Cycle time relates inversely to Throughput through Little's
> law.
>
> So it certainly appears to be a conflict to me.
>
> Larry
>
> --- In CriticalChain@yahoogroups.com, "Jack Vinson" <jackvinson@> wrote:
> >
> > Same with questions I've had.  It didn't catch anyone's eye / excitement.
> >
> > I wonder if "queue time" doesn't quite make sense in the Project
> > environment?  (The terminology, not the concept.)  Maybe it should be
> > work-in-process (WIP) or "active tasks" for the constraint?  In that
> light,
> > the cloud is that we want to maximize throughput by minimizing cycle time
> > AND not starve the drum.  We believe the cycle time is important because
> > faster projects = happy customers, faster $$.  We believe that we don't
> want
> > to starve the drum because "an hour lost on the constraint is lost
> forever."
> > In order to minimize cycle time, we don't want to release work into the
> > system before the system can handle the work.  And in order to not starve
> > the drum, we need to release enough work into the system to keep a queue /
> > work in front of the drum.
> >
> > The way I am thinking of "D," I am not sure if there is a conflict.  Sure,
> > we could get even faster turnaround time, but at the expense of starving
> the
> > drum from time to time.  So release work into the system such that the
> drum
> > is expected to be active on project work all the time.  And then focus on
> > "road runner" in all the tasks and monitor the drum.  If it is starved
> "too
> > often," then there is room for more projects or the constraint has moved.
>
> >
> > Yes? No?  Were you thinking along a different line?
> >
> > Jack
> >
>

A couple of years ago I helped my wife figure out how to manage her
waiting list (she is an oldage psychiatrist) using toc and agile
principles. She got her waiting list time down from 20+ weeks wait
from when a gp doctor refers the patient to when she gets to see the
patient to about 12 weeks.

I guided her but she did all the thinking and doing.  Plus she worked
her butt off to do it. Her colleagues waiting times were all in the
20+ week too and the govt promises were around 18 weeks.

Within a few months her queue was back up to around 20 weeks. Why?
The gps started referring more patients to her because ... Because she
had shorter queues !

Even though she was treating far more patients each week than her
collegues she she looked no better. She kept working hard but slowed
down a little. They're measured by waiting time - not throughput.

This is in the nhs btw. There's no profit motive.

Clarke Ching


On 3 Feb 2010, at 04:36 PM, "lawrence_leach"
<lawrence_leach@...> wrote:

> Hi David
>
> Here is something that might be missing:
>
> http://www.ted.com/talks/sendhil_mullainathan.html
>
> I think one of the biggest disservices Eli G has done to the TOC
> world is to pose his "layers of resistance" model. It is sad to see
> how many uncritically accept his untested, and I believe incorrect,
> hypothesis. We have plenty of research confirming that people do not
> behave according to such "logic". We can use that knowledge to help
> them behave in ways that are better for themselves, and in the
> video, their children.
>
> We need to think for ourselves, and apply the scientific method to
> such problems.
>
> What you are missing is one of Deming's four points of Profound
> Knowledge: Psychology. You can use it and the scientific method
> (Another of Deming's SoPK: theory of knowledge) to test each of the
> solutions you hypothesize, and to invent others, to get the desired
> result.
>
> Regards,
> Larry Leach
>
>
>
>
> --- In CriticalChain@yahoogroups.com, David Peterson <david@...>
> wrote:
>>
>> OK, so the assumption is that multi-tasking will give better
>> service to the
>> customers, which as we know is wrong, wrong, wrong. It seems like a
>> fairly
>> easy cloud to evaporate...
>>
>> - Have strict visible WIP limits. E.g. using Kanban tokens.
>> - Hide the queue. E.g. with a good receptionist, the doctor can
>> focus on one
>> patient at a time and never see the queue of people in the waiting
>> room.
>> - Educate the customers.
>> - Reduce the size of the items to reduce the cycle time.
>> - Have clear policies about expediting.
>> - Just ignore the queue. You know you'll get through the queue
>> quicker if
>> you single-task, so don't worry about it.
>>
>> Or am I missing something?
>>
>> David
>>
>>
>> On 3 February 2010 00:48, lawrence_leach <lawrence_leach@...> wrote:
>>
>>>
>>>
>>> Hi, David
>>>
>>> Sure. If people have a visible list of many tasks, they often feel
>>> that as
>>> pressure. They feel that they have to show that they are working on
>>> something for each customer.
>>>
>>> Larry
>>>
>>>
>>> --- In CriticalChain@yahoogroups.com <CriticalChain
>>> %40yahoogroups.com>,
>>> David Peterson <david@> wrote:
>>>>
>>>> Hi Larry,
>>>>
>>>> You said: "A queue puts pressure on the drum to multitask."
>>>>
>>>> Can you expand on the cause-effect logic of this statement? I'm
>>>> not clear
>>>> about it.
>>>>
>>>> David
>>>>
>>>>
>>>> On 1 February 2010 02:49, lawrence_leach <lawrence_leach@> wrote:
>>>>
>>>>>
>>>>>
>>>>> Hi, Jack
>>>>>
>>>>> It came up with some DBR people. There, you deliberately keep a
>>>>> queue
>>> for
>>>>> the drum so as to not starve it. You then use the size of the
>>>>> queue to
>>>>> trigger release of work into the system. Usually that won't work
>>>>> with
>>>>> projects because there is a substantial time delay between
>>>>> release of a
>>>>> project and drum work on it. And it can vary for every project.
>>>>>
>>>>> In CC, the primary way to exploit the drum is to eliminate
>>> multitasking. A
>>>>> queue puts pressure on the drum to multitask. Queue time also adds
>>> directly
>>>>> to cycle time. Cycle time relates inversely to Throughput through
>>> Little's
>>>>> law.
>>>>>
>>>>> So it certainly appears to be a conflict to me.
>>>>>
>>>>> Larry
>>>>>
>>>>>
>>>>> --- In CriticalChain@yahoogroups.com <CriticalChain
>>>>> %40yahoogroups.com><CriticalChain%
>>> 40yahoogroups.com>,
>>>
>>>>> "Jack Vinson" <jackvinson@> wrote:
>>>>>>
>>>>>> Same with questions I've had. It didn't catch anyone's eye /
>>> excitement.
>>>>>>
>>>>>> I wonder if "queue time" doesn't quite make sense in the Project
>>>>>> environment? (The terminology, not the concept.) Maybe it
>>>>>> should be
>>>>>> work-in-process (WIP) or "active tasks" for the constraint? In
>>>>>> that
>>>>> light,
>>>>>> the cloud is that we want to maximize throughput by minimizing
>>>>>> cycle
>>> time
>>>>>> AND not starve the drum. We believe the cycle time is important
>>> because
>>>>>> faster projects = happy customers, faster $$. We believe that we
>>> don't
>>>>> want
>>>>>> to starve the drum because "an hour lost on the constraint is
>>>>>> lost
>>>>> forever."
>>>>>> In order to minimize cycle time, we don't want to release work
>>>>>> into
>>> the
>>>>>> system before the system can handle the work. And in order to not
>>> starve
>>>>>> the drum, we need to release enough work into the system to
>>>>>> keep a
>>> queue
>>>>> /
>>>>>> work in front of the drum.
>>>>>>
>>>>>> The way I am thinking of "D," I am not sure if there is a
>>>>>> conflict.
>>> Sure,
>>>>>> we could get even faster turnaround time, but at the expense of
>>> starving
>>>>> the
>>>>>> drum from time to time. So release work into the system such
>>>>>> that the
>>>>> drum
>>>>>> is expected to be active on project work all the time. And then
>>>>>> focus
>>> on
>>>>>> "road runner" in all the tasks and monitor the drum. If it is
>>>>>> starved
>>>>> "too
>>>>>> often," then there is room for more projects or the constraint
>>>>>> has
>>> moved.
>>>>>
>>>>>>
>>>>>> Yes? No? Were you thinking along a different line?
>>>>>>
>>>>>> Jack
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> [Non-text portions of this message have been removed]
>>>>
>>>
>>>
>>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>
>
>
>
> ------------------------------------
>
> To unsubscribe from this discussion, send an email to:
> CriticalChain-unsubscribe@egroups.com
> Any administrative comments or questions should be sent to:
> CriticalChain-owner@egroups.com
> Yahoo! Groups Links
>
>
>

Hi, Jack

Yes, AND...I had a brilliant observation made by a customer the other day in
regard to handling non-project work.

His point was that only the drum resource is loaded to (or near) capacity, over
a reasonable period of time. He is right about that: the CC softare lets you see
the load to capacity for each resource for all projects in the active Pipeline.
It is usually a Pareto type result; i.e. there is a rapid drop off of
load/capacity for the non-drum resources.

This means that even with a fully loaded pipeline of projects, there is huge
unused capacity in the system. We need a way to direct the new emergency work to
those "idle" resources.

Some say, "Yes, but...it is always the same few knowledge resources that are
needed for that non-project work as well". In other words, only the drum
resource can do the non-project work, too.

A few organizations have taken that to heart, and kept those most important
resources OUT of the project assignments. They help on the project assignments
when they are available for that, or they do the emergency work whan it has
higher priority.

It's a hard bullet to bite up front, but leads to a marvelously effective
system.

Regards,
Larry Leach



--- In CriticalChain@yahoogroups.com, "Jack Vinson" <jackvinson@...> wrote:
>
> Someone just asked me a question offline that made me rethink this
> discussion.
>
> Is there a large queue of work for the constraint resource, if you are doing
> multi-project CCPM and gauging the release of projects based on the capacity
> of that constraint?  There is a queue of unreleased projects.  And most CCPM
> will use a capacity buffer to add time between projects (increase the cycle
> time) in order to ensure variation within projects does not impinge on other
> projects.
>
> As I suggested before, the size of this capacity buffer can be debated, but
> there is probably plenty of room for wiggle, and whether you have too much
> or too little capacity buffer should appear from your project buffer
> management statistics.
>
> Jack Vinson
>

re: David's comment

"instead of developing many features simultaneously, the teams develop one
feature at a time and until work begins on a feature, the business are free
to change their minds about which feature comes next."

Of course the choice of one feature - or the way it is implemented - may
well make it impossible to create one that is requested later, or at least
create considerable rework as well as unmanageable complexity and
instability.

Kik


Crispin ("Kik") Piney, PgMP

kik@...
+33 (0)680 11 57 77

-----Original Message-----
From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of David Peterson
Sent: 03 February 2010 16:45
To: CriticalChain@yahoogroups.com
Subject: Re: [CriticalChain] Re: Discussion Cloud

I love paying to jump the queue with Ryanair. I think they could segment
their market further by allowing people to bid for their place in the queue.
I guess that would be too complicated to manage at the gates.

The queues I hate are the ones where you think you're nearing the front only
to find that you've been queuing to get into the real queue inside. The
Eiffel tower did that to me. If I'd have known how far back I was, I
wouldn't have bothered. But once I'd got that far I decided to carry on. So
maybe there are some tactics for concealing the queue from customers -
especially if it's a single transaction rather than a relationship.

The queues I like are the ones where they give you a pager and you can go
and have a cup of coffee and they buzz you when it's your turn. Or failing
that, a take-a-number system where you know it's fair and can quickly gauge
how long you're going to be waiting.

Corey Ladas talks about software teams striking a different bargain with the
business<http://leansoftwareengineering.com/2007/09/10/striking-a-different-
bargain-with-the-business/>
-
instead of developing many features simultaneously, the teams develop one
feature at a time and until work begins on a feature, the business are free
to change their minds about which feature comes next. By limiting WIP, the
lead times become consistent enough that the development team can almost
guarantee a level of service - e.g. if the business submit a feature this
week, the feature will be delivered to them within 30 days. There's only one
queue and the business have to collaborate and decide together what goes in
it and specifically what gets selected next.

David

Hi, All

I agree with Tony. I missed the point he responded to.

This doesn't really relate to the cloud I posed, but might interest some:

I like to illustrate exploiting with the five ship story, first relayed to me by
Karl Buckrige. I'll tell it here also in response to the simple storys request.
I have matured its telling since Karl taught it to me many years ago. It is now
the most "sticky" story I have in all of my presentations. Everyone gets it. I
have even added ways to handle two major NBRs that used to inevetiably be
raised. In this case, I will not handle them up front as I usually do, but will
do so when they are raised by this group, as I am pretty sure they will be.

The situation is that you supervise five staff who unload ships. Five ships
arrive at your dock Monday morning to be unloaded. Each will require five
person-days to unload. What do you do?

Because ship Captains are notoriously ill-mannered people (think of them like
Project Managers), you know you need to get started on each one, so you assign
one of your staff to each ship. The Captains are happy as clams, and on Friday
evening all ships are unloaded, and can go out and make money for their company.

Is there a better way? Stop for a moment and think...I wouldn't ask it here
unless there was, would I?

You decide to exploit your resource by putting all five people on ship one on
Monday. The five person days of work are done on Monday evening, ao it is good
to go. You just saved 80% of the cycle time for that ship.

Then you move everyone to ship 2 on Tuesday. It finishes Tuesday evening, saving
60% on cycle time, if you allow for the time it sat idle, or 80% also if you
only count the active work time on it.

And so on till ship 5 on Friday, on which you save nothing on overall cycle
time, but lose nothing either. So you gain on cycle time for four out of the
five ships, just by focusing your resources.

OBTW, if you now have established this staggering as your way of doing business,
and the ships go out on some routine schedule, you may get the 80% savings, or
maybe at least 60% allowing for some variation, on all future ships.

Regards,
Larry Leach





--- In CriticalChain@yahoogroups.com, "Tony Rizzo" <Tony.Rizzo@...> wrote:
>
> >:  ...most will use a capacity buffer to add time between
>
> >:  projects (increase the cycle time)
>
>
>
> This is false.
>
>
>
> Project-duration is measured from start to finish.  By spacing projects on
> the timeline, with a capacity-buffer, we do not delay the start of each
> project beyond the release-time that corresponds to a JIT arrival at the
> bottleneck.  We simply prevent the damagingly early release of each project,
> thereby blocking the false perceptions of urgency that force multitasking to
> happen.
>
>
>
> Using the capacity-buffer does not increase project-duration.  Rather, it
> causes the smallest practicable values of project-duration, and, more
> importantly, it increases the rate of flow through the primary system,
> causing significantly greater productivity without requiring one cent of
> additional expense.
>
> Tony Rizzo
>
> +1.908.322.1840 desk
> +1.908.930.0411 mobile
>  <mailto:tony.rizzo@...> tony.rizzo@...
>
>
>
> From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
> On Behalf Of Jack Vinson
> Sent: Tuesday, February 02, 2010 5:53 PM
> To: CriticalChain@yahoogroups.com
> Subject: RE: [CriticalChain] Re: Discussion Cloud
>
>
>
>
>
> Someone just asked me a question offline that made me rethink this
> discussion.
>
> Is there a large queue of work for the constraint resource, if you are doing
> multi-project CCPM and gauging the release of projects based on the capacity
> of that constraint? There is a queue of unreleased projects. And most CCPM
> will use a capacity buffer to add time between projects (increase the cycle
> time) in order to ensure variation within projects does not impinge on other
> projects.
>
> As I suggested before, the size of this capacity buffer can be debated, but
> there is probably plenty of room for wiggle, and whether you have too much
> or too little capacity buffer should appear from your project buffer
> management statistics.
>
> Jack Vinson
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Hi, All

On second thought, maybe I should have said "I agree with Tony from the point of
view of the system manager".

Of course, to the customer for project five, it looks like your project
staggering increased the cycle time on their project...the time from their order
till they get their result. And if you use a capacity buffer, it looks like an
absolute increase to the promised date.

In execution you don't wait on capacity buffers, and so you do actually get the
early projects our faster, and do not delay the last project.

In a real environment, you in fact get all projects done sooner, because you
reduce the waste of task switching...something not addressed by the story. You
also get them out better, because quality defects decrease, and maybe even a
little cheaper...

OBTW, with a full system the ship example, like the bead game, only improves
cycle time, not Throughput of ships, for the dockmaster. On the other hand, it
could dramatically increase T for the ship's Captains. What to make of that?

Regards,
Larry Leach


--- In CriticalChain@yahoogroups.com, "Tony Rizzo" <Tony.Rizzo@...> wrote:
>
> >:  ...most will use a capacity buffer to add time between
>
> >:  projects (increase the cycle time)
>
>
>
> This is false.
>
>
>
> Project-duration is measured from start to finish.  By spacing projects on
> the timeline, with a capacity-buffer, we do not delay the start of each
> project beyond the release-time that corresponds to a JIT arrival at the
> bottleneck.  We simply prevent the damagingly early release of each project,
> thereby blocking the false perceptions of urgency that force multitasking to
> happen.
>
>
>
> Using the capacity-buffer does not increase project-duration.  Rather, it
> causes the smallest practicable values of project-duration, and, more
> importantly, it increases the rate of flow through the primary system,
> causing significantly greater productivity without requiring one cent of
> additional expense.
>
> Tony Rizzo
>
> +1.908.322.1840 desk
> +1.908.930.0411 mobile
>  <mailto:tony.rizzo@...> tony.rizzo@...
>
>
>
> From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
> On Behalf Of Jack Vinson
> Sent: Tuesday, February 02, 2010 5:53 PM
> To: CriticalChain@yahoogroups.com
> Subject: RE: [CriticalChain] Re: Discussion Cloud
>
>
>
>
>
> Someone just asked me a question offline that made me rethink this
> discussion.
>
> Is there a large queue of work for the constraint resource, if you are doing
> multi-project CCPM and gauging the release of projects based on the capacity
> of that constraint? There is a queue of unreleased projects. And most CCPM
> will use a capacity buffer to add time between projects (increase the cycle
> time) in order to ensure variation within projects does not impinge on other
> projects.
>
> As I suggested before, the size of this capacity buffer can be debated, but
> there is probably plenty of room for wiggle, and whether you have too much
> or too little capacity buffer should appear from your project buffer
> management statistics.
>
> Jack Vinson
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

hi,

On Wed, Feb 3, 2010 at 8:43 AM, lawrence_leach
<lawrence_leach@...> wrote:
> The Goal is live trees. The humans are the constraint to the system. They just
aren't very reliable. (Six sigma problem?) Sometimes they go on vacation, etc.
We exploit them by reducing the time they have to spend; i.e. putting in the
hydrants. But then we need move on to elevate; in this case replace them
(mostly) by the automatic sprinklers.
>
> The humans are still a necessary condition, of course. They need to maintain
the system, and turn it on before they leave on vaction.

so for me, on the whole, this example is not turning on any lightbulbs
over my head about how CC-ToC is different than Lean-ToC. my current
guess is that there are many situations where the two approaches would
do much the same thing (they are both based on ToC after all), and
thus those situations don't contrast the two.

sincerely.

>:  I should have just gone to sleep.



                 :-)



>: Increasing the size of the capacity will increase

>: the time between work on one project and work

>: on the next.



No, it won't.  Increasing the spacing between the models of individual
projects, on a depiction of our timeline, changes only the value of
duration-to-completion that we predict with our models and with which we
manage the expectations of interested parties.



Increasing the spacing between the models of individual projects, on a
depiction of our timeline, must not affect the timing of the actual releases
of the physical projects.  The timing of the actual releases of the physical
projects must remain consistent with a buffered-JIT arrival at the
bottleneck, or we risk starving the bottleneck of work and consequently
reducing the output rate of the system.





>: Decreasing the cycle time too far _can_ have a

>: damaging impact on projects due to too-early

>: release and potential for variability to cascade into

>: other projects.



If by "Decreasing the cycle time too far" you mean releasing the physical
projects sooner than the JIT release-time, I agree with you fully.  This can
be very damaging.  In fact, this is precisely what's happening today,
globally.  The primary systems of most knowledge-work companies currently
are operated without any form of flow-control.  Those who claim that they do
use flow-control usually don't know a great deal about control-methods.
Often these individuals consider acceptable such methods as using the annual
budget as a trigger that releases a large number of projects simultaneously.
At times, even individuals who should know better, resort to crude methods
like monitoring the aggregate utilization of resources and releasing
projects in groups whenever the aggregate utilization falls below an already
excessively high value.



Failing to control adequately the flow of projects through a primary system
creates both, some real urgencies and many, false urgencies.  All are
artificial.  The resulting, widespread perceptions of urgency in turn cause
the senior executives and the resource-managers to respond with that most
damaging and comparably ubiquitous of responses, multitasking.



When a primary system is managed per the CCMPM model (CCMPM, not CCPM), as
you point out, the actual releases of projects remain consistent with
buffered-JIT arrivals at the bottleneck.  This method of control not only
eliminates all the unnecessary work-in-process but, more importantly, it
renders the entire system hugely more manageable.  The managers gain a
task-level prioritization system with which they can eliminate the
multitasking entirely and release the full speed and capacity of which their
system is capable.



Such systems are joys to behold, for the two years of three that their
fragile deployments last.



Tony Rizzo

+1.908.322.1840 desk
+1.908.930.0411 mobile
  <mailto:tony.rizzo@...> tony.rizzo@...



From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Jack Vinson
Sent: Wednesday, February 03, 2010 3:35 AM
To: CriticalChain@yahoogroups.com
Subject: RE: [CriticalChain] Re: Discussion Cloud





I wrote that just before going to sleep. I should have just gone to sleep.

By the reference to cycle time, I mean the cycle time on the constraint.
You are correct that it will not increase the duration of the projects
overall - it just affects the spacing of the projects. Increasing the size
of the capacity will increase the time between work on one project and work
on the next. Decreasing the cycle time too far _can_ have a damaging impact
on projects due to too-early release and potential for variability to
cascade into other projects.

Jack

-----Original Message-----
From: CriticalChain@yahoogroups.com <mailto:CriticalChain%40yahoogroups.com>
[mailto:CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> ]
On Behalf Of Tony Rizzo
Sent: Tuesday, 02 February 2010 11:54 PM
To: CriticalChain@yahoogroups.com <mailto:CriticalChain%40yahoogroups.com>
Subject: RE: [CriticalChain] Re: Discussion Cloud

>: ...most will use a capacity buffer to add time between

>: projects (increase the cycle time)

This is false.

Project-duration is measured from start to finish. By spacing projects on
the timeline, with a capacity-buffer, we do not delay the start of each
project beyond the release-time that corresponds to a JIT arrival at the
bottleneck. We simply prevent the damagingly early release of each project,
thereby blocking the false perceptions of urgency that force multitasking to
happen.

Using the capacity-buffer does not increase project-duration. Rather, it
causes the smallest practicable values of project-duration, and, more
importantly, it increases the rate of flow through the primary system,
causing significantly greater productivity without requiring one cent of
additional expense.

Tony Rizzo

+1.908.322.1840 desk
+1.908.930.0411 mobile
<mailto:tony.rizzo@... <mailto:tony.rizzo%40pdinstitute.com> >
tony.rizzo@... <mailto:tony.rizzo%40pdinstitute.com>

From: CriticalChain@yahoogroups.com <mailto:CriticalChain%40yahoogroups.com>
[mailto:CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> ]
On Behalf Of Jack Vinson
Sent: Tuesday, February 02, 2010 5:53 PM
To: CriticalChain@yahoogroups.com <mailto:CriticalChain%40yahoogroups.com>
Subject: RE: [CriticalChain] Re: Discussion Cloud

Someone just asked me a question offline that made me rethink this
discussion.

Is there a large queue of work for the constraint resource, if you are doing
multi-project CCPM and gauging the release of projects based on the capacity
of that constraint? There is a queue of unreleased projects. And most CCPM
will use a capacity buffer to add time between projects (increase the cycle
time) in order to ensure variation within projects does not impinge on other
projects.

As I suggested before, the size of this capacity buffer can be debated, but
there is probably plenty of room for wiggle, and whether you have too much
or too little capacity buffer should appear from your project buffer
management statistics.

Jack Vinson

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

------------------------------------

To unsubscribe from this discussion, send an email to:
CriticalChain-unsubscribe@egroups.com
<mailto:CriticalChain-unsubscribe%40egroups.com>
Any administrative comments or questions should be sent to:
CriticalChain-owner@egroups.com <mailto:CriticalChain-owner%40egroups.com>
Yahoo! Groups Links





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

English kings!  And just the other night you were ravaged by a Swiss
prince!

www.justinroffmarsh.com
[Sent from my phone: please excuse brevity!]
Phone: Ext 10
       US:  773 649 1688
       Aus: 07 3102 3404

On Feb 4, 2010, at 1:51 AM, "Clarke Ching" <clarke.ching@...>
wrote:

> Here in Scotland they're less obsessed with queues and more obsessed
> with moaning about you English folk and what your kings did centuries
> ago. I generlise ...
>
> One thing about queues which I think we sometimes forget: queues
> indicate scarcity and popularity. According to limited understanding
> of marketing both scarcity and popularity are very powerful
> influencing tools. I'm think of nightclubs which gave a queue soooooo
> people join it (contrasted with one with no queue which no one wants
> to go into). I'm thinking of the skin cream which sold out here in the
> uk last year and suddenly became very popular because it was scarce.
> I'm thinking of Ryan air which charges extra to jump the boarding
> queues. I'm thinking of farm economics where price elasticity means
> they cn earn more money by reducing supply - even if it means not
> selling everything they sell.
>
> Perhaps external queues mean we hve something people want to buy?
>
> I wonder how else we could exploit queues to charge more or otherwise
> mke more money. Any thoughts?
>
> Clarke Ching
>
> On 3 Feb 2010, at 02:18 PM, David Peterson <david@...>
> wrote:
>
> > Does it actually stop the nicer-word-than-nagging? Or is it like
> > removing a
> > bottleneck - there's always another one. I have suspicions that
> wives
> > secretly love "reminding" their husbands and if husbands kept
> > dropping what
> > they were doing to attend to their wives every need, it would take
> > all the
> > fun out of it. And, maybe not in Scotland, but in England, queuing
> and
> > moaning are our nation's favourite pastimes. A long queue wouldn't
> > put us
> > off. We'd just see it as a wonderful opportunity to huff and
> puff. :)
> >
> > David
> >
> >
> >
> > On 3 February 2010 13:26, Clarke Ching <clarke.ching@...>
> wrote:
> >
> >>
> >>
> >> Good stuff David. I think the thing you may be missing is the power
> >> of
> >> the voices of a kazillion customers in the queue shouting or
> nagging
> >> "me me me" and the others shouting "goodbye" as they leave taking
> >> their money with them.
> >>
> >> I know i do a lot of things i consider unimportant just to stop the
> >> nicer-word-than-nagging from my (lovely) wife ...
> >>
> >> Clarke Ching
> >>
> >>
> >> On 3 Feb 2010, at 12:39 PM, David Peterson
> >> <david@...<david%40crowdsoft.com>>
> >> wrote:
> >>
> >>> OK, so the assumption is that multi-tasking will give better
> service
> >>> to the
> >>> customers, which as we know is wrong, wrong, wrong. It seems
> like a
> >>> fairly
> >>> easy cloud to evaporate...
> >>>
> >>> - Have strict visible WIP limits. E.g. using Kanban tokens.
> >>> - Hide the queue. E.g. with a good receptionist, the doctor can
> >>> focus on one
> >>> patient at a time and never see the queue of people in the waiting
> >>> room.
> >>> - Educate the customers.
> >>> - Reduce the size of the items to reduce the cycle time.
> >>> - Have clear policies about expediting.
> >>> - Just ignore the queue. You know you'll get through the queue
> >>> quicker if
> >>> you single-task, so don't worry about it.
> >>>
> >>> Or am I missing something?
> >>>
> >>> David
> >>>
> >>>
> >>> On 3 February 2010 00:48, lawrence_leach
> >>> <lawrence_leach@... <lawrence_leach%40hotmail.com>> wrote:
> >>>
> >>>>
> >>>>
> >>>> Hi, David
> >>>>
> >>>> Sure. If people have a visible list of many tasks, they often
> feel
> >>>> that as
> >>>> pressure. They feel that they have to show that they are
> working on
> >>>> something for each customer.
> >>>>
> >>>> Larry
> >>>>
> >>>>
> >>>> --- In CriticalChain@yahoogroups.com <CriticalChain
> >>>> %40yahoogroups.com><CriticalChain
> >>>> %40yahoogroups.com>,
> >>
> >>>> David Peterson <david@...> wrote:
> >>>>>
> >>>>> Hi Larry,
> >>>>>
> >>>>> You said: "A queue puts pressure on the drum to multitask."
> >>>>>
> >>>>> Can you expand on the cause-effect logic of this statement? I'm
> >>>>> not clear
> >>>>> about it.
> >>>>>
> >>>>> David
> >>>>>
> >>>>>
> >>>>> On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi, Jack
> >>>>>>
> >>>>>> It came up with some DBR people. There, you deliberately keep a
> >>>>>> queue
> >>>> for
> >>>>>> the drum so as to not starve it. You then use the size of the
> >>>>>> queue to
> >>>>>> trigger release of work into the system. Usually that won't
> work
> >>>>>> with
> >>>>>> projects because there is a substantial time delay between
> >>>>>> release of a
> >>>>>> project and drum work on it. And it can vary for every project.
> >>>>>>
> >>>>>> In CC, the primary way to exploit the drum is to eliminate
> >>>> multitasking. A
> >>>>>> queue puts pressure on the drum to multitask. Queue time also
> >>>>>> adds
> >>>> directly
> >>>>>> to cycle time. Cycle time relates inversely to Throughput
> through
> >>>> Little's
> >>>>>> law.
> >>>>>>
> >>>>>> So it certainly appears to be a conflict to me.
> >>>>>>
> >>>>>> Larry
> >>>>>>
> >>>>>>
> >>>>>> --- In CriticalChain@yahoogroups.com<CriticalChain
> >>>>>> %40yahoogroups.com><CriticalChain
> >>>>>> %40yahoogroups.com><CriticalChain%
> >>
> >>>> 40yahoogroups.com>,
> >>>>
> >>>>>> "Jack Vinson" <jackvinson@> wrote:
> >>>>>>>
> >>>>>>> Same with questions I've had. It didn't catch anyone's eye /
> >>>> excitement.
> >>>>>>>
> >>>>>>> I wonder if "queue time" doesn't quite make sense in the
> Project
> >>>>>>> environment? (The terminology, not the concept.) Maybe it
> should
> >>>>>>> be
> >>>>>>> work-in-process (WIP) or "active tasks" for the constraint? In
> >>>>>>> that
> >>>>>> light,
> >>>>>>> the cloud is that we want to maximize throughput by minimizing
> >>>>>>> cycle
> >>>> time
> >>>>>>> AND not starve the drum. We believe the cycle time is
> important
> >>>> because
> >>>>>>> faster projects = happy customers, faster $$. We believe
> that we
> >>>> don't
> >>>>>> want
> >>>>>>> to starve the drum because "an hour lost on the constraint is
> >>>>>>> lost
> >>>>>> forever."
> >>>>>>> In order to minimize cycle time, we don't want to release work
> >>>>>>> into
> >>>> the
> >>>>>>> system before the system can handle the work. And in order to
> >>>>>>> not
> >>>> starve
> >>>>>>> the drum, we need to release enough work into the system to
> >>>>>>> keep a
> >>>> queue
> >>>>>> /
> >>>>>>> work in front of the drum.
> >>>>>>>
> >>>>>>> The way I am thinking of "D," I am not sure if there is a
> >>>>>>> conflict.
> >>>> Sure,
> >>>>>>> we could get even faster turnaround time, but at the expense
> of
> >>>> starving
> >>>>>> the
> >>>>>>> drum from time to time. So release work into the system such
> >>>>>>> that the
> >>>>>> drum
> >>>>>>> is expected to be active on project work all the time. And
> then
> >>>>>>> focus
> >>>> on
> >>>>>>> "road runner" in all the tasks and monitor the drum. If it is
> >>>>>>> starved
> >>>>>> "too
> >>>>>>> often," then there is room for more projects or the constraint
> >>>>>>> has
> >>>> moved.
> >>>>>>
> >>>>>>>
> >>>>>>> Yes? No? Were you thinking along a different line?
> >>>>>>>
> >>>>>>> Jack
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> [Non-text portions of this message have been removed]
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> [Non-text portions of this message have been removed]
> >>>
> >>>
> >>>
> >>> ------------------------------------
> >>
> >>>
> >>> To unsubscribe from this discussion, send an email to:
> >>> CriticalChain-unsubscribe@egroups.com<CriticalChain-unsubscribe
> >>> %40egroups.com>
> >>> Any administrative comments or questions should be sent to:
> >>> CriticalChain-owner@egroups.com <CriticalChain-owner
> %40egroups.com>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > To unsubscribe from this discussion, send an email to:
> > CriticalChain-unsubscribe@egroups.com
> > Any administrative comments or questions should be sent to:
> > CriticalChain-owner@egroups.com
> > Yahoo! Groups Links
> >
> >
> >
>


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

Riveted, I think. Not ranged.

(and for the record ... I'm not Scottish.)

Clarke Ching


On 3 Feb 2010, at 08:46 PM, "Justin Roff-Marsh"
<justin.roffmarsh@...
  > wrote:

> English kings!  And just the other night you were ravaged by a Swiss
> prince!
>
> www.justinroffmarsh.com
> [Sent from my phone: please excuse brevity!]
> Phone: Ext 10
>      US:  773 649 1688
>      Aus: 07 3102 3404
>
> On Feb 4, 2010, at 1:51 AM, "Clarke Ching" <clarke.ching@...>
> wrote:
>
>> Here in Scotland they're less obsessed with queues and more obsessed
>> with moaning about you English folk and what your kings did centuries
>> ago. I generlise ...
>>
>> One thing about queues which I think we sometimes forget: queues
>> indicate scarcity and popularity. According to limited understanding
>> of marketing both scarcity and popularity are very powerful
>> influencing tools. I'm think of nightclubs which gave a queue soooooo
>> people join it (contrasted with one with no queue which no one wants
>> to go into). I'm thinking of the skin cream which sold out here in
>> the
>> uk last year and suddenly became very popular because it was scarce.
>> I'm thinking of Ryan air which charges extra to jump the boarding
>> queues. I'm thinking of farm economics where price elasticity means
>> they cn earn more money by reducing supply - even if it means not
>> selling everything they sell.
>>
>> Perhaps external queues mean we hve something people want to buy?
>>
>> I wonder how else we could exploit queues to charge more or otherwise
>> mke more money. Any thoughts?
>>
>> Clarke Ching
>>
>> On 3 Feb 2010, at 02:18 PM, David Peterson <david@...>
>> wrote:
>>
>>> Does it actually stop the nicer-word-than-nagging? Or is it like
>>> removing a
>>> bottleneck - there's always another one. I have suspicions that
>> wives
>>> secretly love "reminding" their husbands and if husbands kept
>>> dropping what
>>> they were doing to attend to their wives every need, it would take
>>> all the
>>> fun out of it. And, maybe not in Scotland, but in England, queuing
>> and
>>> moaning are our nation's favourite pastimes. A long queue wouldn't
>>> put us
>>> off. We'd just see it as a wonderful opportunity to huff and
>> puff. :)
>>>
>>> David
>>>
>>>
>>>
>>> On 3 February 2010 13:26, Clarke Ching <clarke.ching@...>
>> wrote:
>>>
>>>>
>>>>
>>>> Good stuff David. I think the thing you may be missing is the power
>>>> of
>>>> the voices of a kazillion customers in the queue shouting or
>> nagging
>>>> "me me me" and the others shouting "goodbye" as they leave taking
>>>> their money with them.
>>>>
>>>> I know i do a lot of things i consider unimportant just to stop the
>>>> nicer-word-than-nagging from my (lovely) wife ...
>>>>
>>>> Clarke Ching
>>>>
>>>>
>>>> On 3 Feb 2010, at 12:39 PM, David Peterson
>>>> <david@...<david%40crowdsoft.com>>
>>>> wrote:
>>>>
>>>>> OK, so the assumption is that multi-tasking will give better
>> service
>>>>> to the
>>>>> customers, which as we know is wrong, wrong, wrong. It seems
>> like a
>>>>> fairly
>>>>> easy cloud to evaporate...
>>>>>
>>>>> - Have strict visible WIP limits. E.g. using Kanban tokens.
>>>>> - Hide the queue. E.g. with a good receptionist, the doctor can
>>>>> focus on one
>>>>> patient at a time and never see the queue of people in the waiting
>>>>> room.
>>>>> - Educate the customers.
>>>>> - Reduce the size of the items to reduce the cycle time.
>>>>> - Have clear policies about expediting.
>>>>> - Just ignore the queue. You know you'll get through the queue
>>>>> quicker if
>>>>> you single-task, so don't worry about it.
>>>>>
>>>>> Or am I missing something?
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> On 3 February 2010 00:48, lawrence_leach
>>>>> <lawrence_leach@... <lawrence_leach%40hotmail.com>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Hi, David
>>>>>>
>>>>>> Sure. If people have a visible list of many tasks, they often
>> feel
>>>>>> that as
>>>>>> pressure. They feel that they have to show that they are
>> working on
>>>>>> something for each customer.
>>>>>>
>>>>>> Larry
>>>>>>
>>>>>>
>>>>>> --- In CriticalChain@yahoogroups.com <CriticalChain
>>>>>> %40yahoogroups.com><CriticalChain
>>>>>> %40yahoogroups.com>,
>>>>
>>>>>> David Peterson <david@...> wrote:
>>>>>>>
>>>>>>> Hi Larry,
>>>>>>>
>>>>>>> You said: "A queue puts pressure on the drum to multitask."
>>>>>>>
>>>>>>> Can you expand on the cause-effect logic of this statement? I'm
>>>>>>> not clear
>>>>>>> about it.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>> On 1 February 2010 02:49, lawrence_leach <lawrence_leach@...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi, Jack
>>>>>>>>
>>>>>>>> It came up with some DBR people. There, you deliberately keep a
>>>>>>>> queue
>>>>>> for
>>>>>>>> the drum so as to not starve it. You then use the size of the
>>>>>>>> queue to
>>>>>>>> trigger release of work into the system. Usually that won't
>> work
>>>>>>>> with
>>>>>>>> projects because there is a substantial time delay between
>>>>>>>> release of a
>>>>>>>> project and drum work on it. And it can vary for every project.
>>>>>>>>
>>>>>>>> In CC, the primary way to exploit the drum is to eliminate
>>>>>> multitasking. A
>>>>>>>> queue puts pressure on the drum to multitask. Queue time also
>>>>>>>> adds
>>>>>> directly
>>>>>>>> to cycle time. Cycle time relates inversely to Throughput
>> through
>>>>>> Little's
>>>>>>>> law.
>>>>>>>>
>>>>>>>> So it certainly appears to be a conflict to me.
>>>>>>>>
>>>>>>>> Larry
>>>>>>>>
>>>>>>>>
>>>>>>>> --- In CriticalChain@yahoogroups.com<CriticalChain
>>>>>>>> %40yahoogroups.com><CriticalChain
>>>>>>>> %40yahoogroups.com><CriticalChain%
>>>>
>>>>>> 40yahoogroups.com>,
>>>>>>
>>>>>>>> "Jack Vinson" <jackvinson@> wrote:
>>>>>>>>>
>>>>>>>>> Same with questions I've had. It didn't catch anyone's eye /
>>>>>> excitement.
>>>>>>>>>
>>>>>>>>> I wonder if "queue time" doesn't quite make sense in the
>> Project
>>>>>>>>> environment? (The terminology, not the concept.) Maybe it
>> should
>>>>>>>>> be
>>>>>>>>> work-in-process (WIP) or "active tasks" for the constraint? In
>>>>>>>>> that
>>>>>>>> light,
>>>>>>>>> the cloud is that we want to maximize throughput by minimizing
>>>>>>>>> cycle
>>>>>> time
>>>>>>>>> AND not starve the drum. We believe the cycle time is
>> important
>>>>>> because
>>>>>>>>> faster projects = happy customers, faster $$. We believe
>> that we
>>>>>> don't
>>>>>>>> want
>>>>>>>>> to starve the drum because "an hour lost on the constraint is
>>>>>>>>> lost
>>>>>>>> forever."
>>>>>>>>> In order to minimize cycle time, we don't want to release work
>>>>>>>>> into
>>>>>> the
>>>>>>>>> system before the system can handle the work. And in order to
>>>>>>>>> not
>>>>>> starve
>>>>>>>>> the drum, we need to release enough work into the system to
>>>>>>>>> keep a
>>>>>> queue
>>>>>>>> /
>>>>>>>>> work in front of the drum.
>>>>>>>>>
>>>>>>>>> The way I am thinking of "D," I am not sure if there is a
>>>>>>>>> conflict.
>>>>>> Sure,
>>>>>>>>> we could get even faster turnaround time, but at the expense
>> of
>>>>>> starving
>>>>>>>> the
>>>>>>>>> drum from time to time. So release work into the system such
>>>>>>>>> that the
>>>>>>>> drum
>>>>>>>>> is expected to be active on project work all the time. And
>> then
>>>>>>>>> focus
>>>>>> on
>>>>>>>>> "road runner" in all the tasks and monitor the drum. If it is
>>>>>>>>> starved
>>>>>>>> "too
>>>>>>>>> often," then there is room for more projects or the constraint
>>>>>>>>> has
>>>>>> moved.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes? No? Were you thinking along a different line?
>>>>>>>>>
>>>>>>>>> Jack
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [Non-text portions of this message have been removed]
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> [Non-text portions of this message have been removed]
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------
>>>>
>>>>>
>>>>> To unsubscribe from this discussion, send an email to:
>>>>> CriticalChain-unsubscribe@egroups.com<CriticalChain-unsubscribe
>>>>> %40egroups.com>
>>>>> Any administrative comments or questions should be sent to:
>>>>> CriticalChain-owner@egroups.com <CriticalChain-owner
>> %40egroups.com>
>>>>> Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> To unsubscribe from this discussion, send an email to:
>>> CriticalChain-unsubscribe@egroups.com
>>> Any administrative comments or questions should be sent to:
>>> CriticalChain-owner@egroups.com
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> To unsubscribe from this discussion, send an email to:
> CriticalChain-unsubscribe@egroups.com
> Any administrative comments or questions should be sent to:
> CriticalChain-owner@egroups.com
> Yahoo! Groups Links
>
>
>

(anybody from TOCCA on the list?)

i found this PDF a decent read.

http://preview.tinyurl.com/y9f6paf

i'd appreciate folks' criticisms.

sincerely.

Hi, David

I think you are on the right track. In good Drs offices, the Doctor does not see
the queue, and they do not multitask. The queue is out in the waiting room,
where the Drs never go. The receptionists collect data, etc., and then move the
patient to one of servral exam rooms. The nurse gets with the patient and does
all she can do, and sets stuff up for the Dr. When the Dr. comes in, he does his
thing and then moves on to the next exam room.

Good Dentists have also moved to this model. I see the Dentist about 3 min on a
routine hour exam visit.

They are exploiting the constraint.

Customers are happy if they don't have to wait too long in the waiting area.

Regards,
Larry Leach


--- In CriticalChain@yahoogroups.com, David Peterson <david@...> wrote:
>
> OK, so the assumption is that multi-tasking will give better service to the
> customers, which as we know is wrong, wrong, wrong. It seems like a fairly
> easy cloud to evaporate...
>
> - Have strict visible WIP limits. E.g. using Kanban tokens.
> - Hide the queue. E.g. with a good receptionist, the doctor can focus on one
> patient at a time and never see the queue of people in the waiting room.
> - Educate the customers.
> - Reduce the size of the items to reduce the cycle time.
> - Have clear policies about expediting.
> - Just ignore the queue. You know you'll get through the queue quicker if
> you single-task, so don't worry about it.
>
> Or am I missing something?
>
> David
>
>
> On 3 February 2010 00:48, lawrence_leach <lawrence_leach@...> wrote:
>
> >
> >
> > Hi, David
> >
> > Sure. If people have a visible list of many tasks, they often feel that as
> > pressure. They feel that they have to show that they are working on
> > something for each customer.
> >
> > Larry
> >
> >
> > --- In CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>,
> > David Peterson <david@> wrote:
> > >
> > > Hi Larry,
> > >
> > > You said: "A queue puts pressure on the drum to multitask."
> > >
> > > Can you expand on the cause-effect logic of this statement? I'm not clear
> > > about it.
> > >
> > > David
> > >
> > >
> > > On 1 February 2010 02:49, lawrence_leach <lawrence_leach@> wrote:
> > >
> > > >
> > > >
> > > > Hi, Jack
> > > >
> > > > It came up with some DBR people. There, you deliberately keep a queue
> > for
> > > > the drum so as to not starve it. You then use the size of the queue to
> > > > trigger release of work into the system. Usually that won't work with
> > > > projects because there is a substantial time delay between release of a
> > > > project and drum work on it. And it can vary for every project.
> > > >
> > > > In CC, the primary way to exploit the drum is to eliminate
> > multitasking. A
> > > > queue puts pressure on the drum to multitask. Queue time also adds
> > directly
> > > > to cycle time. Cycle time relates inversely to Throughput through
> > Little's
> > > > law.
> > > >
> > > > So it certainly appears to be a conflict to me.
> > > >
> > > > Larry
> > > >
> > > >
> > > > --- In CriticalChain@yahoogroups.com
<CriticalChain%40yahoogroups.com><CriticalChain%
> > 40yahoogroups.com>,
> >
> > > > "Jack Vinson" <jackvinson@> wrote:
> > > > >
> > > > > Same with questions I've had. It didn't catch anyone's eye /
> > excitement.
> > > > >
> > > > > I wonder if "queue time" doesn't quite make sense in the Project
> > > > > environment? (The terminology, not the concept.) Maybe it should be
> > > > > work-in-process (WIP) or "active tasks" for the constraint? In that
> > > > light,
> > > > > the cloud is that we want to maximize throughput by minimizing cycle
> > time
> > > > > AND not starve the drum. We believe the cycle time is important
> > because
> > > > > faster projects = happy customers, faster $$. We believe that we
> > don't
> > > > want
> > > > > to starve the drum because "an hour lost on the constraint is lost
> > > > forever."
> > > > > In order to minimize cycle time, we don't want to release work into
> > the
> > > > > system before the system can handle the work. And in order to not
> > starve
> > > > > the drum, we need to release enough work into the system to keep a
> > queue
> > > > /
> > > > > work in front of the drum.
> > > > >
> > > > > The way I am thinking of "D," I am not sure if there is a conflict.
> > Sure,
> > > > > we could get even faster turnaround time, but at the expense of
> > starving
> > > > the
> > > > > drum from time to time. So release work into the system such that the
> > > > drum
> > > > > is expected to be active on project work all the time. And then focus
> > on
> > > > > "road runner" in all the tasks and monitor the drum. If it is starved
> > > > "too
> > > > > often," then there is room for more projects or the constraint has
> > moved.
> > > >
> > > > >
> > > > > Yes? No? Were you thinking along a different line?
> > > > >
> > > > > Jack
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

Hi, Raoul

What? Lean doesn't get CC at all. It uses takt time...the antithesis.

Regards,
Larry Leach

--- In CriticalChain@yahoogroups.com, Raoul Duke <raould@...> wrote:
>
> hi,
>
> On Wed, Feb 3, 2010 at 8:43 AM, lawrence_leach
> <lawrence_leach@...> wrote:
> > The Goal is live trees. The humans are the constraint to the system. They
just aren't very reliable. (Six sigma problem?) Sometimes they go on vacation,
etc. We exploit them by reducing the time they have to spend; i.e. putting in
the hydrants. But then we need move on to elevate; in this case replace them
(mostly) by the automatic sprinklers.
> >
> > The humans are still a necessary condition, of course. They need to maintain
the system, and turn it on before they leave on vaction.
>
> so for me, on the whole, this example is not turning on any lightbulbs
> over my head about how CC-ToC is different than Lean-ToC. my current
> guess is that there are many situations where the two approaches would
> do much the same thing (they are both based on ToC after all), and
> thus those situations don't contrast the two.
>
> sincerely.
>