Hi, Brian
Thanks for some helpful thoughts.
Yes, the place to start is with the lightbulbs we want to go off. One difficulty
is that the associations people carry for whatever they believe can differ quite
a lot, so the trigger for lightbulb in one person may leave another in the dark.
As time goes on, I learn more and more how most people's thinking about
variation is fundamentally flawed. The good news is that I have also learned
that many of the flaws are systematic. We have a chance with those.
But even for those, it isn't easy to substitute more rational thinking. That's
why Deming insisted that people stay with him for four days...and spent many
hours on his simulations. He first spent many years maturing his simple
simulations.
We have one good "sticky" one for multitasking: Tony Rizzo's bead game. I have
tried Rob Newbold's project dice game for a few years now, but have never found
it as meaningful. I am thinking it might do better to go back to the simpler
Goldratt dice game, followed by something that looks more like a project. That's
why "Sixes" intrigued me.
If I can get it working right, it will do for many lightbulbs. These include:
1. Cutting tasks and the project buffer.
2. Feeding buffers
3. Pipelining
4. Buffer recovery (bench resource)
And probably others.
James is a master at figuring out how to use such tools in various ways. He did
a presentation in Utah in May on PQ that took it to new heights! (Alas, the
feedback from the audiance around me indicated he needed about 4 hours for them
to get it, vs. the 30 minutes he had).
Let's keep at it.
Regards,
Larry Leach
--- In CriticalChain@yahoogroups.com, "Potter, James Brian" <cliotocguy@...>
wrote:
>
> Larry,
>
> Consider some network other than N tasks in series. Introduce a little
> parallelism. Maybe something (best viewed in a monospaced font like
> Courier) like . . .
>
> 1A-----+------2A--+
> \ \
> 1B--+ +----2B----+--3A--+
> \ / \
> 1C----+-------2C--+ +--4A--Complete
> /
> 1D------------2D-------3B--+
>
> Such a network (You can probably imagine a better one.) should shine a
> light on both the potential for exploiting "early" task finishes in
> serially dependent task chains and the "late" task completion risks
> (loss or "early" finish advantage in tasks in parallel with a "late"
> task) imposed by integration points.
>
> If you adjusted the number of tasks in the serial chain leg so that
> the expected time through the serial task sequence and the expected
> time through the sub-network containing serial components with
> parallelism within the component is (unlike the illustration above)
> nearly the same, I suspect that you'd get some lightbulb effects going
> on.
>
> Also, if folks find the example too artificial with all tasks having
> equal expected duration, you can find dice built on any of the five
> regular polyhedra (options for 4, 6, 8, 12, or 20 faces and numbered
> 1-4, 1-6, 1-8, 1-10 [two faces for each number on the icosahedron],
> 1-12, and 1-20). Try hobby shops, gaming specialty stores, and
> (naturally) on-line. For simplicity when using dice with different
> numbers of faces, you may want to have tasks complete upon a role of
> "1" so that all die rollers have the same objective.
>
> I can just imagine the things your clients might say to "motivate" a
> fellow client to "roll a one" (and how closely those things might
> resemble the "help" too frequently offered to teams working on a
> "late" task that's gumming up a project).
>
> :-)
>
> Brian Potter
>
> voice: 843/586-9177 (land)
> e-mail: ClioToCGuy@...
>
> Optimization is about pretending that tomorrow is the same as
> yesterday. ToC is about making tomorrow's chances better than
> yesterday's chances were.
>
>
>
> On Jul 2, 2009, at 1:19 AM, Lawrence wrote:
>
> Hi, James
>
> The problem I have is that statistical theory says we should use the
> mean, not the median. Only means add linearly.
>
> As I noted to Jay, it is actually a geometeric distribution. It has
> nothing to do with a beta distribution that I can figure out. The
> material you have at the beginning of the presentaion appears to me to
> be wrong; in particular the first distribution for the rolls, and then
> the cumulative.
>
> I really liked the bench resource idea! But with the numbers we were
> getting, there was no need for it. I was going to have them plot the
> results on a fever chart, and get the bench resource when they were in
> the red. They rarely even got in the green; i.e. buffer penetration
> was negative most of the time...even use a task estimate of 6.
>
> Regards,
> Larry
>
> --- In CriticalChain@yahoogroups.com, Santiago Velásquez Martínez
> <ifsavel@> wrote:
> >
> > Dr. Holts comments.......
> >
> > ---------- Forwarded message ----------
> > From: Holt, James R <jholt@>
> > Date: 2009/6/30
> > Subject: RE: [CriticalChain] Sixes
> > To: Santiago Velásquez Martínez <ifsavel@>
> > Cc: bjlists@
> >
> >
> > Looks like you guys are doing this exactly right! Help the audience
> > learn
> > the wide variety of duration time come not from the thrower but the
> > SYSTEM!
> >
> > The number of rolls to get a six is indeed a negative exponential
> > curve
> > (Number per roll).
> > The inverse of the Negative Exponential yields the Beta Curve (Rolls
> > per
> > number).
> > Those of you who study simulation will recognize the relationship.
> > But, that aside,
> > the lesson to learn is to protect the system and not the individual.
> >
> > You do need to play this with a group (or simulated group). With
> > only five
> > people, you don't get the benefits of aggregation.
> >
> > As you comfortably move to the a target of the median times the
> > number of
> > people and add a 50% buffer, you are generally much, much below the
> > previous
> > safe estimates.
> >
> > I encourage you to use the advanced versions of the Sixes Game. The
> > Concept
> > of RESOURCE BENCH is a breakthrough.
> > It's explained a bit better in the Assembly Game
> > http://www.vancouver.wsu.edu/fac/holt/em530/Docs/Assembly.ppt
> >
> > Keep thinking!
> >
> >
> > James R. Holt, Ph.D., PE
> > Engineering & Technology Management
> >
> >
> > ------------------------------
> > *From:* Santiago Velásquez Martínez [mailto:ifsavel@]
> > *Sent:* Tuesday, June 30, 2009 7:20 AM
> > *To:* Holt, James R
> > *Subject:* Fwd: [CriticalChain] Sixes
> >
> > Dr. Holt:
> >
> > For if you want to discuss this subject from your point of view....
> >
> > ---------- Forwarded message ----------
> > From: jblists <jblists@>
> > Date: 2009/6/30
> > Subject: Re: [CriticalChain] Sixes
> > To: CriticalChain@yahoogroups.com
> >
> >
> >
> >
> > Larry,
> >
> > I did a little playing in Excel and realized that the distribution of
> > the number of rolls is an exponential with a lambda of 1/6.
> >
> > This yields a median of a little more than 4, a mean of 6 and a
> > standard
> > deviation of 6.
> > Looking at the cumulative chart, 50% are less than or equal to 4, 85%
> > are a little less than 12 and 95% around 18.
> > Because it is a constantly decreasing function, you won't get the mean
> > to equal the median or any of the types of results with say a Beta
> > distribution.
> > Actually over 60% of the tasks will be less than the mean of 6.
> >
> > But if we use the mean as the average for a lot of runs then 10 runs
> > would be 60. I need to spend more time figuring out the variance of
> > the
> > resulting distribution. It may be normal or beta because it still
> > can't
> > go less than 0.
> >
> > More later.
> >
> >
> > Jay
> >
> > Lawrence wrote:
> >>
> >>
> >> Hi, Jay
> >>
> >> Did the Sixes game today with a dozen participants. It was OK, but
> >> did
> >> not go as I expected.
> >>
> >> Most did not get very high runs, altough we did 60 total. The highest
> >> was 32, but it was out there by iteself. Consequently, even with $20
> >> on the table, most were happy to go along with 10. A couple of them
> >> understood that was a great bet. I got them up to 15, but there was
> >> not a groundswell demanding it. So I took my money back, and we ran
> >> with 10 as the estimate.
> >>
> >> The highest actual was 60, so it wasn't useful for tracking buffer
> >> penetration or using the bench resource.
> >>
> >> I suspect this was a fluke, but it has me worried a little.I know
> >> using the mean is mathematically correct, but in this case it seems
> >> to
> >> overestimate. The median would work better. Maybe it is because of
> >> the
> >> nature of this distibution, having a such a long, low probability
> >> tail.
> >>
> >> Thoughts from the statisticians?
> >>
> >> Regards,
> >> Larry Leach
> >>
> >> --- In CriticalChain@yahoogroups.com <CriticalChain
> >> %40yahoogroups.com>
> >> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >> %2540yahoogroups.com>>,
> > "Lawrence"
> >> <lawrence_leach@> wrote:
> >>>
> >>> Hi, Jay
> >>>
> >>> Thanks.
> >>>
> >>> It is interesting that it came to the same number for this case. You
> >> need a buffer sizing approach that works generally; i.e. with
> >> different size tasks, and where you do not have the distribution.
> >>>
> >>> Regards,
> >>> Larry
> >>>
> >>> --- In CriticalChain@yahoogroups.com <CriticalChain
> >>> %40yahoogroups.com>
> >> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >> %2540yahoogroups.com>>,
> > jblists <jblists@> wrote:
> >>>>
> >>>> Larry,
> >>>>
> >>>> My formula is pretty straightforward and while my Statistics
> >>>> teacher
> >>>> would probably flunk me on this here goes.
> >>>>
> >>>> When we ran the trial runs, I tracked each trial on a histogram
> >> with a
> >>>> calculation of what percentage of trials were less than a given
> >> number.
> >>>> On our trials, 50% were at 4 or less and 90% were at 14 or less.
> >>>>
> >>>> The point I was trying to make to them was that 50% of the tasks
> >>>> were
> >>>> going to come in at the 50% estimate or earlier. For this reason, I
> >>>> claimed that 5 of the 10 'tasks' were going to take 4 or less
> >> rolls. The
> >>>> remaining 5 tasks were going to beat the 90% number which was 14.
> >>>>
> >>>> This leads to 5 tasks at 4 or 20 rolls for the 5 of them and
> >>>> 5 tasks at 14 or 70 rolls for the 5 of them,
> >>>> Adding the two numbers gave us 90 as a conservative estimate for
> >>>> the
> >>>> 'project'.
> >>>>
> >>>> This conservative estimate held as we finished the project in 75
> >> rolls.
> >>>>
> >>>> Hope this helps.
> >>>>
> >>>> Jay
> >>>>
> >>>>
> >>>> Lawrence wrote:
> >>>>>
> >>>>>
> >>>>> Hi, Jay
> >>>>>
> >>>>> Can you run that buffer siizng approach past us again, with a
> >> little
> >>>>> explanation?
> >>>>>
> >>>>> The theoretical median is 3.6, so 4 is pretty close. The
> >> theoretical
> >>>>> mean for this distribution is 6, so that is what one should use
> >>>>> for
> >>>>> the tasks, lacking data. Because this distribution is so skewed,
> >> being
> >>>>> free with "50% confidence" estimates doesn't work so good. The
> >> mean is
> >>>>> the central tendency that sums: not the median. Thus, with 10
> >>>>> tasks
> >>>>> the tasks would total 60 and the buffer add 30, for a total of 90.
> >>>>>
> >>>>> This is kind of like Deming's bead experiment in several ways.
> >> One is
> >>>>> that you should probably use the statistics from your process, vs.
> >>>>> using the theoretical distribution. Deming used to make a big deal
> >>>>> about the fact that the several rigs he used over years never
> >>>>> had a
> >>>>> mean that matched the theoretical: 10 red beads. I think the
> >>>>> ranged
> >>>>> form like 9.4 to 11.something.
> >>>>>
> >>>>> I like your idea for simulating Parknson's law as another
> >>>>> variation.
> >>>>>
> >>>>> Regards,
> >>>>> Larry Leach
> >>>>>
> >>>>> --- In CriticalChain@yahoogroups.com<CriticalChain
> >>>>> %40yahoogroups.com>
> >> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >> %2540yahoogroups.com>
> >>
> >>>>> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >>>>> %2540yahoogroups.com>>,
> > jblists <jblists@> wrote:
> >>>>>>
> >>>>>> Larry,
> >>>>>>
> >>>>>> I just used the sixes game in a Critical Chain class and it
> >> exceeded my
> >>>>>> expectations. The initial runs led to a 50% confidence at 4
> >> and 90%
> >>>>>> confidence of 14 rolls. I calculated the buffer at 5*4 + 5*14
> >> = 90. The
> >>>>>> likelihood of exceeding 85 is small but probably greater than
> >>>>>> 10%.
> >>>>>>
> >>>>>> I added a wrinkle when after the first person rolled a 6 (in 4
> >>>>> rolls) we
> >>>>>> all sat and waited for the next 10 rolls as the second task
> >> resource
> >>>>> was
> >>>>>> not "scheduled" to begin until roll 15
> >>>>>>
> >>>>>> Jay
> >>>>>>
> >>>>>> Lawrence wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi, Brian
> >>>>>>>
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>> The Wikipedia, which Prasad referenced, is a good source for the
> >>>>>>> equations I wanted. The key was realizing it is a geometric
> >>>>> progression.
> >>>>>>>
> >>>>>>> The formulas also work for the "sixes" dice game Dr. Holt
> >> uses. One
> >>>>>>> thing concerns me about it: the "task" variance is quite
> >> large (30).
> >>>>>>> That makes it hard to relate to a mean of 6. Also, my initial
> >>>>> physical
> >>>>>>> simulations of it did not feel good (nothing like a smoothe
> >>>>>>> distribution with 50 trials). With the ten tasks as he used, the
> >>>>>>> variance of the sum is 300, thus the standard deviation is
> >> about 20,
> >>>>>>> so I'd want a buffer about 60. I thought he ended up with
> >> 40, but
> >>>>> need
> >>>>>>> to check back.
> >>>>>>>
> >>>>>>> I need to continue working through some simulations on it. I
> >> have a
> >>>>>>> class next week that is going to be treated to my first
> >> trial of
> >>>>> it. I
> >>>>>>> particularly like two features of it:
> >>>>>>> 1. To get people to understand (in part) why they need to
> >> seriously
> >>>>>>> cut task duration estimates.
> >>>>>>> 2. The feeding buffer illustration.
> >>>>>>> I continue to find people struggling with those two ideas, so
> >>>>> continue
> >>>>>>> to look for ways to help.
> >>>>>>>
> >>>>>>> I intend to show the results with MS Project, as we go.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Larry Leach
> >>>>>>>
> >>>>>>> --- In CriticalChain@yahoogroups.com<CriticalChain
> >>>>>>> %40yahoogroups.com>
> >> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >> %2540yahoogroups.com>
> >>
> >>>>> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >>>>> %2540yahoogroups.com>
> >>
> >>>>>>> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >>>>>>> %2540yahoogroups.com>>,
> > "Potter, James Brian"
> >>>>>>> <cliotocguy@> wrote:
> >>>>>>>>
> >>>>>>>> Larry & Rob,
> >>>>>>>>
> >>>>>>>> The "coin toss until you get a head" distribution is
> >> indeed the
> >>>>>>>> geometric distribution. For this case . . .
> >>>>>>>>
> >>>>>>>> mean = 1 / ( 1/2 ) = 2 (as Larry suspects)
> >>>>>>>> Var = s^2 = ( 1 - 1/2 ) / [ ( 1/2 ) ^ 2 ] = 1/2 / 1/4 = 2
> >>>>>>>> s = sqrt( 2 )
> >>>>>>>>
> >>>>>>>> Groady details on page 20 of the second edition of the CRC
> >> Handbook
> >>>>>>>> for Probability and Statistics (and somewhere in every
> >> introductory
> >>>>>>>> statistics text ever written).
> >>>>>>>>
> >>>>>>>> Also, look at the closely related binomial distribution.
> >>>>>>>>
> >>>>>>>> Also, look at the somewhat similar (for modeling purposes)
> >>>>> exponential
> >>>>>>>> and Poisson distributions which may feel more friendly to
> >> those with
> >>>>>>>> queueing theory backgrounds.
> >>>>>>>>
> >>>>>>>> :-)
> >>>>>>>>
> >>>>>>>> Brian Potter
> >>>>>>>>
> >>>>>>>> voice: 843/586-9177 (land)
> >>>>>>>> e-mail: ClioToCGuy@
> >>>>>>>>
> >>>>>>>> Optimization is about pretending that tomorrow is the same as
> >>>>>>>> yesterday. ToC is about making tomorrow's chances better than
> >>>>>>>> yesterday's chances were.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Jun 18, 2009, at 9:00 AM, Rob Newbold wrote:
> >>>>>>>>
> >>>>>>>> Larry -
> >>>>>>>> I was thinking of something completely different, so I
> >> looked it
> >>>>> up. Try
> >>>>>>>>
> >> http://www.vancouver.wsu.edu/fac/holt/em530/Docs/SixesGame.pdf.
> >> <http://www.vancouver.wsu.edu/fac/holt/em530/Docs/SixesGame.pdf.>
> >>>>> <http://www.vancouver.wsu.edu/fac/holt/em530/Docs/SixesGame.pdf.
> >> <http://www.vancouver.wsu.edu/fac/holt/em530/Docs/SixesGame.pdf.>>
> >>>>>>>
> >> <http://www.vancouver.wsu.edu/fac/holt/em530/Docs/SixesGame.pdf.
> >> <http://www.vancouver.wsu.edu/fac/holt/em530/Docs/SixesGame.pdf.>
> >>>>> <http://www.vancouver.wsu.edu/fac/holt/em530/Docs/SixesGame.pdf.
> >> <http://www.vancouver.wsu.edu/fac/holt/em530/Docs/SixesGame.pdf.>>>
> >>>>>>>>
> >>>>>>>> I think it still boils down to a geometric series.
> >>>>>>>>
> >>>>>>>> Rob
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: "Lawrence" lawrence_leach@ lawrence_leach
> >>>>>>>> Sent: Thu Jun 18, 2009 2:48 am
> >>>>>>>> To: 'Critical Chain Group'
> >>>>>>>> Subject: RE: A little statistical help
> >>>>>>>>
> >>>>>>>> Hi, Rob
> >>>>>>>>
> >>>>>>>> I currently use a die and a table. You can simulate any
> >>>>> distribution you
> >>>>>>>> want
> >>>>>>>> with it. I make it match a distribution that is similar to
> >> many task
> >>>>>>>> distributions; i.e. a one is half the mean, a six is twice
> >> the
> >>>>> mean. It
> >>>>>>>> works
> >>>>>>>> OK, but flipping the coin seems simpler to me.
> >>>>>>>>
> >>>>>>>> One could just roll two dice, of course. It gives a nice
> >>>>> distribution.
> >>>>>>>> Showing
> >>>>>>>> some of the approaches are very robust in face of alternative
> >>>>>>>> distributions
> >>>>>>>> and
> >>>>>>>> viloation of strict assumptions (e.g. Central Limit
> >> Theorum) can
> >>>>> help,
> >>>>>>>> if
> >>>>>>>> you
> >>>>>>>> want to teach that.
> >>>>>>>>
> >>>>>>>> BTW, James gave a neat presentation in Ogden last month.
> >> He extended
> >>>>>>>> the PQ
> >>>>>>>> game
> >>>>>>>> to show how to use T accounting to support a number of
> >> different
> >>>>>>>> decisions/scenarios. He went through it too fast for the
> >> audiance at
> >>>>>>>> hand,
> >>>>>>>> but I
> >>>>>>>> could see how it could lead to some in-depth understanding
> >> if people
> >>>>>>>> were
> >>>>>>>> taken
> >>>>>>>> through it in a time that allows them to cogitate and
> >> learn...say 4
> >>>>>>>> hours.
> >>>>>>>> He
> >>>>>>>> did it in about 30 minutes. James is usually willing to
> >> share such
> >>>>>>>> stuff.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Larry
> >>>>>>>>
> >>>>>>>> --- In CriticalChain@yahoogroups.com<CriticalChain
> >>>>>>>> %40yahoogroups.com>
> >> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >> %2540yahoogroups.com>
> >>
> >>>>> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >>>>> %2540yahoogroups.com>
> >>
> >>>>>>> <mailto:CriticalChain%40yahoogroups.com<CriticalChain
> >>>>>>> %2540yahoogroups.com>>,
> > "Rob Newbold"
> >> <prochain@>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Larry -
> >>>>>>>>> Thanks for the recommendation. The coin flip is a pretty
> >> limited
> >>>>>>>>> distribution, I'm not sure how far you can take it. You
> >> might also
> >>>>>>>>> contact
> >>>>>>>>> Dr. James Holt -- at one point he was working on a dice
> >> game that
> >>>>>>>>> struck
> >>>>>>>> me
> >>>>>>>>> as having similarities, but with a more realistic
> >> distribution. I
> >>>>>>>>> don't
> >>>>>>>> know
> >>>>>>>>> if it's something he's in a position to pass around but it
> >>>>> wouldn't
> >>>>>>>>> hurt
> >>>>>>>> to
> >>>>>>>>> ask.
> >>>>>>>>>
> >>>>>>>>> Rob
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>>
> >>>>>>>>> Posted by: "Lawrence" lawrence_leach@ lawrence_leach
> >>>>>>>>> Date: Tue Jun 16, 2009 3:36 pm ((PDT))
> >>>>>>>>>
> >>>>>>>>> Hi, All
> >>>>>>>>>
> >>>>>>>>> While reading Rob Newbold's new book (which I highly
> >>>>> recommend), one
> >>>>>>>>> of
> >>>>>>>> many
> >>>>>>>>> things that intrigued me was a simple way he uses to
> >> simulate
> >>>>> variable
> >>>>>>>> task
> >>>>>>>>> performance. The method is to flip a coin multiple
> >> times. The
> >>>>> number
> >>>>>>>>> of
> >>>>>>>>> times you need to flip to get a head represents the
> >> actual days.
> >>>>>>>>>
> >>>>>>>>> He suggests using it for a simulation of five tasks in a
> >> row, or
> >>>>>>>>> parallel
> >>>>>>>>> paths. You get to decide what you want to use for the
> >>>>> estimate. It is
> >>>>>>>>> illuminating relative to sizing tasks and buffers.
> >>>>>>>>>
> >>>>>>>>> It made me wiggle about suggesting using "50% probable"
> >>>>> estimates. I
> >>>>>>>> always
> >>>>>>>>> knew that was mathematically wrong: "50% probable" is
> >> actually the
> >>>>>>>>> median,
> >>>>>>>>> and we really want the mean. Most people do not know the
> >>>>> difference,
> >>>>>>>>> and
> >>>>>>>> do
> >>>>>>>>> not have data to support anything but their multitasking
> >>>>> Pakinsonian
> >>>>>>>>> experieces. I thought it "close enough" in most cases so
> >> as to not
> >>>>>>>> terrorize
> >>>>>>>>> them with a suggestion of statistics (their eyes glaze
> >> over).
> >>>>>>>>>
> >>>>>>>>> However, this example does not seem all that unreasonable a
> >>>>>>>>> distibution,
> >>>>>>>> and
> >>>>>>>>> my first simulations caused me to realize that for an
> >> estimate of
> >>>>>>>>> one, you
> >>>>>>>>> never get a positive variation to offset a negative.
> >> Thus, you
> >>>>> over-
> >>>>>>>>> run
> >>>>>>>> too
> >>>>>>>>> frequently, even with a 50% buffer!
> >>>>>>>>>
> >>>>>>>>> He presented the numbers for the probabilty of n or
> >> less, which
> >>>>>>>>> (after a
> >>>>>>>>> little noodling) turn out to be 1-.5^n. In other words,
> >> there
> >>>>> is a 50%
> >>>>>>>>> chance of getting a one, a 75% chance of getting a two,
> >> and so on.
> >>>>>>>>>
> >>>>>>>>> So I think 1 is the median and mode for that distribution?
> >>>>>>>>>
> >>>>>>>>> My problem is: how do you calculate the mean?
> >>>>>>>>>
> >>>>>>>>> Based on simulation, I think it is 2; but I'd like to
> >> know how to
> >>>>>>>>> show it
> >>>>>>>>> mathematically. My calculus was too long ago.
> >>>>>>>>>
> >>>>>>>>> Using five tasks with the mean, if it is 2, and 50% buffer
> >>>>> (i.e. 15
> >>>>>>>>> as the
> >>>>>>>>> total "planned project duration" should do well. Anyone
> >> able to
> >>>>>>>>> model that
> >>>>>>>>> in Excel? (I am noodling it).
> >>>>>>>>>
> >>>>>>>>> I am thinking about using it in a way to help people
> >>>>> understand why
> >>>>>>>>> they
> >>>>>>>>> need to dramatically cut their task duration estimates. I
> >>>>> don't like
> >>>>>>>>> the
> >>>>>>>>> more or less arbitrary "cut in half" any more than Rob
> >> does, but
> >>>>>>>>> have come
> >>>>>>>>> back to it because I have not found a way to encourage
> >> people to
> >>>>>>>>> make that
> >>>>>>>>> large a cut. Most will go only with a 1/3 cut at most.
> >> Experience
> >>>>>>>>> shows
> >>>>>>>> that
> >>>>>>>>> is not enough, but Parkinson's law will make it seem
> >> like it was,
> >>>>>>>>> thereby
> >>>>>>>>> limiting the total gain of the implementation.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Larry Leach
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Rob Newbold [mailto:prochain@]
> >>>>>>>> Sent: Wednesday, June 17, 2009 4:52 PM
> >>>>>>>> To: 'Critical Chain Group'
> >>>>>>>> Subject: RE: A little statistical help
> >>>>>>>>
> >>>>>>>> Larry -
> >>>>>>>> Thanks for the recommendation. The coin flip is a pretty
> >> limited
> >>>>>>>> distribution, I'm not sure how far you can take it. You
> >> might also
> >>>>>>>> contact
> >>>>>>>> Dr. James Holt -- at one point he was working on a dice
> >> game that
> >>>>>>>> struck me
> >>>>>>>> as having similarities, but with a more realistic
> >> distribution. I
> >>>>>>>> don't know
> >>>>>>>> if it's something he's in a position to pass around but it
> >> wouldn't
> >>>>>>>> hurt to
> >>>>>>>> ask.
> >>>>>>>>
> >>>>>>>> Rob
> >>>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>>
> >>>>>>>> Posted by: "Lawrence" lawrence_leach@ lawrence_leach
> >>>>>>>> Date: Tue Jun 16, 2009 3:36 pm ((PDT))
> >>>>>>>>
> >>>>>>>> Hi, All
> >>>>>>>>
> >>>>>>>> While reading Rob Newbold's new book (which I highly
> >> recommend), one
> >>>>>>>> of many
> >>>>>>>> things that intrigued me was a simple way he uses to simulate
> >>>>> variable
> >>>>>>>> task
> >>>>>>>> performance. The method is to flip a coin multiple times. The
> >>>>> number of
> >>>>>>>> times you need to flip to get a head represents the actual
> >> days.
> >>>>>>>>
> >>>>>>>> He suggests using it for a simulation of five tasks in a
> >> row, or
> >>>>>>>> parallel
> >>>>>>>> paths. You get to decide what you want to use for the
> >> estimate.
> >>>>> It is
> >>>>>>>> illuminating relative to sizing tasks and buffers.
> >>>>>>>>
> >>>>>>>> It made me wiggle about suggesting using "50% probable"
> >> estimates. I
> >>>>>>>> always
> >>>>>>>> knew that was mathematically wrong: "50% probable" is
> >> actually the
> >>>>>>>> median,
> >>>>>>>> and we really want the mean. Most people do not know the
> >> difference,
> >>>>>>>> and do
> >>>>>>>> not have data to support anything but their multitasking
> >> Pakinsonian
> >>>>>>>> experieces. I thought it "close enough" in most cases so
> >> as to not
> >>>>>>>> terrorize
> >>>>>>>> them with a suggestion of statistics (their eyes glaze over).
> >>>>>>>>
> >>>>>>>> However, this example does not seem all that unreasonable a
> >>>>>>>> distibution, and
> >>>>>>>> my first simulations caused me to realize that for an
> >> estimate
> >>>>> of one,
> >>>>>>>> you
> >>>>>>>> never get a positive variation to offset a negative. Thus,
> >> you over-
> >>>>>>>> run too
> >>>>>>>> frequently, even with a 50% buffer!
> >>>>>>>>
> >>>>>>>> He presented the numbers for the probabilty of n or less,
> >> which
> >>>>> (after a
> >>>>>>>> little noodling) turn out to be 1-.5^n. In other words,
> >> there is
> >>>>> a 50%
> >>>>>>>> chance of getting a one, a 75% chance of getting a two,
> >> and so on.
> >>>>>>>>
> >>>>>>>> So I think 1 is the median and mode for that distribution?
> >>>>>>>>
> >>>>>>>> My problem is: how do you calculate the mean?
> >>>>>>>>
> >>>>>>>> Based on simulation, I think it is 2; but I'd like to know
> >> how
> >>>>> to show
> >>>>>>>> it
> >>>>>>>> mathematically. My calculus was too long ago.
> >>>>>>>>
> >>>>>>>> Using five tasks with the mean, if it is 2, and 50% buffer
> >> (i.e.
> >>>>> 15 as
> >>>>>>>> the
> >>>>>>>> total "planned project duration" should do well. Anyone
> >> able to
> >>>>> model
> >>>>>>>> that
> >>>>>>>> in Excel? (I am noodling it).
> >>>>>>>>
> >>>>>>>> I am thinking about using it in a way to help people
> >> understand
> >>>>> why they
> >>>>>>>> need to dramatically cut their task duration estimates. I
> >> don't
> >>>>> like the
> >>>>>>>> more or less arbitrary "cut in half" any more than Rob
> >> does, but
> >>>>> have
> >>>>>>>> come
> >>>>>>>> back to it because I have not found a way to encourage
> >> people to
> >>>>> make
> >>>>>>>> that
> >>>>>>>> large a cut. Most will go only with a 1/3 cut at most.
> >> Experience
> >>>>>>>> shows that
> >>>>>>>> is not enough, but Parkinson's law will make it seem like
> >> it was,
> >>>>>>>> thereby
> >>>>>>>> limiting the total gain of the implementation.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Larry Leach
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ------------------------------------
> >>>>>>>>
> >>>>>>>> To unsubscribe from this discussion, send an email to:
> >>>>>>>> CriticalChain-unsubscribe@egroups.com<CriticalChain-
> >>>>>>>> unsubscribe%40egroups.com>
> >> <mailto:CriticalChain-unsubscribe%40egroups.com<CriticalChain-
> >> unsubscribe%2540egroups.com>
> >>
> >>>>> <mailto:CriticalChain-unsubscribe%40egroups.com<CriticalChain-
> >>>>> unsubscribe%2540egroups.com>
> >>
> >>>>>>> <mailto:CriticalChain-unsubscribe%40egroups.com<CriticalChain-
> >>>>>>> unsubscribe%2540egroups.com>
> >>
> >>>>>>>> Any administrative comments or questions should be sent to:
> >>>>>>>> CriticalChain-owner@egroups.com<CriticalChain-owner
> >>>>>>>> %40egroups.com>
> >> <mailto:CriticalChain-owner%40egroups.com<CriticalChain-owner
> >> %2540egroups.com>
> >>
> >>>>> <mailto:CriticalChain-owner%40egroups.com<CriticalChain-owner
> >>>>> %2540egroups.com>
> >>
> >>>>>>> <mailto:CriticalChain-owner%40egroups.com<CriticalChain-owner
> >>>>>>> %2540egroups.com>
> >>
> >>>>>>>> Yahoo! Groups Links
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
> >
> >
> >
> > --
> > __________________________________
> > Santiago Velásquez Martínez
> >
> > "Life is a constant word problem" - Michael Owen
> >
> >
> >
> > --
> > __________________________________
> > Santiago Velásquez Martínez
> >
> > "Life is a constant word problem" - Michael Owen
> >
> >
> > [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
>