Hello all

What tool do you suggest one can use for working with people all around the
world?

Let's say you have a project in USA, delopers in India, programmers in
China, and you want them all to be updated on the project.

My first guess would be a private blog.  Does anybody have experience with
security of blogs, even if they're private?  What else do you suggest?

Bye,

--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."


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

I guess Microsoft is working on a web-based tool for collaborative planning of
software projects. For reference, see

http://research.microsoft.com/~desney/publications/MSR-TR-2005-107-JobShopTask.p\
df



Santiago Velásquez Martínez <ifsavel@...> wrote:          Hello all

What tool do you suggest one can use for working with people all around the
world?

Let's say you have a project in USA, delopers in India, programmers in
China, and you want them all to be updated on the project.

My first guess would be a private blog. Does anybody have experience with
security of blogs, even if they're private? What else do you suggest?

Bye,

--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."

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






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

Hi Santiago,

For starters I would recommend to use a bug tracking system that is on the
intranet with access available to all team members, such as Bugzilla or maybe
Trac, which has a Wiki and bug tracking system integrated.  Both are free.  I
find them to be very approporiate for delegating and tracking tasks with teams
that are globally dispersed.  Especially since the tasks can be grouped around
the project and release they are part of.

You could also go with a commercial products.  For example basecamphq.com offers
some products.  I have used them in a previous project and they are ok. 
However, I did not think that they provide anything that can't be accomplished
with open source projects coupled with email and Instant messaging programs.

Best of luck,


----- Original Message ----
From: Santiago Velásquez Martínez <ifsavel@...>
To: criticalchain@yahoogroups.com
Sent: Monday, October 1, 2007 12:28:50 PM
Subject: [CriticalChain] Collaborative Online Environments













             Hello all



What tool do you suggest one can use for working with people all around the

world?



Let's say you have a project in USA, delopers in India, programmers in

China, and you want them all to be updated on the project.



My first guess would be a private blog.  Does anybody have experience with

security of blogs, even if they're private?  What else do you suggest?



Bye,



--

____________ _________ _________ ____

Santiago Velásquez Martínez



"The important thing is not to stop questioning. "



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














<!--

#ygrp-mkp{
border:1px solid #d8d8d8;font-family:Arial;margin:14px 0px;padding:0px 14px;}
#ygrp-mkp hr{
border:1px solid #d8d8d8;}
#ygrp-mkp #hd{
color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px 0px;}
#ygrp-mkp #ads{
margin-bottom:10px;}
#ygrp-mkp .ad{
padding:0 0;}
#ygrp-mkp .ad a{
color:#0000ff;text-decoration:none;}
-->



<!--

#ygrp-sponsor #ygrp-lc{
font-family:Arial;}
#ygrp-sponsor #ygrp-lc #hd{
margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;}
#ygrp-sponsor #ygrp-lc .ad{
margin-bottom:10px;padding:0 0;}
-->



<!--

#ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean, sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean,
sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;}
#ygrp-vitnav{
padding-top:10px;font-family:Verdana;font-size:77%;margin:0;}
#ygrp-vitnav a{
padding:0 1px;}
#ygrp-actbar{
clear:both;margin:25px 0;white-space:nowrap;color:#666;text-align:right;}
#ygrp-actbar .left{
float:left;white-space:nowrap;}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;font-size:77%;padding:15px 0;}
#ygrp-ft{
font-family:verdana;font-size:77%;border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;}

#ygrp-vital{
background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;}
#ygrp-vital #vithd{
font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:upp\
ercase;}
#ygrp-vital ul{
padding:0;margin:2px 0;}
#ygrp-vital ul li{
list-style-type:none;clear:both;border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-ri\
ght:.5em;}
#ygrp-vital ul li .cat{
font-weight:bold;}
#ygrp-vital a{
text-decoration:none;}

#ygrp-vital a:hover{
text-decoration:underline;}

#ygrp-sponsor #hd{
color:#999;font-size:77%;}
#ygrp-sponsor #ov{
padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;margin:0;}
#ygrp-sponsor #ov li{
list-style-type:square;padding:6px 0;font-size:77%;}
#ygrp-sponsor #ov li a{
text-decoration:none;font-size:130%;}
#ygrp-sponsor #nc{
background-color:#eee;margin-bottom:20px;padding:0 8px;}
#ygrp-sponsor .ad{
padding:8px 0;}
#ygrp-sponsor .ad #hd1{
font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%\
;}
#ygrp-sponsor .ad a{
text-decoration:none;}
#ygrp-sponsor .ad a:hover{
text-decoration:underline;}
#ygrp-sponsor .ad p{
margin:0;}
o{font-size:0;}
.MsoNormal{
margin:0 0 0 0;}
#ygrp-text tt{
font-size:120%;}
blockquote{margin:0 0 0 4px;}
.replbq{margin:4;}
-->








      
________________________________________________________________________________\
____
Check out the hottest 2008 models today at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html

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

Actually Microsoft has already bought a collaboration tool back in 2005,
called Groove. It's creator is the same mind behind Lotus Notes, a very
popular collaboration tool in the 80's and 90's, Ray Ozzie. Groove now comes
together with some versions of MS Office.

Take a look at this:
http://en.wikipedia.org/wiki/Groove_Virtual_Office

http://office.microsoft.com/en-us/groove/default.aspx

I've used it a little bit and found it very interesting. They are pushing it
strongly to distributed Project Management, perhaps with some interaction
with Project and EPM (a.k.a Project Server).

Take a look also at xProcess: www.ivis.com . It has a web-based portion as
well.

And don't forget that Realization's Concerto is totally web-based... They
have also a workgroup version of Concerto, for small-to-medium teams.

Good hunt!

Adail Muniz Retamal
www.heptagon.com.br



On 10/1/07, Prasad Velaga <prasad_velaga2003@...> wrote:
>
>   I guess Microsoft is working on a web-based tool for collaborative
> planning of software projects. For reference, see
>
>
>
http://research.microsoft.com/~desney/publications/MSR-TR-2005-107-JobShopTask.p\
df
>
> Santiago Velásquez Martínez <ifsavel@... <ifsavel%40gmail.com>>
> wrote: Hello all
>
> What tool do you suggest one can use for working with people all around
> the
> world?
>
> Let's say you have a project in USA, delopers in India, programmers in
> China, and you want them all to be updated on the project.
>
> My first guess would be a private blog. Does anybody have experience with
> security of blogs, even if they're private? What else do you suggest?
>
> Bye,
>
> --
> __________________________________
> Santiago Velásquez Martínez
>
> "The important thing is not to stop questioning."
>
> [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]

Santiago,



There are many useful web-based and semi-web-based possibilities for you.
After looking around for months, I’ve begun using a combination of
LiveProject and BaseCamp.  LiveProject enables team use of MSProject online
without the rest of the Microsoft baggage and cost. BaseCamp is a handy
collaboration service for project documents and dialog. You can find these
online and learn more.



All the best to you,



From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Santiago Velásquez Martínez
Sent: Monday, October 01, 2007 12:29 PM
To: criticalchain@yahoogroups.com
Subject: [CriticalChain] Collaborative Online Environments



Hello all

What tool do you suggest one can use for working with people all around the
world?

Let's say you have a project in USA, delopers in India, programmers in
China, and you want them all to be updated on the project.

My first guess would be a private blog. Does anybody have experience with
security of blogs, even if they're private? What else do you suggest?

Bye,

--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."

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





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

Santiago-

Interesting question.  Not completely related to CCPM...  But this is a big
interest area for me.  It all depends on what you are really trying to do
(what limitation are your trying to overcome).

As someone else said: one could do this very simply with email.  But then
that implies MORE stuff in the inbox.

Blogs work nicely to get updates and status from people.  Private blogs are
doable, even from Google's www.Blogspot.com service.  Blogs are a nice
option, since they can be e-mailed for people who don't want to use the web
or a news reader.  But blogs aren't as useful when you want to have richer
conversations between a lot of people.  They are more news-orients, though
comments can form a small discussion.

Someone else already mentioned www.BasecampHQ.com for collaborative
projects.  I like it too.  You can track high-level deliverables and lists
tasks that need to be managed.  The disadvantage in a CCPM context is that
they don't have any dreams of doing complex project network management.
Basecamp is more helpful for managing the communications between clients and
the people running the project.  (It was created by a design firm who
recognized a need for communicating with clients.)  It incorporates blogs
and similar technologies.

If you are thinking about sharing of content (files, documents...), then
something like Groove or other offerings along those lines can work.  Wikis
are great for shared development of content.  Basecamp works here too.

There is always Realization's Concerto for managing the CCPM online, of
course.  :-)

Regards,

Jack Vinson, Ph.D.
Knowledge Jolt, Inc.
http://www.jackvinson.com
p: 847.570.0934
m: 847.212.5789




-----Original Message-----
From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Santiago Velásquez Martínez
Sent: Monday, October 01, 2007 11:29 AM
To: criticalchain@yahoogroups.com
Subject: [CriticalChain] Collaborative Online Environments

Hello all

What tool do you suggest one can use for working with people all around the
world?

Let's say you have a project in USA, delopers in India, programmers in
China, and you want them all to be updated on the project.

My first guess would be a private blog.  Does anybody have experience with
security of blogs, even if they're private?  What else do you suggest?

Bye,

--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."

Hi Santiago

Interesting question but  I'm going to answer a differet question: how do you
get one team working productively when it is spread across multiple sites and
time zones?

The trouble is ... I don't know the definitive answer, but I do know that it
takes more than technology and it needs more than just focuing on managing
tasks. It is hard. I have two projects running across multiple sites but same
timezones - one hugely success, the other one struggled. The difference?  In the
success we took the hit I downtime tob ensure that we met up with each other so
that we could see the whites of each others eyes; we broke the work down into
chunks and made sure that everyone understood what success meant for each task
(ie what tets needed to pass); we chatted several times ech week in short
conference calls; I spent a lot of time asking people what their concerns were
and then addressing them; we ate together occassionally and drank a little too.
We chatted via email and phone.

We used a bit of technology in the  not so successful project - mostly wikis -
and as many conference calls as we could bare ... But it limped along.

The difference is that in the successful project I paid a lot of attention to
getting the people to know and care about each other. In the other I didn't.

The successful project was maybe 10 times bigger than the other, btw.

If you can't meet face to face then give webcams a shot.  I've been using them
to talk to my 2 little daughters while I'm away travelling. Incredible
difference in the quality of conversation. Incredible.

Clarke
.oOo. Sent from my BlackBerry
www.ClarkeChing.com
+44(0)7920114893

-----Original Message-----
From: "Santiago Velásquez Martínez" <ifsavel@...>

Date: Mon, 1 Oct 2007 11:28:50
To:criticalchain@yahoogroups.com
Subject: [CriticalChain] Collaborative Online Environments


Hello all

What tool do you suggest one can use for working with people all around the
world?

Let's say you have a project in USA, delopers in India, programmers in
China, and you want them all to be updated on the project.

My first guess would be a private blog.  Does anybody have experience with
security of blogs, even if they're private?  What else do you suggest?

Bye,

--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."


[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

"The trouble is ... I don't know the definitive answer...."

I do.

The problem is structural.  Most companies lack a control system, and a
project manager is an inadequate substitute for one, because in all but the
rarest of cases a project manager lacks the authority with which to control
anything related to projects.  Ironic, isn't it?

The effects of the missing control system are made worse by the widespread
failure to recognize that one project within a continuous-flow
(shared-resource or matrix) system can't be controlled in the same manner as
a project that is a stand-alone system with dedicated resources.

Finally, the definitive answer is that there are two solutions available: a)
create a stand-alone system for each project and b) manage the Total
Matrix(tm) as one system, rather than continuing with the futile attempts to
manage separately the many projects that share the resources of the matrix.


Of these two possible solutions, the latter provides considerably greater
productivity, but it does so only when the matrix is controlled actively as
a single system.  This, again, requires a structural change, which some in
consulting circles still consider unnecessary.

Tony Rizzo
+1 908 322 5042 (desk)
+1 908 230 5348 (mobile)




>: -----Original Message-----
>: From: CriticalChain@yahoogroups.com
>: [mailto:CriticalChain@yahoogroups.com] On Behalf Of Clarke Ching
>: Sent: Monday, October 01, 2007 4:17 PM
>: To: CriticalChain@yahoogroups.com
>: Subject: Re: [CriticalChain] Collaborative Online Environments
>:
>: Hi Santiago
>:
>: Interesting question but  I'm going to answer a differet
>: question: how do you get one team working productively when
>: it is spread across multiple sites and time zones?
>:
>: The trouble is ... I don't know the definitive answer, but I
>: do know that it takes more than technology and it needs more
>: than just focuing on managing tasks. It is hard. I have two
>: projects running across multiple sites but same timezones -
>: one hugely success, the other one struggled. The difference?
>:  In the success we took the hit I downtime tob ensure that
>: we met up with each other so that we could see the whites of
>: each others eyes; we broke the work down into chunks and
>: made sure that everyone understood what success meant for
>: each task (ie what tets needed to pass); we chatted several
>: times ech week in short conference calls; I spent a lot of
>: time asking people what their concerns were and then
>: addressing them; we ate together occassionally and drank a
>: little too. We chatted via email and phone.
>:
>: We used a bit of technology in the  not so successful
>: project - mostly wikis - and as many conference calls as we
>: could bare ... But it limped along.
>:
>: The difference is that in the successful project I paid a
>: lot of attention to getting the people to know and care
>: about each other. In the other I didn't.
>:
>: The successful project was maybe 10 times bigger than the
>: other, btw.
>:
>: If you can't meet face to face then give webcams a shot.
>: I've been using them to talk to my 2 little daughters while
>: I'm away travelling. Incredible difference in the quality of
>: conversation. Incredible.
>:
>: Clarke
>: .oOo. Sent from my BlackBerry
>: www.ClarkeChing.com
>: +44(0)7920114893
>:
>: -----Original Message-----
>: From: "Santiago Velásquez Martínez" <ifsavel@...>
>:
>: Date: Mon, 1 Oct 2007 11:28:50
>: To:criticalchain@yahoogroups.com
>: Subject: [CriticalChain] Collaborative Online Environments
>:
>:
>: Hello all
>:
>: What tool do you suggest one can use for working with people
>: all around the
>: world?
>:
>: Let's say you have a project in USA, delopers in India,
>: programmers in
>: China, and you want them all to be updated on the project.
>:
>: My first guess would be a private blog.  Does anybody have
>: experience with
>: security of blogs, even if they're private?  What else do
>: you suggest?
>:
>: Bye,
>:
>: --
>: __________________________________
>: Santiago Velásquez Martínez
>:
>: "The important thing is not to stop questioning."
>:
>:
>: [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
>:
>:
>:
>:
>:
>: 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
>:
>:
>:
>:

Larry wrote:

"In my experience, projects do not get into trouble because they lack detail
in the network. They are instead impacted by things that the network just
doesn't contemplate (i.e. black swans); like the truck driver who drove his
truck carrying a large specialized component to the work site under a bridge
that was a mere one foot too low. This really happened to one my projects
(long ago), with a highly specialized part for a nuclear reactor. It caused
a one-year delay in the billion dollar project. No amount of detail in the
project network would have prevented it."



[REZ] This is a perfect example of a task MISSING from a plan because of
inadequate DETAIL - a grey swan. Here, a large and awkward piece of
equipment is being transported, whose arrival is critical to a project
schedule. A brief consideration of what failure modes could cause transport
to be delayed will identify a number of route-specific characteristics that
are critical. For example, any bridges that must be crossed must be able to
support the weight of the load. Any curves must allow the turning radius of
the transporter. And yes, the load must fit under anything (bridges, wires,
poles, traffic signals, etc.) that it must go under. As well as hazards
concerned with load width, weather, etc. A competent transportation company
that handles large, heavy, and awkward loads has data on such hazards, and
routing software to plan the most efficient and SAFE route. So the missing
task is "CHECK PLANNED ROUTE FOR HAZARDS" after generating a proposed route.
[And if this component is so important, you can even hire a guy and a truck,
and put weights and poles sticking out to simulate the actual load, and have
them drive the route in advance to physically test it.] This is a perfectly
foreseeable and preventable problem. Precisely why bridges have marked on
them how high they are. The problem was even preventable at the last minute
if the driver had been attentive! Hardly a black swan. merely a grey one.
[There was a great piece on "Modern Marvels" recently about a house
transporter truck with special hydraulic jack that allowed it to take routes
and maneuver around obstacles other trucks couldn't. Checking route hazards,
including parked cars, was a routine part of their process.]



Now, if we are the project manager at the site where the component is being
delivered, then of course this task isn't on our plan - it is on the plan of
the sub making (or delivering) the component. But we can certainly review
their plan, and see if as a part of their process they consider the possible
failure modes of whatever they do (in this case, delivery) and see, thanks
to the DETAIL in their plans, what they consider, and what they don't
consider (risks!). Without detail, I have no idea if they check their
routings for hazards or not. With detail, and can see what they don't
address, and discuss with them if in this case additional tasks need to be
performed, and the level of performance required.



This is basic risk planning, and also fundamental process improvement. Both
of these require a certain level of detail to provide sufficient insight to
the process of interest. If you have that level, fine. If you have less
detail than that, then you need more. [You don't have to necessarily stick
it in the project plan, but it has to be somewhere (and not just in
somebody's head).] If you have more detail than that, then someone did more
work than necessary - for this particular problem. [It may be another
problem requires the detail this one doesn't. Or it may be the detail is
just unnecessary.] After all, no one is arguing for UNNECESSARY detail,
right?



Typically when I ask for more detail in a plan or process I'm reviewing, the
reason the detail isn't there to begin with is that the person doing the
planning didn't see (or know how to use) the additional detail - so they
didn't put it in. They're not stupid. Who does extra work for no reason? The
reason I ask for it, is because I need it to see certain things they aren't
aware of, or to do certain analysis they don't know how to do. I'm not
cruel. I don't ask for detail that I don't see any possible need or use for.
So the constructive question to ask when you see detail that you don't see
(or understand) the reason for, is to ask, "Why this level of detail?" There
may be a very good reason that you just aren't aware of.



The problem here in the transportation example is not "too little detail" or
"too much detail" in a project PLAN. The problem is a weak PROCESS for
planning deliveries that failed to consider a common transportation hazard
that was very foreseeable and preventable -- if your business is
transporting large heavy things. The missing or inadequately performed
PROCESS step caused the problem. And just putting the missing task in the
project plan would not have prevented the problem, UNLESS the process as
executed carried out the inserted task, adequately. What matters is doing
the necessary steps in the process, not whether it is in the plan. If the
process is good, you don't need a lot of detail in the plan. But a bad
process needs more detail to perform like a good process! [And such
additional detail is unnecessary if we aren't trying to improve the
performance of the process. Or after we've mastered the process.]



What is "enough" detail, "too much" detail, or "inadequate" detail DEPENDS
on the project, the organization, and the circumstances. In a transportation
example, you would think that it would be unnecessary to have a step CHECK
FOR SUFFICIENT FUEL BEFORE STARTING TRIP. Who would argue that such a small,
trivial step needs to be explicitly mentioned? After all, any idiot can
simply look at the fuel gauge before starting the vehicle, and if there is
not enough, get more. There should be no reason why anyone would run out of
fuel in mid-trip, right? [Only a crazed, detail-obsessed planner would
include such things in there plan, clearly. A textbook case of "detailitis",
yes?]



And yet my first major consulting project was at the tenth largest railroad
in North America, and their #3 cause of delay for their late freight trains
was "running out of fuel" mid-trip. Not once, but many times during the
year. Upon investigation, it turned out that there were policy conflicts
that caused the problem, and part of the solution was to explicitly add the
CHECK FUEL step to their process - until it was embedded in their trip
process and the problem eliminated. [At that point there was no longer a
reason for this detail, and it could safely be removed from the process as
an explicit step - except for training new people.]



So if a load getting stuck under a bridge isn't a black swan, what would be?
Something unforeseeable, unpreventable, and catastrophic? [And thus,
unbufferable.] For a ground transportation example, a meteor striking the
transporter enroute, and damaging the component beyond field repair. A real,
similar case happened a few years ago to a Scandinavian auto company: their
two new state of the art heavy presses were coming by ship from Japan. A
freak storm at the tip of Africa sank the ship. They had waited three years
for the presses, and the lead time for new ones was five years. And yes, the
heavy presses were a constraint for their production process. They were
screwed. Even if the possibility of the ship sinking had been seriously
considered, the additional cost of sending the presses in two ships would
have ruled out serious consideration of that countermeasure. Sometimes
really bad luck happens.



So black swans happen, and if they do, tough luck. You're screwed. But for
every unforeseeable, unpreventable, and catastrophic black swan, there are
many more foreseeable, preventable, and bufferable grey swans. And risk
management is all about dealing with grey swans. For black swans, we have.
prayer?



Regards, Richard Zultner







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

http://people.howstuffworks.com/murphys-law.htm

--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."


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

Hi Larry et al



I was reminded this morning that we already had a term for unknown unknowns
– our old friend “Murphy”.



The passage below seems most relevant to Richard’s comments.



So no matter how much detail you put into your plan something will still go
wrong. So why bother and accept that fact – better to have a control
mechanism (known as buffer management) that shows up the deviation quickly
so that PMs can generate the most appropriate actions to get back on track,





by HYPERLINK "http://people.howstuffworks.com/about-author.htm#clark"Josh
Clark



Preventing Murphy's Law

While most of us appreciate Murphy's Law for its ability to explain our
sense of helplessness during certain events, others see it as a tool. At
least one person sees it as a mathematical equation that can predict the
chances of processes going awry. Joel Pel, a biological engineer at the
University of British Columbia created a formula that predicts the
occurrence of Murphy's Law.




Pm = -Km (e-I*C*U + F /Fm-1)

The formula uses a constant equal to one, a factor that is unconstant, and a
few variables. In this formula, Pel uses the importance of the event (I),
the complexity of the system involved (C), the urgency of the need for the
system to work (U) and the frequency the­ system is used (F).

In an essay he wrote for Science Creative Quarterly, Pel uses the example of
predicting the occurrence of Murphy's Law when a driver needs to drive his
Toyota Tercel a distance of about 60 miles to his home in a rainstorm
without the clutch going out. Using Murphy's Equation, Pel comes up with an
answer of 1, meaning the clutch on the Tercel will definitely go out in a
rainstorm. While anyone familiar with a Tercel might've seen that coming,
it's somehow comforting to know that it can also be predicted mathematically
[source: Science Creative Quarterly].

Murphy's Law reminds engineers, computer programmers and scientists of a
simple truth: systems fail. In some cases, a system's failure means that the
experiment must be repeated. In other cases, the results of a failure can be
much more costly.

NASA has learned this over and over again. The space agency has had numerous
failures, and although the number is proportionately small to its successes,
the failures are often very costly. Ironically, in the case of one unmanned
orbiting vessel, a set of sensors had two ways of being connected and --
just as with Murphy's original Gee Whiz test-- the sensors were all
connected incorrectly. When the sensors failed to operate the way they were
designed, the parachutes that were meant to slow the spacecraft down didn't
open, and the orbiter crashed into the desert [source: MSNBC].

It's an instance like this, in conjunction with an awareness of Murphy's Law
that has caused designers to install fail-safes. There are examples of
fail-safes all around us. Some are systems that use limited choices to
reduce errors, like the mismatched prong sizes on an electrical plug. Others
are mechanisms that prevent matters from going from bad to worse, like
lawnmowers that have levers that must be held down in order for the mower to
operate. If the person operating the mower lets go of the lever, the
lawnmower stops running.

Fail-safes are also referred to as "idiot-proof." But Murphy's Law still has
a tendency to strike, even when care has been taken to ensure against
failure or catastrophe. This leads us to the last law we'll relate to
Murphy's: Grave's Law, which states, "If you make something idiot-proof, the
world will create a better idiot."

Regards



Jim Bowles


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.13.37/1042 - Release Date: 01/10/2007
18:59



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.13.39/1045 - Release Date: 02/10/2007
18:43




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

Hi Jim,

Some of you might know Geometric distribution which represents the probability
distribution of how many times you have to toss a coin until you get head. If
the probability of getting head in a single toss is nonzero, however small it is
(like one out of a zillion), then with probability one, we get a head in a
finite number of tosses.

   Isn't this a proof of Murphy's law, "whatever can go wrong will go wrong"?


   Regards,
   Prasad


Jim Bowles <j_m-bowles@...> wrote:
   Hi Larry et al



I was reminded this morning that we already had a term for unknown unknowns
– our old friend “Murphy”.


The passage below seems most relevant to Richard’s comments.

So no matter how much detail you put into your plan something will still go
wrong. So why bother and accept that fact – better to have a control
mechanism (known as buffer management) that shows up the deviation quickly
so that PMs can generate the most appropriate actions to get back on
track,.......



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

This being what sums it all beautifully:

"If you make something idiot-proof, the
world will create a better idiot."



On 10/3/07, Jim Bowles <j_m-bowles@...> wrote:
>
> Hi Larry et al
>
>
>
> I was reminded this morning that we already had a term for unknown
> unknowns
> – our old friend "Murphy".
>
>
>
> The passage below seems most relevant to Richard's comments.
>
>
>
> So no matter how much detail you put into your plan something will still
> go
> wrong. So why bother and accept that fact – better to have a control
> mechanism (known as buffer management) that shows up the deviation quickly
> so that PMs can generate the most appropriate actions to get back on
> track,
>
>
>
>
>
> by HYPERLINK "http://people.howstuffworks.com/about-author.htm#clark"Josh
> Clark
>
>
>
> Preventing Murphy's Law
>
> While most of us appreciate Murphy's Law for its ability to explain our
> sense of helplessness during certain events, others see it as a tool. At
> least one person sees it as a mathematical equation that can predict the
> chances of processes going awry. Joel Pel, a biological engineer at the
> University of British Columbia created a formula that predicts the
> occurrence of Murphy's Law.
>
>
>
>
> Pm = -Km (e-I*C*U + F /Fm-1)
>
> The formula uses a constant equal to one, a factor that is unconstant, and
> a
> few variables. In this formula, Pel uses the importance of the event (I),
> the complexity of the system involved (C), the urgency of the need for the
> system to work (U) and the frequency the­ system is used (F).
>
> In an essay he wrote for Science Creative Quarterly, Pel uses the example
> of
> predicting the occurrence of Murphy's Law when a driver needs to drive his
> Toyota Tercel a distance of about 60 miles to his home in a rainstorm
> without the clutch going out. Using Murphy's Equation, Pel comes up with
> an
> answer of 1, meaning the clutch on the Tercel will definitely go out in a
> rainstorm. While anyone familiar with a Tercel might've seen that coming,
> it's somehow comforting to know that it can also be predicted
> mathematically
> [source: Science Creative Quarterly].
>
> Murphy's Law reminds engineers, computer programmers and scientists of a
> simple truth: systems fail. In some cases, a system's failure means that
> the
> experiment must be repeated. In other cases, the results of a failure can
> be
> much more costly.
>
> NASA has learned this over and over again. The space agency has had
> numerous
> failures, and although the number is proportionately small to its
> successes,
> the failures are often very costly. Ironically, in the case of one
> unmanned
> orbiting vessel, a set of sensors had two ways of being connected and --
> just as with Murphy's original Gee Whiz test-- the sensors were all
> connected incorrectly. When the sensors failed to operate the way they
> were
> designed, the parachutes that were meant to slow the spacecraft down
> didn't
> open, and the orbiter crashed into the desert [source: MSNBC].
>
> It's an instance like this, in conjunction with an awareness of Murphy's
> Law
> that has caused designers to install fail-safes. There are examples of
> fail-safes all around us. Some are systems that use limited choices to
> reduce errors, like the mismatched prong sizes on an electrical plug.
> Others
> are mechanisms that prevent matters from going from bad to worse, like
> lawnmowers that have levers that must be held down in order for the mower
> to
> operate. If the person operating the mower lets go of the lever, the
> lawnmower stops running.
>
> Fail-safes are also referred to as "idiot-proof." But Murphy's Law still
> has
> a tendency to strike, even when care has been taken to ensure against
> failure or catastrophe. This leads us to the last law we'll relate to
> Murphy's: Grave's Law, which states, "If you make something idiot-proof,
> the
> world will create a better idiot."
>
> Regards
>
>
>
> Jim Bowles
>
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.13.37/1042 - Release Date:
> 01/10/2007
> 18:59
>
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.488 / Virus Database: 269.13.39/1045 - Release Date:
> 02/10/2007
> 18:43
>
>
>
>
> [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
>
>
>
>


--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."


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

Richard, do you have the cloud for:

"Not once, but many times during the
year. Upon investigation, it turned out that there were policy conflicts
that caused the problem, and part of the solution was to explicitly add the
CHECK FUEL step to their process - until it was embedded in their trip
"

Thanks


On 10/2/07, Richard <Richard@...> wrote:
>
>   Larry wrote:
>
> "In my experience, projects do not get into trouble because they lack
> detail
> in the network. They are instead impacted by things that the network just
> doesn't contemplate (i.e. black swans); like the truck driver who drove
> his
> truck carrying a large specialized component to the work site under a
> bridge
> that was a mere one foot too low. This really happened to one my projects
> (long ago), with a highly specialized part for a nuclear reactor. It
> caused
> a one-year delay in the billion dollar project. No amount of detail in the
> project network would have prevented it."
>
> [REZ] This is a perfect example of a task MISSING from a plan because of
> inadequate DETAIL - a grey swan. Here, a large and awkward piece of
> equipment is being transported, whose arrival is critical to a project
> schedule. A brief consideration of what failure modes could cause
> transport
> to be delayed will identify a number of route-specific characteristics
> that
> are critical. For example, any bridges that must be crossed must be able
> to
> support the weight of the load. Any curves must allow the turning radius
> of
> the transporter. And yes, the load must fit under anything (bridges,
> wires,
> poles, traffic signals, etc.) that it must go under. As well as hazards
> concerned with load width, weather, etc. A competent transportation
> company
> that handles large, heavy, and awkward loads has data on such hazards, and
> routing software to plan the most efficient and SAFE route. So the missing
> task is "CHECK PLANNED ROUTE FOR HAZARDS" after generating a proposed
> route.
> [And if this component is so important, you can even hire a guy and a
> truck,
> and put weights and poles sticking out to simulate the actual load, and
> have
> them drive the route in advance to physically test it.] This is a
> perfectly
> foreseeable and preventable problem. Precisely why bridges have marked on
> them how high they are. The problem was even preventable at the last
> minute
> if the driver had been attentive! Hardly a black swan. merely a grey one.
> [There was a great piece on "Modern Marvels" recently about a house
> transporter truck with special hydraulic jack that allowed it to take
> routes
> and maneuver around obstacles other trucks couldn't. Checking route
> hazards,
> including parked cars, was a routine part of their process.]
>
> Now, if we are the project manager at the site where the component is
> being
> delivered, then of course this task isn't on our plan - it is on the plan
> of
> the sub making (or delivering) the component. But we can certainly review
> their plan, and see if as a part of their process they consider the
> possible
> failure modes of whatever they do (in this case, delivery) and see, thanks
> to the DETAIL in their plans, what they consider, and what they don't
> consider (risks!). Without detail, I have no idea if they check their
> routings for hazards or not. With detail, and can see what they don't
> address, and discuss with them if in this case additional tasks need to be
> performed, and the level of performance required.
>
> This is basic risk planning, and also fundamental process improvement.
> Both
> of these require a certain level of detail to provide sufficient insight
> to
> the process of interest. If you have that level, fine. If you have less
> detail than that, then you need more. [You don't have to necessarily stick
> it in the project plan, but it has to be somewhere (and not just in
> somebody's head).] If you have more detail than that, then someone did
> more
> work than necessary - for this particular problem. [It may be another
> problem requires the detail this one doesn't. Or it may be the detail is
> just unnecessary.] After all, no one is arguing for UNNECESSARY detail,
> right?
>
> Typically when I ask for more detail in a plan or process I'm reviewing,
> the
> reason the detail isn't there to begin with is that the person doing the
> planning didn't see (or know how to use) the additional detail - so they
> didn't put it in. They're not stupid. Who does extra work for no reason?
> The
> reason I ask for it, is because I need it to see certain things they
> aren't
> aware of, or to do certain analysis they don't know how to do. I'm not
> cruel. I don't ask for detail that I don't see any possible need or use
> for.
> So the constructive question to ask when you see detail that you don't see
> (or understand) the reason for, is to ask, "Why this level of detail?"
> There
> may be a very good reason that you just aren't aware of.
>
> The problem here in the transportation example is not "too little detail"
> or
> "too much detail" in a project PLAN. The problem is a weak PROCESS for
> planning deliveries that failed to consider a common transportation hazard
> that was very foreseeable and preventable -- if your business is
> transporting large heavy things. The missing or inadequately performed
> PROCESS step caused the problem. And just putting the missing task in the
> project plan would not have prevented the problem, UNLESS the process as
> executed carried out the inserted task, adequately. What matters is doing
> the necessary steps in the process, not whether it is in the plan. If the
> process is good, you don't need a lot of detail in the plan. But a bad
> process needs more detail to perform like a good process! [And such
> additional detail is unnecessary if we aren't trying to improve the
> performance of the process. Or after we've mastered the process.]
>
> What is "enough" detail, "too much" detail, or "inadequate" detail DEPENDS
> on the project, the organization, and the circumstances. In a
> transportation
> example, you would think that it would be unnecessary to have a step CHECK
> FOR SUFFICIENT FUEL BEFORE STARTING TRIP. Who would argue that such a
> small,
> trivial step needs to be explicitly mentioned? After all, any idiot can
> simply look at the fuel gauge before starting the vehicle, and if there is
> not enough, get more. There should be no reason why anyone would run out
> of
> fuel in mid-trip, right? [Only a crazed, detail-obsessed planner would
> include such things in there plan, clearly. A textbook case of
> "detailitis",
> yes?]
>
> And yet my first major consulting project was at the tenth largest
> railroad
> in North America, and their #3 cause of delay for their late freight
> trains
> was "running out of fuel" mid-trip. Not once, but many times during the
> year. Upon investigation, it turned out that there were policy conflicts
> that caused the problem, and part of the solution was to explicitly add
> the
> CHECK FUEL step to their process - until it was embedded in their trip
> process and the problem eliminated. [At that point there was no longer a
> reason for this detail, and it could safely be removed from the process as
> an explicit step - except for training new people.]
>
> So if a load getting stuck under a bridge isn't a black swan, what would
> be?
> Something unforeseeable, unpreventable, and catastrophic? [And thus,
> unbufferable.] For a ground transportation example, a meteor striking the
> transporter enroute, and damaging the component beyond field repair. A
> real,
> similar case happened a few years ago to a Scandinavian auto company:
> their
> two new state of the art heavy presses were coming by ship from Japan. A
> freak storm at the tip of Africa sank the ship. They had waited three
> years
> for the presses, and the lead time for new ones was five years. And yes,
> the
> heavy presses were a constraint for their production process. They were
> screwed. Even if the possibility of the ship sinking had been seriously
> considered, the additional cost of sending the presses in two ships would
> have ruled out serious consideration of that countermeasure. Sometimes
> really bad luck happens.
>
> So black swans happen, and if they do, tough luck. You're screwed. But for
> every unforeseeable, unpreventable, and catastrophic black swan, there are
> many more foreseeable, preventable, and bufferable grey swans. And risk
> management is all about dealing with grey swans. For black swans, we have.
> prayer?
>
> Regards, Richard Zultner
>
> [Non-text portions of this message have been removed]
>
>
>



--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."


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

The truck story is no swan, of any colour. It is "just"a special cause
uncertainty, not to be covered by CCPM methodology in itself.
I am really impressed by the size of our communications.
Edgard Calia

   ----- Original Message -----
   From: Richard
   To: CriticalChain@yahoogroups.com
   Sent: Tuesday, October 02, 2007 2:30 PM
   Subject: [CriticalChain] Re: Black Swans? No, missing detail


   Larry wrote:

   "In my experience, projects do not get into trouble because they lack detail
   in the network. They are instead impacted by things that the network just
   doesn't contemplate (i.e. black swans); like the truck driver who drove his
   truck carrying a large specialized component to the work site under a bridge
   that was a mere one foot too low. This really happened to one my projects
   (long ago), with a highly specialized part for a nuclear reactor. It caused
   a one-year delay in the billion dollar project. No amount of detail in the
   project network would have prevented it."

   [REZ] This is a perfect example of a task MISSING from a plan because of
   inadequate DETAIL - a grey swan. Here, a large and awkward piece of
   equipment is being transported, whose arrival is critical to a project
   schedule. A brief consideration of what failure modes could cause transport
   to be delayed will identify a number of route-specific characteristics that
   are critical. For example, any bridges that must be crossed must be able to
   support the weight of the load. Any curves must allow the turning radius of
   the transporter. And yes, the load must fit under anything (bridges, wires,
   poles, traffic signals, etc.) that it must go under. As well as hazards
   concerned with load width, weather, etc. A competent transportation company
   that handles large, heavy, and awkward loads has data on such hazards, and
   routing software to plan the most efficient and SAFE route. So the missing
   task is "CHECK PLANNED ROUTE FOR HAZARDS" after generating a proposed route.
   [And if this component is so important, you can even hire a guy and a truck,
   and put weights and poles sticking out to simulate the actual load, and have
   them drive the route in advance to physically test it.] This is a perfectly
   foreseeable and preventable problem. Precisely why bridges have marked on
   them how high they are. The problem was even preventable at the last minute
   if the driver had been attentive! Hardly a black swan. merely a grey one.
   [There was a great piece on "Modern Marvels" recently about a house
   transporter truck with special hydraulic jack that allowed it to take routes
   and maneuver around obstacles other trucks couldn't. Checking route hazards,
   including parked cars, was a routine part of their process.]

   Now, if we are the project manager at the site where the component is being
   delivered, then of course this task isn't on our plan - it is on the plan of
   the sub making (or delivering) the component. But we can certainly review
   their plan, and see if as a part of their process they consider the possible
   failure modes of whatever they do (in this case, delivery) and see, thanks
   to the DETAIL in their plans, what they consider, and what they don't
   consider (risks!). Without detail, I have no idea if they check their
   routings for hazards or not. With detail, and can see what they don't
   address, and discuss with them if in this case additional tasks need to be
   performed, and the level of performance required.

   This is basic risk planning, and also fundamental process improvement. Both
   of these require a certain level of detail to provide sufficient insight to
   the process of interest. If you have that level, fine. If you have less
   detail than that, then you need more. [You don't have to necessarily stick
   it in the project plan, but it has to be somewhere (and not just in
   somebody's head).] If you have more detail than that, then someone did more
   work than necessary - for this particular problem. [It may be another
   problem requires the detail this one doesn't. Or it may be the detail is
   just unnecessary.] After all, no one is arguing for UNNECESSARY detail,
   right?

   Typically when I ask for more detail in a plan or process I'm reviewing, the
   reason the detail isn't there to begin with is that the person doing the
   planning didn't see (or know how to use) the additional detail - so they
   didn't put it in. They're not stupid. Who does extra work for no reason? The
   reason I ask for it, is because I need it to see certain things they aren't
   aware of, or to do certain analysis they don't know how to do. I'm not
   cruel. I don't ask for detail that I don't see any possible need or use for.
   So the constructive question to ask when you see detail that you don't see
   (or understand) the reason for, is to ask, "Why this level of detail?" There
   may be a very good reason that you just aren't aware of.

   The problem here in the transportation example is not "too little detail" or
   "too much detail" in a project PLAN. The problem is a weak PROCESS for
   planning deliveries that failed to consider a common transportation hazard
   that was very foreseeable and preventable -- if your business is
   transporting large heavy things. The missing or inadequately performed
   PROCESS step caused the problem. And just putting the missing task in the
   project plan would not have prevented the problem, UNLESS the process as
   executed carried out the inserted task, adequately. What matters is doing
   the necessary steps in the process, not whether it is in the plan. If the
   process is good, you don't need a lot of detail in the plan. But a bad
   process needs more detail to perform like a good process! [And such
   additional detail is unnecessary if we aren't trying to improve the
   performance of the process. Or after we've mastered the process.]

   What is "enough" detail, "too much" detail, or "inadequate" detail DEPENDS
   on the project, the organization, and the circumstances. In a transportation
   example, you would think that it would be unnecessary to have a step CHECK
   FOR SUFFICIENT FUEL BEFORE STARTING TRIP. Who would argue that such a small,
   trivial step needs to be explicitly mentioned? After all, any idiot can
   simply look at the fuel gauge before starting the vehicle, and if there is
   not enough, get more. There should be no reason why anyone would run out of
   fuel in mid-trip, right? [Only a crazed, detail-obsessed planner would
   include such things in there plan, clearly. A textbook case of "detailitis",
   yes?]

   And yet my first major consulting project was at the tenth largest railroad
   in North America, and their #3 cause of delay for their late freight trains
   was "running out of fuel" mid-trip. Not once, but many times during the
   year. Upon investigation, it turned out that there were policy conflicts
   that caused the problem, and part of the solution was to explicitly add the
   CHECK FUEL step to their process - until it was embedded in their trip
   process and the problem eliminated. [At that point there was no longer a
   reason for this detail, and it could safely be removed from the process as
   an explicit step - except for training new people.]

   So if a load getting stuck under a bridge isn't a black swan, what would be?
   Something unforeseeable, unpreventable, and catastrophic? [And thus,
   unbufferable.] For a ground transportation example, a meteor striking the
   transporter enroute, and damaging the component beyond field repair. A real,
   similar case happened a few years ago to a Scandinavian auto company: their
   two new state of the art heavy presses were coming by ship from Japan. A
   freak storm at the tip of Africa sank the ship. They had waited three years
   for the presses, and the lead time for new ones was five years. And yes, the
   heavy presses were a constraint for their production process. They were
   screwed. Even if the possibility of the ship sinking had been seriously
   considered, the additional cost of sending the presses in two ships would
   have ruled out serious consideration of that countermeasure. Sometimes
   really bad luck happens.

   So black swans happen, and if they do, tough luck. You're screwed. But for
   every unforeseeable, unpreventable, and catastrophic black swan, there are
   many more foreseeable, preventable, and bufferable grey swans. And risk
   management is all about dealing with grey swans. For black swans, we have.
   prayer?

   Regards, Richard Zultner

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






------------------------------------------------------------------------------
   Esta mensagem foi verificada pelo E-mail Protegido Terra.
   Scan engine: McAfee VirusScan / Atualizado em 02/10/2007 / Versão: 5.1.00/5132
   Proteja o seu e-mail Terra: http://mail.terra.com.br/


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

Is there someone who can say what the official (and possibly
unofficial) view is from PMI regarding CCPM?
Many years ago I was able to download the PMBOK but it seems that is
not available now.

Regards
John

John,

Unfortunately PMI's view on CC is disappointing... :(

A search for "critical chain" inside the PMBOK 2004 yields these feeble
excerpts:


Chapter 6: Project Time Management
6.5 SCHEDULE DEVELOPMENT
6.5.2 Schedule Development: Tools and Techniques

.1 Schedule Network Analysis

Schedule network analysis is a technique that generates the project
schedule. It employs a schedule model and various analytical techniques,
such as critical path method, *critical chain method*, what-if analysis, and
resource leveling to calculate the early and late start and finish dates,
and scheduled start and finish dates for the uncompleted portions of project
schedule activities. If the schedule network diagram used in the model has
any network loops or network open ends, then those loops and open ends are
adjusted before one of the analytical techniques is applied. Some network
paths may have points of path convergence or path divergence that can be
identified and used in schedule compression analysis or other analyses.

.5 *Critical Chain*
*Critical chain* is another technique that modifies the project schedule to
account for limited resources. *Critical chain* mixes deterministic and
probabilistic approaches. Initially, the schedule network is built using
activity logic, required dependencies, and defined constraints as input.
Then, the critical path is calculated. After the critical path is
identified, resource availability is entered and the resource driven result
is determined.
The result often alters the critical path. *Critical chain* recognizes the
critical path as a moving target, which must be managed.
*Critical chain* adds duration buffers that are non-work activities to
maintain focus on the planned activity durations. Consequently, in lieu of
managing schedule float, *Critical Chain* focuses on managing buffer
activity durations and the resources applied to planned activities.
Optimistic estimates for the durations are used, and once the buffer
activities are determined, the planned schedule activities are scheduled to
their latest possible dates.

**

*Note:* Buffers as non-work activities? What does that mean? Also, managing
buffer activity durations? They really didn't get it...



Chapter 7: Project Cost Management
Section 7.1 Cost Estimating
.7 Reserve Analysis

[2 paragraphs skipped...]

Alternatively, the schedule activity may be a buffer activity in the *critical
chain method*, and is intentionally placed directly at the end of the
network path for that group of schedule activities. As the schedule
activities progress, the contingency reserve, as measured by resource
consumption of the non-buffer schedule activities, can be adjusted. As a
result, the activity cost variances for the related group of schedule
activities are more accurate because they are based on cost estimates that
are not pessimistic.


Glossary

*Critical Chain Method
*[Technique]. A schedule network analysis technique* that modifies the
project schedule to account for limited resources. The *critical chain
method* mixes deterministic and probabilistic approaches to schedule network
analysis.

Schedule Network Analysis
[Technique]. The technique of identifying early and late start dates*, as
well as early and late finish dates*, for the uncompleted portions of
project schedule activities. See also critical path method, *critical chain
method*, what-if analysis, and resource leveling.



And that's all, folks... As you can see, PMBOK doesn't explain anything
useful... It didn't even mention the execution aspect of CC, only touching
badly the planning aspect.

Larry Leach, who is a PMP and an active PMI member, can say much more about
this ignorance on CC in PMBOK... :)

Best regards,

Adail Muniz Retamal
www.heptagon.com.br



On 10/8/07, mentornz1 <mentor@...> wrote:
>
>   Is there someone who can say what the official (and possibly
> unofficial) view is from PMI regarding CCPM?
> Many years ago I was able to download the PMBOK but it seems that is
> not available now.
>
> Regards
> John
> .
>


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

I gave a very elementary presentation on Critical Chain in a local PMP forum and
also mentioned about the coverage of PMI on critical chain, when answering
queries.
A person who was in the audience, who is also a PMI REP,  gave some of the
points below to defend PMI's coverage. :-)
As Adail mentioned, may be Larry can say more about PMI's coverage.

Thanks and Regards
Ramanan Jagannathan
0044 (20) 754 70543

________________________________

From: CriticalChain@yahoogroups.com on behalf of Adail Retamal
Sent: Mon 08/10/2007 1:55 PM
To: CriticalChain@yahoogroups.com
Subject: Re: [CriticalChain] CCPM and PMI



John,

Unfortunately PMI's view on CC is disappointing... :(

A search for "critical chain" inside the PMBOK 2004 yields these feeble
excerpts:

Chapter 6: Project Time Management
6.5 SCHEDULE DEVELOPMENT
6.5.2 Schedule Development: Tools and Techniques

.1 Schedule Network Analysis

Schedule network analysis is a technique that generates the project
schedule. It employs a schedule model and various analytical techniques,
such as critical path method, *critical chain method*, what-if analysis, and
resource leveling to calculate the early and late start and finish dates,
and scheduled start and finish dates for the uncompleted portions of project
schedule activities. If the schedule network diagram used in the model has
any network loops or network open ends, then those loops and open ends are
adjusted before one of the analytical techniques is applied. Some network
paths may have points of path convergence or path divergence that can be
identified and used in schedule compression analysis or other analyses.

.5 *Critical Chain*
*Critical chain* is another technique that modifies the project schedule to
account for limited resources. *Critical chain* mixes deterministic and
probabilistic approaches. Initially, the schedule network is built using
activity logic, required dependencies, and defined constraints as input.
Then, the critical path is calculated. After the critical path is
identified, resource availability is entered and the resource driven result
is determined.
The result often alters the critical path. *Critical chain* recognizes the
critical path as a moving target, which must be managed.
*Critical chain* adds duration buffers that are non-work activities to
maintain focus on the planned activity durations. Consequently, in lieu of
managing schedule float, *Critical Chain* focuses on managing buffer
activity durations and the resources applied to planned activities.
Optimistic estimates for the durations are used, and once the buffer
activities are determined, the planned schedule activities are scheduled to
their latest possible dates.

**

*Note:* Buffers as non-work activities? What does that mean? Also, managing
buffer activity durations? They really didn't get it...

Chapter 7: Project Cost Management
Section 7.1 Cost Estimating
.7 Reserve Analysis

[2 paragraphs skipped...]

Alternatively, the schedule activity may be a buffer activity in the *critical
chain method*, and is intentionally placed directly at the end of the
network path for that group of schedule activities. As the schedule
activities progress, the contingency reserve, as measured by resource
consumption of the non-buffer schedule activities, can be adjusted. As a
result, the activity cost variances for the related group of schedule
activities are more accurate because they are based on cost estimates that
are not pessimistic.

Glossary

*Critical Chain Method
*[Technique]. A schedule network analysis technique* that modifies the
project schedule to account for limited resources. The *critical chain
method* mixes deterministic and probabilistic approaches to schedule network
analysis.

Schedule Network Analysis
[Technique]. The technique of identifying early and late start dates*, as
well as early and late finish dates*, for the uncompleted portions of
project schedule activities. See also critical path method, *critical chain
method*, what-if analysis, and resource leveling.

And that's all, folks... As you can see, PMBOK doesn't explain anything
useful... It didn't even mention the execution aspect of CC, only touching
badly the planning aspect.

Larry Leach, who is a PMP and an active PMI member, can say much more about
this ignorance on CC in PMBOK... :)

Best regards,

Adail Muniz Retamal
www.heptagon.com.br

On 10/8/07, mentornz1 <mentor@... <mailto:mentor%40clear.net.nz> >
wrote:
>
> Is there someone who can say what the official (and possibly
> unofficial) view is from PMI regarding CCPM?
> Many years ago I was able to download the PMBOK but it seems that is
> not available now.
>
> Regards
> John
> .
>

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






DISCLAIMER:
This message contains privileged and confidential information and is intended
only for an individual named. If you are not the intended recipient, you should
not disseminate, distribute, store, print, copy or deliver this message. Please
notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete or contain viruses. The
sender, therefore,  does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission. If
verification is required, please request a hard-copy version.


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

Could it be that this is compounded by some confused messages from the CCPM
community?

I went to a presentation on CCPM sponsored by my local PMI chapter and here
are some of the points I retained.

The theory of constraints propounds that there you should be able to
identify one major constraint that is affecting the performance of a system.
This has been applied to project management and has led to CCPM.

Yes, but CCPM seems to address more than just one constraint - to wit:
1 ensure that resource dependencies are included in the schedule
2 take "tight" time estimates (50% confidence level)
3 remove individual completion date accountability
4 share time reserves per separate chain (feeding buffers, project buffer)
5 schedule activities as late as reasonable (by taking the buffers into
account)
6 prioritize the chains based on buffer utilization
7 demonize task switching
8 avoid use of earned value
9 change the management culture
10 ... it was not clear whether the presenter understood the difference
between "common"and "special" causes of variation and so could not explain
how the buffers should (or should not) cater for them

a major issue he could not answer was how to apply the concepts in an
environment where most of the work packages are let out to subcontractors

Now: point 1 is part of the PMI recommendations as well so is not a major
differentiator. Points 2, 3, 4, 5, 6 and probably 9 can be combined. 7 is a
separate (and very valid) point. 8 seemed to use the argument that since the
tool can be misused or lead to perverse behaviours, it should be rejected;
this argument can be applied to every tool I know!

So, maybe PMI is not the only party at fault and CCPM needs to present a
clear, concise, unambiguous message: no hype, just a factual description.

Two-way communication is usually the best way to resolve misunderstandings
so what has CCPM got to offer?

Kik


Crispin (Kik) Piney
kik@...

tel: +33 (0)680 11 57 77
Please note: new number - fax: +33 (0)825 23 62 31

-----Original Message-----
From: CriticalChain@yahoogroups.com [mailto:CriticalChain@yahoogroups.com]
On Behalf Of Ramanan.Jagannathan@...
Sent: Monday, October 08, 2007 15:36
To: CriticalChain@yahoogroups.com
Subject: RE: [CriticalChain] CCPM and PMI



I gave a very elementary presentation on Critical Chain in a local PMP forum
and also mentioned about the coverage of PMI on critical chain, when
answering queries.
A person who was in the audience, who is also a PMI REP, gave some of the
points below to defend PMI's coverage. :-)
As Adail mentioned, may be Larry can say more about PMI's coverage.

Thanks and Regards
Ramanan Jagannathan
0044 (20) 754 70543

________________________________

From: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com>
yahoogroups.com on behalf of Adail Retamal
Sent: Mon 08/10/2007 1:55 PM
To: CriticalChain@ <mailto:CriticalChain%40yahoogroups.com> yahoogroups.com
Subject: Re: [CriticalChain] CCPM and PMI

John,

Unfortunately PMI's view on CC is disappointing... :(

A search for "critical chain" inside the PMBOK 2004 yields these feeble
excerpts:

Chapter 6: Project Time Management
6.5 SCHEDULE DEVELOPMENT
6.5.2 Schedule Development: Tools and Techniques

.1 Schedule Network Analysis

Schedule network analysis is a technique that generates the project
schedule. It employs a schedule model and various analytical techniques,
such as critical path method, *critical chain method*, what-if analysis, and
resource leveling to calculate the early and late start and finish dates,
and scheduled start and finish dates for the uncompleted portions of project
schedule activities. If the schedule network diagram used in the model has
any network loops or network open ends, then those loops and open ends are
adjusted before one of the analytical techniques is applied. Some network
paths may have points of path convergence or path divergence that can be
identified and used in schedule compression analysis or other analyses.

.5 *Critical Chain*
*Critical chain* is another technique that modifies the project schedule to
account for limited resources. *Critical chain* mixes deterministic and
probabilistic approaches. Initially, the schedule network is built using
activity logic, required dependencies, and defined constraints as input.
Then, the critical path is calculated. After the critical path is
identified, resource availability is entered and the resource driven result
is determined.
The result often alters the critical path. *Critical chain* recognizes the
critical path as a moving target, which must be managed.
*Critical chain* adds duration buffers that are non-work activities to
maintain focus on the planned activity durations. Consequently, in lieu of
managing schedule float, *Critical Chain* focuses on managing buffer
activity durations and the resources applied to planned activities.
Optimistic estimates for the durations are used, and once the buffer
activities are determined, the planned schedule activities are scheduled to
their latest possible dates.

**

*Note:* Buffers as non-work activities? What does that mean? Also, managing
buffer activity durations? They really didn't get it...

Chapter 7: Project Cost Management
Section 7.1 Cost Estimating
.7 Reserve Analysis

[2 paragraphs skipped...]

Alternatively, the schedule activity may be a buffer activity in the
*critical
chain method*, and is intentionally placed directly at the end of the
network path for that group of schedule activities. As the schedule
activities progress, the contingency reserve, as measured by resource
consumption of the non-buffer schedule activities, can be adjusted. As a
result, the activity cost variances for the related group of schedule
activities are more accurate because they are based on cost estimates that
are not pessimistic.

Glossary

*Critical Chain Method
*[Technique]. A schedule network analysis technique* that modifies the
project schedule to account for limited resources. The *critical chain
method* mixes deterministic and probabilistic approaches to schedule network
analysis.

Schedule Network Analysis
[Technique]. The technique of identifying early and late start dates*, as
well as early and late finish dates*, for the uncompleted portions of
project schedule activities. See also critical path method, *critical chain
method*, what-if analysis, and resource leveling.

And that's all, folks... As you can see, PMBOK doesn't explain anything
useful... It didn't even mention the execution aspect of CC, only touching
badly the planning aspect.

Larry Leach, who is a PMP and an active PMI member, can say much more about
this ignorance on CC in PMBOK... :)

Best regards,

Adail Muniz Retamal
www.heptagon.com.br

On 10/8/07, mentornz1 <mentor@clear. <mailto:mentor%40clear.net.nz> net.nz
<mailto:mentor%40clear.net.nz> > wrote:
>
> Is there someone who can say what the official (and possibly
> unofficial) view is from PMI regarding CCPM?
> Many years ago I was able to download the PMBOK but it seems that is
> not available now.
>
> Regards
> John
> .
>

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

DISCLAIMER:
This message contains privileged and confidential information and is
intended only for an individual named. If you are not the intended
recipient, you should not disseminate, distribute, store, print, copy or
deliver this message. Please notify the sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your
system. E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive late
or incomplete or contain viruses. The sender, therefore, does not accept
liability for any errors or omissions in the contents of this message which
arise as a result of e-mail transmission. If verification is required,
please request a hard-copy version.

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







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

Hi Adail,

Thanks for providing a few excerpts. A part of the description of
critical chain is:

"Initially, the schedule network is built using activity logic,
required dependencies, and defined constraints as input. Then, the
critical path is calculated. After the critical path is identified,
resource availability is entered and the resource driven result
is determined".

My interest is confined only to calculation of critical chain. From
this description, I get an impression that the critical path is
first calculated ignoring the resource availability. How is the
resource availability considered for calculating critical chains for
multiple projects that involve hundreds of activiites and compete
for common resources.

Regards,
Prasad


--- In CriticalChain@yahoogroups.com, "Adail Retamal"
<adail.retamal@...> wrote:
>
> John,
>
> Unfortunately PMI's view on CC is disappointing... :(
>
> A search for "critical chain" inside the PMBOK 2004 yields these
feeble
> excerpts:
>
>
> Chapter 6: Project Time Management
> 6.5 SCHEDULE DEVELOPMENT
> 6.5.2 Schedule Development: Tools and Techniques
>
> .1 Schedule Network Analysis
>
> Schedule network analysis is a technique that generates the project
> schedule. It employs a schedule model and various analytical
techniques,
> such as critical path method, *critical chain method*, what-if
analysis, and
> resource leveling to calculate the early and late start and finish
dates,
> and scheduled start and finish dates for the uncompleted portions
of project
> schedule activities. If the schedule network diagram used in the
model has
> any network loops or network open ends, then those loops and open
ends are
> adjusted before one of the analytical techniques is applied. Some
network
> paths may have points of path convergence or path divergence that
can be
> identified and used in schedule compression analysis or other
analyses.
>
> .5 *Critical Chain*
> *Critical chain* is another technique that modifies the project
schedule to
> account for limited resources. *Critical chain* mixes
deterministic and
> probabilistic approaches. Initially, the schedule network is built
using
> activity logic, required dependencies, and defined constraints as
input.
> Then, the critical path is calculated. After the critical path is
> identified, resource availability is entered and the resource
driven result
> is determined.
> The result often alters the critical path. *Critical chain*
recognizes the
> critical path as a moving target, which must be managed.
> *Critical chain* adds duration buffers that are non-work
activities to
> maintain focus on the planned activity durations. Consequently, in
lieu of
> managing schedule float, *Critical Chain* focuses on managing
buffer
> activity durations and the resources applied to planned activities.
> Optimistic estimates for the durations are used, and once the
buffer
> activities are determined, the planned schedule activities are
scheduled to
> their latest possible dates.
>
> **
>
> *Note:* Buffers as non-work activities? What does that mean? Also,
managing
> buffer activity durations? They really didn't get it...
>
>
>
> Chapter 7: Project Cost Management
> Section 7.1 Cost Estimating
> .7 Reserve Analysis
>
> [2 paragraphs skipped...]
>
> Alternatively, the schedule activity may be a buffer activity in
the *critical
> chain method*, and is intentionally placed directly at the end of
the
> network path for that group of schedule activities. As the schedule
> activities progress, the contingency reserve, as measured by
resource
> consumption of the non-buffer schedule activities, can be
adjusted. As a
> result, the activity cost variances for the related group of
schedule
> activities are more accurate because they are based on cost
estimates that
> are not pessimistic.
>
>
> Glossary
>
> *Critical Chain Method
> *[Technique]. A schedule network analysis technique* that modifies
the
> project schedule to account for limited resources. The *critical
chain
> method* mixes deterministic and probabilistic approaches to
schedule network
> analysis.
>
> Schedule Network Analysis
> [Technique]. The technique of identifying early and late start
dates*, as
> well as early and late finish dates*, for the uncompleted portions
of
> project schedule activities. See also critical path method,
*critical chain
> method*, what-if analysis, and resource leveling.
>
>
>
> And that's all, folks... As you can see, PMBOK doesn't explain
anything
> useful... It didn't even mention the execution aspect of CC, only
touching
> badly the planning aspect.
>
> Larry Leach, who is a PMP and an active PMI member, can say much
more about
> this ignorance on CC in PMBOK... :)
>
> Best regards,
>
> Adail Muniz Retamal
> www.heptagon.com.br

Hi, Adail

I sent them detail comments for the 3rd edition of the PMBOK Guide.
They rejected most of them. My comments may be the only reason they
have anything, albeit wrong. The mindset of the reviers probably made
it difficult for them to absorb my input.

The PMBOK Guide is not well structured to deal with CCPM, which is a
system of project delivery, from planning through execution and
measurement and control. They would have to deal with it in several
of the phases, and in several of the knowledge areas. They don't have
a knowledge area for human behaivor on tasks, as related to schedule
presention methods, to accomodate things like Parkinson's law and
multitasking.

PMI has a new draft scheduling practice guide. It, or couse, is
fundamentaly flawed from a perspective of an entire project delivery
system, but ought to be right on the scheduling aspects of CCPM.
You'll find six hits in it for critical chain, the second of which
is, to me, laughable. You should all review and comment on it.

Regards,
Larry Leach




--- In CriticalChain@yahoogroups.com, "Adail Retamal"
<adail.retamal@...> wrote:
>
> John,
>
> Unfortunately PMI's view on CC is disappointing... :(
>
> A search for "critical chain" inside the PMBOK 2004 yields these
feeble
> excerpts:
>
>
> Chapter 6: Project Time Management
> 6.5 SCHEDULE DEVELOPMENT
> 6.5.2 Schedule Development: Tools and Techniques
>
> .1 Schedule Network Analysis
>
> Schedule network analysis is a technique that generates the project
> schedule. It employs a schedule model and various analytical
techniques,
> such as critical path method, *critical chain method*, what-if
analysis, and
> resource leveling to calculate the early and late start and finish
dates,
> and scheduled start and finish dates for the uncompleted portions
of project
> schedule activities. If the schedule network diagram used in the
model has
> any network loops or network open ends, then those loops and open
ends are
> adjusted before one of the analytical techniques is applied. Some
network
> paths may have points of path convergence or path divergence that
can be
> identified and used in schedule compression analysis or other
analyses.
>
> .5 *Critical Chain*
> *Critical chain* is another technique that modifies the project
schedule to
> account for limited resources. *Critical chain* mixes deterministic
and
> probabilistic approaches. Initially, the schedule network is built
using
> activity logic, required dependencies, and defined constraints as
input.
> Then, the critical path is calculated. After the critical path is
> identified, resource availability is entered and the resource
driven result
> is determined.
> The result often alters the critical path. *Critical chain*
recognizes the
> critical path as a moving target, which must be managed.
> *Critical chain* adds duration buffers that are non-work activities
to
> maintain focus on the planned activity durations. Consequently, in
lieu of
> managing schedule float, *Critical Chain* focuses on managing buffer
> activity durations and the resources applied to planned activities.
> Optimistic estimates for the durations are used, and once the buffer
> activities are determined, the planned schedule activities are
scheduled to
> their latest possible dates.
>
> **
>
> *Note:* Buffers as non-work activities? What does that mean? Also,
managing
> buffer activity durations? They really didn't get it...
>
>
>
> Chapter 7: Project Cost Management
> Section 7.1 Cost Estimating
> .7 Reserve Analysis
>
> [2 paragraphs skipped...]
>
> Alternatively, the schedule activity may be a buffer activity in
the *critical
> chain method*, and is intentionally placed directly at the end of
the
> network path for that group of schedule activities. As the schedule
> activities progress, the contingency reserve, as measured by
resource
> consumption of the non-buffer schedule activities, can be adjusted.
As a
> result, the activity cost variances for the related group of
schedule
> activities are more accurate because they are based on cost
estimates that
> are not pessimistic.
>
>
> Glossary
>
> *Critical Chain Method
> *[Technique]. A schedule network analysis technique* that modifies
the
> project schedule to account for limited resources. The *critical
chain
> method* mixes deterministic and probabilistic approaches to
schedule network
> analysis.
>
> Schedule Network Analysis
> [Technique]. The technique of identifying early and late start
dates*, as
> well as early and late finish dates*, for the uncompleted portions
of
> project schedule activities. See also critical path method,
*critical chain
> method*, what-if analysis, and resource leveling.
>
>
>
> And that's all, folks... As you can see, PMBOK doesn't explain
anything
> useful... It didn't even mention the execution aspect of CC, only
touching
> badly the planning aspect.
>
> Larry Leach, who is a PMP and an active PMI member, can say much
more about
> this ignorance on CC in PMBOK... :)
>
> Best regards,
>
> Adail Muniz Retamal
> www.heptagon.com.br
>
>
>
> On 10/8/07, mentornz1 <mentor@...> wrote:
> >
> >   Is there someone who can say what the official (and possibly
> > unofficial) view is from PMI regarding CCPM?
> > Many years ago I was able to download the PMBOK but it seems that
is
> > not available now.
> >
> > Regards
> > John
> > .
> >
>
>
> [Non-text portions of this message have been removed]
>

Hi, Kik

I too have seen crappy presentations on CCPM. I have also seen worse
presentations on conventional PM at PMI conferences, so CCPM gets not
distinction there.

Of course, my books provide the clear description you ask for, in PMI
terms. ;-}

I have no problems with questions from PMI audiances, and prefer
groups of Project Management Professionals. I have talked before
thousands of PMI members, starting with my first CCPM presentation to
them at the international meeting in Long Beach in 1997, attended by
a "sell out" crowd of 220 (they had to turn people away). I taught
CCPM for PMI seminars for five years, and still do so for chapters. I
do many chapter presentations each year. I always get "best course
(or presntation) I have ever attended" comments.

I answer the EV question with "of course you can use EV with
CCPM...for cost control", and show them how, using a cost buffer. I
also demonstrate the fundamental flaws in EV for schedule control,
starting with two simple questions. (PS: The recent PMI practice
standard on EV addrsses one of these issues, the first time I have
seen it in writing.)

It takes time to turn a supertanker. PMI now has over 200,000
members. There are thousands of courses and books on conventional PM,
still discussing 40+ year old stuff no one uses or cares about. It
will take patience and persistance.

Regards,
Larry Leach

--- In CriticalChain@yahoogroups.com, "Crispin \(\"Kik\"\) Piney"
<kik.piney@...> wrote:
>
> Could it be that this is compounded by some confused messages from
the CCPM
> community?
>
> I went to a presentation on CCPM sponsored by my local PMI chapter
and here
> are some of the points I retained.
>
> The theory of constraints propounds that there you should be able to
> identify one major constraint that is affecting the performance of
a system.
> This has been applied to project management and has led to CCPM.
>
> Yes, but CCPM seems to address more than just one constraint - to
wit:
> 1 ensure that resource dependencies are included in the schedule
> 2 take "tight" time estimates (50% confidence level)
> 3 remove individual completion date accountability
> 4 share time reserves per separate chain (feeding buffers, project
buffer)
> 5 schedule activities as late as reasonable (by taking the buffers
into
> account)
> 6 prioritize the chains based on buffer utilization
> 7 demonize task switching
> 8 avoid use of earned value
> 9 change the management culture
> 10 ... it was not clear whether the presenter understood the
difference
> between "common"and "special" causes of variation and so could not
explain
> how the buffers should (or should not) cater for them
>
> a major issue he could not answer was how to apply the concepts in
an
> environment where most of the work packages are let out to
subcontractors
>
> Now: point 1 is part of the PMI recommendations as well so is not a
major
> differentiator. Points 2, 3, 4, 5, 6 and probably 9 can be
combined. 7 is a
> separate (and very valid) point. 8 seemed to use the argument that
since the
> tool can be misused or lead to perverse behaviours, it should be
rejected;
> this argument can be applied to every tool I know!
>
> So, maybe PMI is not the only party at fault and CCPM needs to
present a
> clear, concise, unambiguous message: no hype, just a factual
description.
>
> Two-way communication is usually the best way to resolve
misunderstandings
> so what has CCPM got to offer?
>
> Kik
>
>
> Crispin (Kik) Piney
> kik@...
>
> tel: +33 (0)680 11 57 77
> Please note: new number - fax: +33 (0)825 23 62 31
>
> -----Original Message-----
> From: CriticalChain@yahoogroups.com
[mailto:CriticalChain@yahoogroups.com]
> On Behalf Of Ramanan.Jagannathan@...
> Sent: Monday, October 08, 2007 15:36
> To: CriticalChain@yahoogroups.com
> Subject: RE: [CriticalChain] CCPM and PMI
>
>

If CCPM and the PMI are philosophically divided (we proceed from
differing fundamental premises), I wonder if we should even be trying to
get CCMP included in the PMBOK.

It would be like me, as an atheist, attempting to have references to
scientific method inserted into the old testament in an attempt to
propagate rationality!

Justin

________________________________

From: CriticalChain@yahoogroups.com
[mailto:CriticalChain@yahoogroups.com] On Behalf Of Lawrence
Sent: Wednesday, 10 October 2007 1:22 AM
To: CriticalChain@yahoogroups.com
Subject: [CriticalChain] Re: CCPM and PMI



Hi, Adail

I sent them detail comments for the 3rd edition of the PMBOK Guide.
They rejected most of them. My comments may be the only reason they
have anything, albeit wrong. The mindset of the reviers probably made
it difficult for them to absorb my input.

The PMBOK Guide is not well structured to deal with CCPM, which is a
system of project delivery, from planning through execution and
measurement and control. They would have to deal with it in several
of the phases, and in several of the knowledge areas. They don't have
a knowledge area for human behaivor on tasks, as related to schedule
presention methods, to accomodate things like Parkinson's law and
multitasking.

PMI has a new draft scheduling practice guide. It, or couse, is
fundamentaly flawed from a perspective of an entire project delivery
system, but ought to be right on the scheduling aspects of CCPM.
You'll find six hits in it for critical chain, the second of which
is, to me, laughable. You should all review and comment on it.

Regards,
Larry Leach

--- In CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> , "Adail Retamal"
<adail.retamal@...> wrote:
>
> John,
>
> Unfortunately PMI's view on CC is disappointing... :(
>
> A search for "critical chain" inside the PMBOK 2004 yields these
feeble
> excerpts:
>
>
> Chapter 6: Project Time Management
> 6.5 SCHEDULE DEVELOPMENT
> 6.5.2 Schedule Development: Tools and Techniques
>
> .1 Schedule Network Analysis
>
> Schedule network analysis is a technique that generates the project
> schedule. It employs a schedule model and various analytical
techniques,
> such as critical path method, *critical chain method*, what-if
analysis, and
> resource leveling to calculate the early and late start and finish
dates,
> and scheduled start and finish dates for the uncompleted portions
of project
> schedule activities. If the schedule network diagram used in the
model has
> any network loops or network open ends, then those loops and open
ends are
> adjusted before one of the analytical techniques is applied. Some
network
> paths may have points of path convergence or path divergence that
can be
> identified and used in schedule compression analysis or other
analyses.
>
> .5 *Critical Chain*
> *Critical chain* is another technique that modifies the project
schedule to
> account for limited resources. *Critical chain* mixes deterministic
and
> probabilistic approaches. Initially, the schedule network is built
using
> activity logic, required dependencies, and defined constraints as
input.
> Then, the critical path is calculated. After the critical path is
> identified, resource availability is entered and the resource
driven result
> is determined.
> The result often alters the critical path. *Critical chain*
recognizes the
> critical path as a moving target, which must be managed.
> *Critical chain* adds duration buffers that are non-work activities
to
> maintain focus on the planned activity durations. Consequently, in
lieu of
> managing schedule float, *Critical Chain* focuses on managing buffer
> activity durations and the resources applied to planned activities.
> Optimistic estimates for the durations are used, and once the buffer
> activities are determined, the planned schedule activities are
scheduled to
> their latest possible dates.
>
> **
>
> *Note:* Buffers as non-work activities? What does that mean? Also,
managing
> buffer activity durations? They really didn't get it...
>
>
>
> Chapter 7: Project Cost Management
> Section 7.1 Cost Estimating
> .7 Reserve Analysis
>
> [2 paragraphs skipped...]
>
> Alternatively, the schedule activity may be a buffer activity in
the *critical
> chain method*, and is intentionally placed directly at the end of
the
> network path for that group of schedule activities. As the schedule
> activities progress, the contingency reserve, as measured by
resource
> consumption of the non-buffer schedule activities, can be adjusted.
As a
> result, the activity cost variances for the related group of
schedule
> activities are more accurate because they are based on cost
estimates that
> are not pessimistic.
>
>
> Glossary
>
> *Critical Chain Method
> *[Technique]. A schedule network analysis technique* that modifies
the
> project schedule to account for limited resources. The *critical
chain
> method* mixes deterministic and probabilistic approaches to
schedule network
> analysis.
>
> Schedule Network Analysis
> [Technique]. The technique of identifying early and late start
dates*, as
> well as early and late finish dates*, for the uncompleted portions
of
> project schedule activities. See also critical path method,
*critical chain
> method*, what-if analysis, and resource leveling.
>
>
>
> And that's all, folks... As you can see, PMBOK doesn't explain
anything
> useful... It didn't even mention the execution aspect of CC, only
touching
> badly the planning aspect.
>
> Larry Leach, who is a PMP and an active PMI member, can say much
more about
> this ignorance on CC in PMBOK... :)
>
> Best regards,
>
> Adail Muniz Retamal
> www.heptagon.com.br
>
>
>
> On 10/8/07, mentornz1 <mentor@...> wrote:
> >
> > Is there someone who can say what the official (and possibly
> > unofficial) view is from PMI regarding CCPM?
> > Many years ago I was able to download the PMBOK but it seems that
is
> > not available now.
> >
> > Regards
> > John
> > .
> >
>
>
> [Non-text portions of this message have been removed]
>






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

Hi, Prasad

One need not calculate the critical path first for CCPM projet plans.
Thus, despite my attempts to help them get it right, the second and
third sentences you quote (and other staements in the PMBOK Guide)
are wrong.

However, I do recommend calcultating the critical path schedule, just
to help optimizing the plan. You can have resources entered when
calcuating the critical path; they do not affect the calcuation. The
critical path is the shortest schedule you will be able to achieve
with a critical chain plan (for a given network), and thus is a
measure of how much resource availability is affting your critical
chain project duration.

Multiple projects do not affect the critical chain of individual
projects. After planning each individual project, you pipeline the
project starts to "level" the overall demand only for the most used
resouce across all projects: the drum resource. Pipeling means
delaying the start of whole projects, vs. seeking to resouces level
across multiple projects. Resource leveing across multiple projects
stretches out the duration of all (or many) projects.

Pipelining requires the installation of a capacity constraint buffer;
conceptually a delay between the use of the drum resorce from one
project to the next. In all but the simplest cases, application of
the capacity constrain buffer differs from that conceptual picture,
but this may not be not a key point here.

Many people struggle with understanding "resource leveling" in the
context of understanding variation. Because all task durations are
variable, you can't "resource level". You can only apply that
deterministic method to try and ensure that there is enough overall
capacity of the duration of the projects so all resources can get
their work done. Actual task performance sequence imust be dynamic,
depending on the progress of the mutliple projects.

You might want to read one of my books to understand this.

Regards,
Larry Leach



--- In CriticalChain@yahoogroups.com, "Prasad Velaga"
<prasad_velaga2003@...> wrote:
>
>
> Hi Adail,
>
> Thanks for providing a few excerpts. A part of the description of
> critical chain is:
>
> "Initially, the schedule network is built using activity logic,
> required dependencies, and defined constraints as input. Then, the
> critical path is calculated. After the critical path is identified,
> resource availability is entered and the resource driven result
> is determined".
>
> My interest is confined only to calculation of critical chain. From
> this description, I get an impression that the critical path is
> first calculated ignoring the resource availability. How is the
> resource availability considered for calculating critical chains
for
> multiple projects that involve hundreds of activiites and compete
> for common resources.
>
> Regards,
> Prasad
>
>
> --- In CriticalChain@yahoogroups.com, "Adail Retamal"
> <adail.retamal@> wrote:
> >
> > John,
> >
> > Unfortunately PMI's view on CC is disappointing... :(
> >
> > A search for "critical chain" inside the PMBOK 2004 yields these
> feeble
> > excerpts:
> >
> >
> > Chapter 6: Project Time Management
> > 6.5 SCHEDULE DEVELOPMENT
> > 6.5.2 Schedule Development: Tools and Techniques
> >
> > .1 Schedule Network Analysis
> >
> > Schedule network analysis is a technique that generates the
project
> > schedule. It employs a schedule model and various analytical
> techniques,
> > such as critical path method, *critical chain method*, what-if
> analysis, and
> > resource leveling to calculate the early and late start and
finish
> dates,
> > and scheduled start and finish dates for the uncompleted portions
> of project
> > schedule activities. If the schedule network diagram used in the
> model has
> > any network loops or network open ends, then those loops and open
> ends are
> > adjusted before one of the analytical techniques is applied. Some
> network
> > paths may have points of path convergence or path divergence that
> can be
> > identified and used in schedule compression analysis or other
> analyses.
> >
> > .5 *Critical Chain*
> > *Critical chain* is another technique that modifies the project
> schedule to
> > account for limited resources. *Critical chain* mixes
> deterministic and
> > probabilistic approaches. Initially, the schedule network is
built
> using
> > activity logic, required dependencies, and defined constraints as
> input.
> > Then, the critical path is calculated. After the critical path is
> > identified, resource availability is entered and the resource
> driven result
> > is determined.
> > The result often alters the critical path. *Critical chain*
> recognizes the
> > critical path as a moving target, which must be managed.
> > *Critical chain* adds duration buffers that are non-work
> activities to
> > maintain focus on the planned activity durations. Consequently,
in
> lieu of
> > managing schedule float, *Critical Chain* focuses on managing
> buffer
> > activity durations and the resources applied to planned
activities.
> > Optimistic estimates for the durations are used, and once the
> buffer
> > activities are determined, the planned schedule activities are
> scheduled to
> > their latest possible dates.
> >
> > **
> >
> > *Note:* Buffers as non-work activities? What does that mean?
Also,
> managing
> > buffer activity durations? They really didn't get it...
> >
> >
> >
> > Chapter 7: Project Cost Management
> > Section 7.1 Cost Estimating
> > .7 Reserve Analysis
> >
> > [2 paragraphs skipped...]
> >
> > Alternatively, the schedule activity may be a buffer activity in
> the *critical
> > chain method*, and is intentionally placed directly at the end of
> the
> > network path for that group of schedule activities. As the
schedule
> > activities progress, the contingency reserve, as measured by
> resource
> > consumption of the non-buffer schedule activities, can be
> adjusted. As a
> > result, the activity cost variances for the related group of
> schedule
> > activities are more accurate because they are based on cost
> estimates that
> > are not pessimistic.
> >
> >
> > Glossary
> >
> > *Critical Chain Method
> > *[Technique]. A schedule network analysis technique* that
modifies
> the
> > project schedule to account for limited resources. The *critical
> chain
> > method* mixes deterministic and probabilistic approaches to
> schedule network
> > analysis.
> >
> > Schedule Network Analysis
> > [Technique]. The technique of identifying early and late start
> dates*, as
> > well as early and late finish dates*, for the uncompleted
portions
> of
> > project schedule activities. See also critical path method,
> *critical chain
> > method*, what-if analysis, and resource leveling.
> >
> >
> >
> > And that's all, folks... As you can see, PMBOK doesn't explain
> anything
> > useful... It didn't even mention the execution aspect of CC, only
> touching
> > badly the planning aspect.
> >
> > Larry Leach, who is a PMP and an active PMI member, can say much
> more about
> > this ignorance on CC in PMBOK... :)
> >
> > Best regards,
> >
> > Adail Muniz Retamal
> > www.heptagon.com.br
>

Hi, Justin

PMI and the CCPM community are completely aligned on goals.

One might consider the parallels between an organization such as PMI
and a religion, although there are significant differences. In
particular, "the book" for PMI is intended as ever-changing, as
compared to a fixed base such as the Bible, Koran, or Book of Morman.

Further, the chief dogma document for PMI is a "Guide" to the Project
Management Body of Knowledge. It does not pretend to be THE ONE AND
ONLY TRUE Body of Knowledge.

I see a larger percentage of TOC "true believers" eschew the PMI
practices than the other way around. I know of only a few who are
both certified Project Management Professionals (PMPs) and advocates
of CCPM as an improvement to certain elements of project practice and
the PMBOK Guide. I continue my ministry to convert as many PMPs as
possible.

I suspect a larger problem on the TOC side, where many think critical
chain is all you need know to succeed on projects. Critical chain is
a far cry from all you need to know to plan and excute projects.
Thats why I define CCPM as the synthesis of the PMI stuff and the
critical chain additions to it. (I also include six sigma, but that's
another story). For example, I have seen people "teaching" "CCPM"
that have no clue of what a Work Breakdown Strucutre is, or how to
manage project issues or scope changes.

The business community is, more and more, adopting the PMI approach.
Not having critical chain adopted by PMI ensures its demise. It would
be like being a Christian in a country run by the Taliban (with guns)
or Romans (with many hungry Lions).

I am actually quite encourged by progress to date with PMI adopting
CCPM. Critical chain is in most new PMI publications, and more
importantly in most new PM books. More and more Universities are
using CCPM in their PM offerings. Its prevelance and accuracy in the
PMBOK Guide will grow upwards. My ministry continues...


Regards,
Larry Leach

--- In CriticalChain@yahoogroups.com, "Justin Roff-Marsh"
<justin.roffmarsh@...> wrote:
>
> If CCPM and the PMI are philosophically divided (we proceed from
> differing fundamental premises), I wonder if we should even be
trying to
> get CCMP included in the PMBOK.
>
> It would be like me, as an atheist, attempting to have references to
> scientific method inserted into the old testament in an attempt to
> propagate rationality!
>
> Justin
>
> ________________________________
>
> From: CriticalChain@yahoogroups.com
> [mailto:CriticalChain@yahoogroups.com] On Behalf Of Lawrence
> Sent: Wednesday, 10 October 2007 1:22 AM
> To: CriticalChain@yahoogroups.com
> Subject: [CriticalChain] Re: CCPM and PMI
>
>
>
> Hi, Adail
>
> I sent them detail comments for the 3rd edition of the PMBOK Guide.
> They rejected most of them. My comments may be the only reason they
> have anything, albeit wrong. The mindset of the reviers probably
made
> it difficult for them to absorb my input.
>
> The PMBOK Guide is not well structured to deal with CCPM, which is
a
> system of project delivery, from planning through execution and
> measurement and control. They would have to deal with it in several
> of the phases, and in several of the knowledge areas. They don't
have
> a knowledge area for human behaivor on tasks, as related to
schedule
> presention methods, to accomodate things like Parkinson's law and
> multitasking.
>
> PMI has a new draft scheduling practice guide. It, or couse, is
> fundamentaly flawed from a perspective of an entire project
delivery
> system, but ought to be right on the scheduling aspects of CCPM.
> You'll find six hits in it for critical chain, the second of which
> is, to me, laughable. You should all review and comment on it.
>
> Regards,
> Larry Leach
>
> --- In CriticalChain@yahoogroups.com
> <mailto:CriticalChain%40yahoogroups.com> , "Adail Retamal"
> <adail.retamal@> wrote:
> >
> > John,
> >
> > Unfortunately PMI's view on CC is disappointing... :(
> >
> > A search for "critical chain" inside the PMBOK 2004 yields these
> feeble
> > excerpts:
> >
> >
> > Chapter 6: Project Time Management
> > 6.5 SCHEDULE DEVELOPMENT
> > 6.5.2 Schedule Development: Tools and Techniques
> >
> > .1 Schedule Network Analysis
> >
> > Schedule network analysis is a technique that generates the
project
> > schedule. It employs a schedule model and various analytical
> techniques,
> > such as critical path method, *critical chain method*, what-if
> analysis, and
> > resource leveling to calculate the early and late start and
finish
> dates,
> > and scheduled start and finish dates for the uncompleted portions
> of project
> > schedule activities. If the schedule network diagram used in the
> model has
> > any network loops or network open ends, then those loops and open
> ends are
> > adjusted before one of the analytical techniques is applied. Some
> network
> > paths may have points of path convergence or path divergence that
> can be
> > identified and used in schedule compression analysis or other
> analyses.
> >
> > .5 *Critical Chain*
> > *Critical chain* is another technique that modifies the project
> schedule to
> > account for limited resources. *Critical chain* mixes
deterministic
> and
> > probabilistic approaches. Initially, the schedule network is
built
> using
> > activity logic, required dependencies, and defined constraints as
> input.
> > Then, the critical path is calculated. After the critical path is
> > identified, resource availability is entered and the resource
> driven result
> > is determined.
> > The result often alters the critical path. *Critical chain*
> recognizes the
> > critical path as a moving target, which must be managed.
> > *Critical chain* adds duration buffers that are non-work
activities
> to
> > maintain focus on the planned activity durations. Consequently,
in
> lieu of
> > managing schedule float, *Critical Chain* focuses on managing
buffer
> > activity durations and the resources applied to planned
activities.
> > Optimistic estimates for the durations are used, and once the
buffer
> > activities are determined, the planned schedule activities are
> scheduled to
> > their latest possible dates.
> >
> > **
> >
> > *Note:* Buffers as non-work activities? What does that mean?
Also,
> managing
> > buffer activity durations? They really didn't get it...
> >
> >
> >
> > Chapter 7: Project Cost Management
> > Section 7.1 Cost Estimating
> > .7 Reserve Analysis
> >
> > [2 paragraphs skipped...]
> >
> > Alternatively, the schedule activity may be a buffer activity in
> the *critical
> > chain method*, and is intentionally placed directly at the end of
> the
> > network path for that group of schedule activities. As the
schedule
> > activities progress, the contingency reserve, as measured by
> resource
> > consumption of the non-buffer schedule activities, can be
adjusted.
> As a
> > result, the activity cost variances for the related group of
> schedule
> > activities are more accurate because they are based on cost
> estimates that
> > are not pessimistic.
> >
> >
> > Glossary
> >
> > *Critical Chain Method
> > *[Technique]. A schedule network analysis technique* that
modifies
> the
> > project schedule to account for limited resources. The *critical
> chain
> > method* mixes deterministic and probabilistic approaches to
> schedule network
> > analysis.
> >
> > Schedule Network Analysis
> > [Technique]. The technique of identifying early and late start
> dates*, as
> > well as early and late finish dates*, for the uncompleted
portions
> of
> > project schedule activities. See also critical path method,
> *critical chain
> > method*, what-if analysis, and resource leveling.
> >
> >
> >
> > And that's all, folks... As you can see, PMBOK doesn't explain
> anything
> > useful... It didn't even mention the execution aspect of CC, only
> touching
> > badly the planning aspect.
> >
> > Larry Leach, who is a PMP and an active PMI member, can say much
> more about
> > this ignorance on CC in PMBOK... :)
> >
> > Best regards,
> >
> > Adail Muniz Retamal
> > www.heptagon.com.br
> >
> >
> >
> > On 10/8/07, mentornz1 <mentor@> wrote:
> > >
> > > Is there someone who can say what the official (and possibly
> > > unofficial) view is from PMI regarding CCPM?
> > > Many years ago I was able to download the PMBOK but it seems
that
> is
> > > not available now.
> > >
> > > Regards
> > > John
> > > .
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Larry

Thank you for humouring my dumb metaphor!

I'm guessing that the PM community is similar to the accounting
community in that the academics appreciate the fundamental flaw in cost
accounting (and the significance of the system constraint), but the
practitioners soldier on undaunted.

If this is the case, and if we want to primarily influence practitioners
(not academics), I'm concerned that the integration of CCPM into the
PMBOK may create the impression that CCPM is a bolt-on extra for
traditional PM, and accordingly, result in our failing to address the
flawed (deterministic) premise.

Obviously, if this were to occur it would result in CCPM failing in its
(miss-) application.

I may, however, be wrong about practitioners' 'deterministic' premise.
I hope I am.

Justin



________________________________

From: CriticalChain@yahoogroups.com
[mailto:CriticalChain@yahoogroups.com] On Behalf Of Lawrence
Sent: Wednesday, 10 October 2007 2:19 AM
To: CriticalChain@yahoogroups.com
Subject: [CriticalChain] Re: CCPM and PMI



Hi, Justin

PMI and the CCPM community are completely aligned on goals.

One might consider the parallels between an organization such as PMI
and a religion, although there are significant differences. In
particular, "the book" for PMI is intended as ever-changing, as
compared to a fixed base such as the Bible, Koran, or Book of Morman.

Further, the chief dogma document for PMI is a "Guide" to the Project
Management Body of Knowledge. It does not pretend to be THE ONE AND
ONLY TRUE Body of Knowledge.

I see a larger percentage of TOC "true believers" eschew the PMI
practices than the other way around. I know of only a few who are
both certified Project Management Professionals (PMPs) and advocates
of CCPM as an improvement to certain elements of project practice and
the PMBOK Guide. I continue my ministry to convert as many PMPs as
possible.

I suspect a larger problem on the TOC side, where many think critical
chain is all you need know to succeed on projects. Critical chain is
a far cry from all you need to know to plan and excute projects.
Thats why I define CCPM as the synthesis of the PMI stuff and the
critical chain additions to it. (I also include six sigma, but that's
another story). For example, I have seen people "teaching" "CCPM"
that have no clue of what a Work Breakdown Strucutre is, or how to
manage project issues or scope changes.

The business community is, more and more, adopting the PMI approach.
Not having critical chain adopted by PMI ensures its demise. It would
be like being a Christian in a country run by the Taliban (with guns)
or Romans (with many hungry Lions).

I am actually quite encourged by progress to date with PMI adopting
CCPM. Critical chain is in most new PMI publications, and more
importantly in most new PM books. More and more Universities are
using CCPM in their PM offerings. Its prevelance and accuracy in the
PMBOK Guide will grow upwards. My ministry continues...

Regards,
Larry Leach

--- In CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> , "Justin Roff-Marsh"
<justin.roffmarsh@...> wrote:
>
> If CCPM and the PMI are philosophically divided (we proceed from
> differing fundamental premises), I wonder if we should even be
trying to
> get CCMP included in the PMBOK.
>
> It would be like me, as an atheist, attempting to have references to
> scientific method inserted into the old testament in an attempt to
> propagate rationality!
>
> Justin
>
> ________________________________
>
> From: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
> [mailto:CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com> ] On Behalf Of Lawrence
> Sent: Wednesday, 10 October 2007 1:22 AM
> To: CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
> Subject: [CriticalChain] Re: CCPM and PMI
>
>
>
> Hi, Adail
>
> I sent them detail comments for the 3rd edition of the PMBOK Guide.
> They rejected most of them. My comments may be the only reason they
> have anything, albeit wrong. The mindset of the reviers probably
made
> it difficult for them to absorb my input.
>
> The PMBOK Guide is not well structured to deal with CCPM, which is
a
> system of project delivery, from planning through execution and
> measurement and control. They would have to deal with it in several
> of the phases, and in several of the knowledge areas. They don't
have
> a knowledge area for human behaivor on tasks, as related to
schedule
> presention methods, to accomodate things like Parkinson's law and
> multitasking.
>
> PMI has a new draft scheduling practice guide. It, or couse, is
> fundamentaly flawed from a perspective of an entire project
delivery
> system, but ought to be right on the scheduling aspects of CCPM.
> You'll find six hits in it for critical chain, the second of which
> is, to me, laughable. You should all review and comment on it.
>
> Regards,
> Larry Leach
>
> --- In CriticalChain@yahoogroups.com
<mailto:CriticalChain%40yahoogroups.com>
> <mailto:CriticalChain%40yahoogroups.com> , "Adail Retamal"
> <adail.retamal@> wrote:
> >
> > John,
> >
> > Unfortunately PMI's view on CC is disappointing... :(
> >
> > A search for "critical chain" inside the PMBOK 2004 yields these
> feeble
> > excerpts:
> >
> >
> > Chapter 6: Project Time Management
> > 6.5 SCHEDULE DEVELOPMENT
> > 6.5.2 Schedule Development: Tools and Techniques
> >
> > .1 Schedule Network Analysis
> >
> > Schedule network analysis is a technique that generates the
project
> > schedule. It employs a schedule model and various analytical
> techniques,
> > such as critical path method, *critical chain method*, what-if
> analysis, and
> > resource leveling to calculate the early and late start and
finish
> dates,
> > and scheduled start and finish dates for the uncompleted portions
> of project
> > schedule activities. If the schedule network diagram used in the
> model has
> > any network loops or network open ends, then those loops and open
> ends are
> > adjusted before one of the analytical techniques is applied. Some
> network
> > paths may have points of path convergence or path divergence that
> can be
> > identified and used in schedule compression analysis or other
> analyses.
> >
> > .5 *Critical Chain*
> > *Critical chain* is another technique that modifies the project
> schedule to
> > account for limited resources. *Critical chain* mixes
deterministic
> and
> > probabilistic approaches. Initially, the schedule network is
built
> using
> > activity logic, required dependencies, and defined constraints as
> input.
> > Then, the critical path is calculated. After the critical path is
> > identified, resource availability is entered and the resource
> driven result
> > is determined.
> > The result often alters the critical path. *Critical chain*
> recognizes the
> > critical path as a moving target, which must be managed.
> > *Critical chain* adds duration buffers that are non-work
activities
> to
> > maintain focus on the planned activity durations. Consequently,
in
> lieu of
> > managing schedule float, *Critical Chain* focuses on managing
buffer
> > activity durations and the resources applied to planned
activities.
> > Optimistic estimates for the durations are used, and once the
buffer
> > activities are determined, the planned schedule activities are
> scheduled to
> > their latest possible dates.
> >
> > **
> >
> > *Note:* Buffers as non-work activities? What does that mean?
Also,
> managing
> > buffer activity durations? They really didn't get it...
> >
> >
> >
> > Chapter 7: Project Cost Management
> > Section 7.1 Cost Estimating
> > .7 Reserve Analysis
> >
> > [2 paragraphs skipped...]
> >
> > Alternatively, the schedule activity may be a buffer activity in
> the *critical
> > chain method*, and is intentionally placed directly at the end of
> the
> > network path for that group of schedule activities. As the
schedule
> > activities progress, the contingency reserve, as measured by
> resource
> > consumption of the non-buffer schedule activities, can be
adjusted.
> As a
> > result, the activity cost variances for the related group of
> schedule
> > activities are more accurate because they are based on cost
> estimates that
> > are not pessimistic.
> >
> >
> > Glossary
> >
> > *Critical Chain Method
> > *[Technique]. A schedule network analysis technique* that
modifies
> the
> > project schedule to account for limited resources. The *critical
> chain
> > method* mixes deterministic and probabilistic approaches to
> schedule network
> > analysis.
> >
> > Schedule Network Analysis
> > [Technique]. The technique of identifying early and late start
> dates*, as
> > well as early and late finish dates*, for the uncompleted
portions
> of
> > project schedule activities. See also critical path method,
> *critical chain
> > method*, what-if analysis, and resource leveling.
> >
> >
> >
> > And that's all, folks... As you can see, PMBOK doesn't explain
> anything
> > useful... It didn't even mention the execution aspect of CC, only
> touching
> > badly the planning aspect.
> >
> > Larry Leach, who is a PMP and an active PMI member, can say much
> more about
> > this ignorance on CC in PMBOK... :)
> >
> > Best regards,
> >
> > Adail Muniz Retamal
> > www.heptagon.com.br
> >
> >
> >
> > On 10/8/07, mentornz1 <mentor@> wrote:
> > >
> > > Is there someone who can say what the official (and possibly
> > > unofficial) view is from PMI regarding CCPM?
> > > Many years ago I was able to download the PMBOK but it seems
that
> is
> > > not available now.
> > >
> > > Regards
> > > John
> > > .
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>






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

Hi Larry,

"I answer the EV question with "of course you can use EV with
CCPM...for cost control", and show them how, using a cost buffer. I
also demonstrate the fundamental flaws in EV for schedule control,
starting with two simple questions. "

What are the two questions?

Thanks


On 10/9/07, Lawrence <lawrence_leach@...> wrote:
>
>   Hi, Kik
>
> I too have seen crappy presentations on CCPM. I have also seen worse
> presentations on conventional PM at PMI conferences, so CCPM gets not
> distinction there.
>
> Of course, my books provide the clear description you ask for, in PMI
> terms. ;-}
>
> I have no problems with questions from PMI audiances, and prefer
> groups of Project Management Professionals. I have talked before
> thousands of PMI members, starting with my first CCPM presentation to
> them at the international meeting in Long Beach in 1997, attended by
> a "sell out" crowd of 220 (they had to turn people away). I taught
> CCPM for PMI seminars for five years, and still do so for chapters. I
> do many chapter presentations each year. I always get "best course
> (or presntation) I have ever attended" comments.
>
> I answer the EV question with "of course you can use EV with
> CCPM...for cost control", and show them how, using a cost buffer. I
> also demonstrate the fundamental flaws in EV for schedule control,
> starting with two simple questions. (PS: The recent PMI practice
> standard on EV addrsses one of these issues, the first time I have
> seen it in writing.)
>
> It takes time to turn a supertanker. PMI now has over 200,000
> members. There are thousands of courses and books on conventional PM,
> still discussing 40+ year old stuff no one uses or cares about. It
> will take patience and persistance.
>
> Regards,
> Larry Leach
>
> --- In CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>,
> "Crispin \(\"Kik\"\) Piney"
> <kik.piney@...> wrote:
> >
> > Could it be that this is compounded by some confused messages from
> the CCPM
> > community?
> >
> > I went to a presentation on CCPM sponsored by my local PMI chapter
> and here
> > are some of the points I retained.
> >
> > The theory of constraints propounds that there you should be able to
> > identify one major constraint that is affecting the performance of
> a system.
> > This has been applied to project management and has led to CCPM.
> >
> > Yes, but CCPM seems to address more than just one constraint - to
> wit:
> > 1 ensure that resource dependencies are included in the schedule
> > 2 take "tight" time estimates (50% confidence level)
> > 3 remove individual completion date accountability
> > 4 share time reserves per separate chain (feeding buffers, project
> buffer)
> > 5 schedule activities as late as reasonable (by taking the buffers
> into
> > account)
> > 6 prioritize the chains based on buffer utilization
> > 7 demonize task switching
> > 8 avoid use of earned value
> > 9 change the management culture
> > 10 ... it was not clear whether the presenter understood the
> difference
> > between "common"and "special" causes of variation and so could not
> explain
> > how the buffers should (or should not) cater for them
> >
> > a major issue he could not answer was how to apply the concepts in
> an
> > environment where most of the work packages are let out to
> subcontractors
> >
> > Now: point 1 is part of the PMI recommendations as well so is not a
> major
> > differentiator. Points 2, 3, 4, 5, 6 and probably 9 can be
> combined. 7 is a
> > separate (and very valid) point. 8 seemed to use the argument that
> since the
> > tool can be misused or lead to perverse behaviours, it should be
> rejected;
> > this argument can be applied to every tool I know!
> >
> > So, maybe PMI is not the only party at fault and CCPM needs to
> present a
> > clear, concise, unambiguous message: no hype, just a factual
> description.
> >
> > Two-way communication is usually the best way to resolve
> misunderstandings
> > so what has CCPM got to offer?
> >
> > Kik
> >
> >
> > Crispin (Kik) Piney
> > kik@...
> >
> > tel: +33 (0)680 11 57 77
> > Please note: new number - fax: +33 (0)825 23 62 31
> >
> > -----Original Message-----
> > From: CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>
> [mailto:CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>]
> > On Behalf Of Ramanan.Jagannathan@...
> > Sent: Monday, October 08, 2007 15:36
> > To: CriticalChain@yahoogroups.com <CriticalChain%40yahoogroups.com>
> > Subject: RE: [CriticalChain] CCPM and PMI
> >
> >
>
>
>



--
__________________________________
Santiago Velásquez Martínez

"The important thing is not to stop questioning."


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

Colleagues,

I received an off-list communication from Robert Nazareth, a certified PMP and a
LinkedIn connection of mine. Since I'm not closely aware of goings on at Boeing,
most of what I could say would be mere (¿wild?) speculation. Further, the folks
at Boeing who REALLY know may have professional nondisclosure obligations. All
that accepted, if you care to take a cut at some of Robert's questions, I've
reproduced them below from his LinkedIn posting. He should pick up your answers
here as he's applied to the list and is probably lurking by now.


Robert Nazareth, PMP wrote off-list: Disclaimer: I am not a CCPM guru -

1. RE: Boeing 787 Delay - Aligned with Critical Chain Project
    Management (CCPM)?

2. Your thoughts (or speculation) on Boeing 787 delay?

3. Assuming they are not using CCPM, what benefits would they
    have experienced?

4. Is new product design/materials/sourcing and execution
    destined for a delay?

5. Is this typical for "bold' introductions within an industry?

6. Do we assume Business Analysis was thoughtfully used?


Now, I'll take a cut at (parts of) the questions that I can field . . .

#3:
Boeing has begun using CCPM for SOME of its commercial airline activities. I
cannot say which ones. Generally, CC/PM and CC/MPM (and their associated
operations, reporting, and recovery disciplines) will improve the LOGISTICS of a
project so that things happen much more quickly and trouble spots surface BEFORE
they cause severe damage to the total project (often with enough warning to
recover before any global adverse effects, though folks working on some tasks
may find themselves working some overtime or receiving extra support not in the
original project plan). These logistical improvements mean that more projects
finish on time, within budget, AND with full content than one might otherwise
expect. Given the lead times on very large projects like an all new commercial
airliner, the 787 program may have been well along (or even already in trouble)
before Critical Chain (even if its benefits touched this particular program)
began having significant impact on the 787 program.

#4:
I think not. CC/PM or CC/MPM can attack the logistical delays one often
experiences doing original work. The ToC Evaporating Cloud technique and more
sophisticated TRIZ methods can help attack the need to develop new approaches
that (frequently) must satisfy (apparently) contradictory requirements (e.g.,
[example 1: strong AND light AND inexpensive] or [example 2: small AND high
capacity]).

#5:
Unfortunately, accumulated case histories seem to suggest that this is still too
often true. Some folks prefer the devil they know to the angel they've not yet
met. Consider the cloud below:

       D:  Do not switch to CC/PM or CC/MPM methods.

    B: Use known methods the project team already understand.

A: Manage the project successfully.

    C: Use methods with a proven record for delivering full
       content on time within budget.

       D': Switch to CC/PM or CC/MPM methods.

How well does that cloud capture the conflict project managers, resource
managers, project management system executives face. From experience they know
that A-B-D will often (¿usually?) mean that projects are some combination of
late, over budget, and lacking full content. On the other hand, they've not yet
tried A-C-D' so they REALLY (deep in their hearts of hearts) do not know WHAT
will happen if they try it. Unfortunately, they CANNOT do both because D and D'
are mutually exclusive. Since most organizations punish failure more severely
when one has tried something new to the firm. A-C-D' is the low risk path for
the firm but the HIGH RISK path for the individual. On the other hand, A-B-D is
the high risk path for the firm but the LOW RISK path for the individual who
will probably NOT be severely punished for using company approved "standard"
methods even if the project fails catastrophically. From a personal stand point,
the choice is clear: failing the way we always fail!
  ed in the past (and maybe getting lucky) is PERSONALLY FAR SAFER than being the
one to introduce a new thing without certainty that it will work perfectly the
first time off the blocks.

:-)

Brian Potter
Leadership Effectiveness Consultant
Membership Vice President, The Strategy Forum

voice:  248/661-2556 (home)
         248/890-7540 (message)
e-mail: jmbpotter<at>sbcglobal<dot>net

           About me: http://www.linkedin.com/in/jmbpotter
The Strategy Forum: http://www.TheStrategyForum.org

Defects are not free. Somebody makes them, and gets paid for making them.
- W. Edwards Deming, _Out of the Crisis,_ p11

Deming addressed the tip of the iceberg. For the rest of the story, contact
Brian.

Hi Brian



I liked your thoughtful posting:



But I think your final comments suggest a deeper cloud – maybe as follows:



D: Use proven methods – (Do not switch to CC/PM or CC/MPM methods.)

B: Protect those responsible for delivery

A: Deliver the project OTIF. (On time in full)

C: Improve the project delivery system


D': Switch to CC/PM or CC/MPM methods



Jim Bowles







#4:
I think not. CC/PM or CC/MPM can attack the logistical delays one often
experiences doing original work. The ToC Evaporating Cloud technique and
more sophisticated TRIZ methods can help attack the need to develop new
approaches that (frequently) must satisfy (apparently) contradictory
requirements (e.g., [example 1: strong AND light AND inexpensive] or
[example 2: small AND high capacity]).

#5:
Unfortunately, accumulated case histories seem to suggest that this is still
too often true. Some folks prefer the devil they know to the angel they've
not yet met. Consider the cloud below:

D: Do not switch to CC/PM or CC/MPM methods.

B: Use known methods the project team already understand.

A: Manage the project successfully.

C: Use methods with a proven record for delivering full
content on time within budget.

D': Switch to CC/PM or CC/MPM methods.

How well does that cloud capture the conflict project managers, resource
managers, project management system executives face. From experience they
know that A-B-D will often (¿usually?) mean that projects are some
combination of late, over budget, and lacking full content. On the other
hand, they've not yet tried A-C-D' so they REALLY (deep in their hearts of
hearts) do not know WHAT will happen if they try it. Unfortunately, they
CANNOT do both because D and D' are mutually exclusive. Since most
organizations punish failure more severely when one has tried something new
to the firm. A-C-D' is the low risk path for the firm but the HIGH RISK path
for the individual. On the other hand, A-B-D is the high risk path for the
firm but the LOW RISK path for the individual who will probably NOT be
severely punished for using company approved "standard" methods even if the
project fails catastrophically. From a personal stand point, the choice is
clear: failing the way we always fail!
ed in the past (and maybe getting lucky) is PERSONALLY FAR SAFER than being
the one to introduce a new thing without certainty that it will work
perfectly the first time off the blocks.

:-)

Brian Potter
Leadership Effectiveness Consultant
Membership Vice President, The Strategy Forum







No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.7/1062 - Release Date: 10/10/2007
17:11



No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.14.7/1062 - Release Date: 10/10/2007
17:11



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

Brian,

When I heard the news yesterday about Boeing's delay I commented with my
wife: they use CCPM...

Then the reporter said that there was some problems with the suppliers not
keeping up with the pace of Boeing...

Perhaps the lack of a "global CCPM deployment" in most/all the participants
of the 787 program could be one of the causes for this delay?

Just thinking out loud... ;)

Adail


On 10/11/07, Brian Potter <jmbpotter@...> wrote:
>
>   Colleagues,
>
> I received an off-list communication from Robert Nazareth, a certified PMP
> and a LinkedIn connection of mine. Since I'm not closely aware of goings on
> at Boeing, most of what I could say would be mere (¿wild?) speculation.
> Further, the folks at Boeing who REALLY know may have professional
> nondisclosure obligations. All that accepted, if you care to take a cut at
> some of Robert's questions, I've reproduced them below from his LinkedIn
> posting. He should pick up your answers here as he's applied to the list and
> is probably lurking by now.
>
> Robert Nazareth, PMP wrote off-list: Disclaimer: I am not a CCPM guru -
>
> 1. RE: Boeing 787 Delay - Aligned with Critical Chain Project
> Management (CCPM)?
>
> 2. Your thoughts (or speculation) on Boeing 787 delay?
>
> 3. Assuming they are not using CCPM, what benefits would they
> have experienced?
>
> 4. Is new product design/materials/sourcing and execution
> destined for a delay?
>
> 5. Is this typical for "bold' introductions within an industry?
>
> 6. Do we assume Business Analysis was thoughtfully used?
>
> Now, I'll take a cut at (parts of) the questions that I can field . . .
>
> #3:
> Boeing has begun using CCPM for SOME of its commercial airline activities.
> I cannot say which ones. Generally, CC/PM and CC/MPM (and their associated
> operations, reporting, and recovery disciplines) will improve the LOGISTICS
> of a project so that things happen much more quickly and trouble spots
> surface BEFORE they cause severe damage to the total project (often with
> enough warning to recover before any global adverse effects, though folks
> working on some tasks may find themselves working some overtime or receiving
> extra support not in the original project plan). These logistical
> improvements mean that more projects finish on time, within budget, AND with
> full content than one might otherwise expect. Given the lead times on very
> large projects like an all new commercial airliner, the 787 program may have
> been well along (or even already in trouble) before Critical Chain (even if
> its benefits touched this particular program) began having significant
> impact on the 787 program.
>
> #4:
> I think not. CC/PM or CC/MPM can attack the logistical delays one often
> experiences doing original work. The ToC Evaporating Cloud technique and
> more sophisticated TRIZ methods can help attack the need to develop new
> approaches that (frequently) must satisfy (apparently) contradictory
> requirements (e.g., [example 1: strong AND light AND inexpensive] or
> [example 2: small AND high capacity]).
>
> #5:
> Unfortunately, accumulated case histories seem to suggest that this is
> still too often true. Some folks prefer the devil they know to the angel
> they've not yet met. Consider the cloud below:
>
> D: Do not switch to CC/PM or CC/MPM methods.
>
> B: Use known methods the project team already understand.
>
> A: Manage the project successfully.
>
> C: Use methods with a proven record for delivering full
> content on time within budget.
>
> D': Switch to CC/PM or CC/MPM methods.
>
> How well does that cloud capture the conflict project managers, resource
> managers, project management system executives face. From experience they
> know that A-B-D will often (¿usually?) mean that projects are some
> combination of late, over budget, and lacking full content. On the other
> hand, they've not yet tried A-C-D' so they REALLY (deep in their hearts of
> hearts) do not know WHAT will happen if they try it. Unfortunately, they
> CANNOT do both because D and D' are mutually exclusive. Since most
> organizations punish failure more severely when one has tried something new
> to the firm. A-C-D' is the low risk path for the firm but the HIGH RISK path
> for the individual. On the other hand, A-B-D is the high risk path for the
> firm but the LOW RISK path for the individual who will probably NOT be
> severely punished for using company approved "standard" methods even if the
> project fails catastrophically. From a personal stand point, the choice is
> clear: failing the way we always fail!
> ed in the past (and maybe getting lucky) is PERSONALLY FAR SAFER than
> being the one to introduce a new thing without certainty that it will work
> perfectly the first time off the blocks.
>
> :-)
>
> Brian Potter
> Leadership Effectiveness Consultant
> Membership Vice President, The Strategy Forum
> .
>


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