<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.5" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: CPM: Fool Me Once</title>
	<link>http://www.reformingprojectmanagement.com/2002/09/30/5/</link>
	<description>The magazine for the project age</description>
	<pubDate>Mon, 08 Sep 2008 00:11:16 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.5</generator>

	<item>
		<title>by: John Draper
        </title>
		<link>http://www.reformingprojectmanagement.com/2002/09/30/5/#comment-378</link>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2002/09/30/5/#comment-378</guid>
					<description>
        The essential problem with the determination of the critical path is that it is done in a deterministic manner.  Let's consider two scenarios.  In the first scenario, the planner realizes that there is variation in activity durations.  So if the same activity is repeated over and over again, there will be a range of durations rather than each instance of the activity finishing in exactly the same length of time.  The astute planner recognizes this and decides that he should use the average of this range of durations for his critical path calculation.  He follows this same reasoning and uses average durations for the remainder of the project activities.  One could then reason that calculated branch and project durations would represent the average if we repeated this project over and over again numerous times.  Following this same line of reasoning then, the calculated critical path through the network should represent the one we expect on average.  Unfortunately, the basis of this entire line or reasoning is wrong.  
Consider a golf game, but instead of best ball it is worst ball.  At each hole, the worst ball of the four players counts.  If this game were played over and over again would the average score simply be that of the worst player?  No, it would be higher than the average score of any of the players.  Why?  Because in this game, good scores on an individual’s part do not count.  Unless all four players score better than their individual averages on a hole, the overall score will continue to increase above worst score of any of the players.
In projects this same thing happens.  If a successor activity has three predecessors that must complete before it starts, only the predecessor that takes the longest time to complete counts.  It does not matter how quickly the other two completed.  If we calculated the “critical path” through the golf game by mapping out which individual player was the determinant of the score on each hole we would find that each time we played the game, we would have a different critical path.  This same phenomenon occurs on our projects.  Because durations are stochastic it is impossible before hand to determine the actual critical path of the project.  This is equivalent to the wandering bottleneck in repetitive manufacturing.  It is impossible to predict moment by moment the location of the next bottleneck.
There is one qualifier with this reasoning.  If one branch of the project contains a total duration that is much greater than those of the rest of the project, then in all likelihood, the critical path will be through this branch.  This is equivalent to the case in which one of the four golf players is much worse than the other three.  Chances are that he will be the determinant of the score on each hole.  In other words the “critical path” will be through him regardless of how many games are played.
In the second scenario, the experienced planner realizes that things usually don’t go as expected on the project.  Therefore, he adds a bit of contingency to each activity’s average duration.  The result of this is twofold:  (1) the calculated project duration will be greater than the most likely project duration if it were repeated over and over again which creates muda and (2) the calculated critical path has no relationship to reality and is totally useless for control of the project.
Bottom line:  Focusing on the calculated (read fictitious) “critical path” to the exclusion of the remainder of the project will be to the detriment of the project manager.
      </description>
		<content:encoded><![CDATA[<p>The essential problem with the determination of the critical path is that it is done in a deterministic manner.  Let&#8217;s consider two scenarios.  In the first scenario, the planner realizes that there is variation in activity durations.  So if the same activity is repeated over and over again, there will be a range of durations rather than each instance of the activity finishing in exactly the same length of time.  The astute planner recognizes this and decides that he should use the average of this range of durations for his critical path calculation.  He follows this same reasoning and uses average durations for the remainder of the project activities.  One could then reason that calculated branch and project durations would represent the average if we repeated this project over and over again numerous times.  Following this same line of reasoning then, the calculated critical path through the network should represent the one we expect on average.  Unfortunately, the basis of this entire line or reasoning is wrong.<br />
Consider a golf game, but instead of best ball it is worst ball.  At each hole, the worst ball of the four players counts.  If this game were played over and over again would the average score simply be that of the worst player?  No, it would be higher than the average score of any of the players.  Why?  Because in this game, good scores on an individual’s part do not count.  Unless all four players score better than their individual averages on a hole, the overall score will continue to increase above worst score of any of the players.<br />
In projects this same thing happens.  If a successor activity has three predecessors that must complete before it starts, only the predecessor that takes the longest time to complete counts.  It does not matter how quickly the other two completed.  If we calculated the “critical path” through the golf game by mapping out which individual player was the determinant of the score on each hole we would find that each time we played the game, we would have a different critical path.  This same phenomenon occurs on our projects.  Because durations are stochastic it is impossible before hand to determine the actual critical path of the project.  This is equivalent to the wandering bottleneck in repetitive manufacturing.  It is impossible to predict moment by moment the location of the next bottleneck.<br />
There is one qualifier with this reasoning.  If one branch of the project contains a total duration that is much greater than those of the rest of the project, then in all likelihood, the critical path will be through this branch.  This is equivalent to the case in which one of the four golf players is much worse than the other three.  Chances are that he will be the determinant of the score on each hole.  In other words the “critical path” will be through him regardless of how many games are played.<br />
In the second scenario, the experienced planner realizes that things usually don’t go as expected on the project.  Therefore, he adds a bit of contingency to each activity’s average duration.  The result of this is twofold:  (1) the calculated project duration will be greater than the most likely project duration if it were repeated over and over again which creates <acronym title="waste">muda</acronym> and (2) the calculated critical path has no relationship to reality and is totally useless for control of the project.<br />
Bottom line:  Focusing on the calculated (read fictitious) “critical path” to the exclusion of the remainder of the project will be to the detriment of the project manager.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Joe Ely
        </title>
		<link>http://www.reformingprojectmanagement.com/2002/09/30/5/#comment-379</link>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2002/09/30/5/#comment-379</guid>
					<description>
        Kudos to John for an excellent illustration of the golf game.  Thanks.

Very thoughtful response, John, thanks for posting it.

Joe
      </description>
		<content:encoded><![CDATA[<p>Kudos to John for an excellent illustration of the golf game.  Thanks.</p>
<p>Very thoughtful response, John, thanks for posting it.</p>
<p>Joe
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
