<?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: Pace Arrivals to Increase Throughput</title>
	<link>http://www.reformingprojectmanagement.com/2005/07/06/495/</link>
	<description>The magazine for the project age</description>
	<pubDate>Fri, 04 Jul 2008 13:41:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.5</generator>

	<item>
		<title>by: Alan Mossman</title>
		<link>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-1003</link>
		<pubDate>Wed, 13 Jul 2005 07:39:57 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-1003</guid>
					<description>In UK on our busiest highways (=motorways) we have variable speed limits.  as traffic density increeases the speed limit is reduced.  This allows more people to travel faster that when there is no speed limit as at lower speeds drivers are willing to drive closer to the vehicle in front (an example of buffer being directly proportional to anxiety).  With variable limits the traffic generally keeps moving at the limit.  without them traffic often comes to a complete halt.  There is a message here for flow on our construction sites and on other projects.  it does make sense to "make haste with less speed"</description>
		<content:encoded><![CDATA[<p>In UK on our busiest highways (=motorways) we have variable speed limits.  as traffic density increeases the speed limit is reduced.  This allows more people to travel faster that when there is no speed limit as at lower speeds drivers are willing to drive closer to the vehicle in front (an example of buffer being directly proportional to anxiety).  With variable limits the traffic generally keeps moving at the limit.  without them traffic often comes to a complete halt.  There is a message here for flow on our construction sites and on other projects.  it does make sense to &#8220;make haste with less speed&#8221;
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Katie</title>
		<link>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-1000</link>
		<pubDate>Thu, 07 Jul 2005 18:47:02 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-1000</guid>
					<description>YES YES ---&#62; No Gannt Chart!!  (I agree). Collaborative communications (daily conversations work real well) ensure that the missing information/spec./etc is not passed on as "waste" (or reacted upon in a counterproductive way).  </description>
		<content:encoded><![CDATA[<p>YES YES &#8212;&gt; No Gannt Chart!!  (I agree). Collaborative communications (daily conversations work real well) ensure that the missing information/spec./etc is not passed on as &#8220;waste&#8221; (or reacted upon in a counterproductive way).
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Hal</title>
		<link>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-996</link>
		<pubDate>Wed, 06 Jul 2005 16:31:32 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-996</guid>
					<description>Mark,

You don't manage it in a Gantt chart.  The most effective way I've found for doing this is by performers promising to complete something (to some level) and then having a daily conversation to report completions.  Any qualifications about maturity can be expressed at that time.  The approach works extremely well in highly specialized product design and development where one person's work releases work for others, e.g. design and engineering buildings.

Hal</description>
		<content:encoded><![CDATA[<p>Mark,</p>
<p>You don&#8217;t manage it in a Gantt chart.  The most effective way I&#8217;ve found for doing this is by performers promising to complete something (to some level) and then having a daily conversation to report completions.  Any qualifications about maturity can be expressed at that time.  The approach works extremely well in highly specialized product design and development where one person&#8217;s work releases work for others, e.g. design and engineering buildings.</p>
<p>Hal
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mark Williams</title>
		<link>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-995</link>
		<pubDate>Wed, 06 Jul 2005 14:56:40 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-995</guid>
					<description>My field is New Product Development and I believe that 'pacing' the flow work in this way can greatly increase the collaborative / iterative working needed on such projects. 

How?

Whenever a downstream task or function is ready for work, the preceeding task or function should at least deliver something - whether the information is complete or not.  It has long been my belief and experience that a drawing, a specification, or a piece of software does not need to be 100% complete for someone downstream to gain some insight relevent to their work.

This of course means that a common understanding of the maturity of that information is critical in order to avoid wasted effort. When this is in place, traditionally sequential tasks can in fact progress at a relatively even rate in parallel, albeit with a lag for the downstream task.

How you plan and manage this interaction in a Gantt chart though, has left me struggling for years!

Mark</description>
		<content:encoded><![CDATA[<p>My field is New Product Development and I believe that &#8216;pacing&#8217; the flow work in this way can greatly increase the collaborative / iterative working needed on such projects. </p>
<p>How?</p>
<p>Whenever a downstream task or function is ready for work, the preceeding task or function should at least deliver something - whether the information is complete or not.  It has long been my belief and experience that a drawing, a specification, or a piece of software does not need to be 100% complete for someone downstream to gain some insight relevent to their work.</p>
<p>This of course means that a common understanding of the maturity of that information is critical in order to avoid wasted effort. When this is in place, traditionally sequential tasks can in fact progress at a relatively even rate in parallel, albeit with a lag for the downstream task.</p>
<p>How you plan and manage this interaction in a Gantt chart though, has left me struggling for years!</p>
<p>Mark
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Kevin Rutherford</title>
		<link>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-993</link>
		<pubDate>Wed, 06 Jul 2005 13:41:37 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2005/07/06/495/#comment-993</guid>
					<description>Hal,
In agile software development, the iterations act as the traffic lights.  Only at an iteration boundary is the Customer permitted to steer the project (ie. request newfeatures, change direction etc).  Between times, new features flow undisturbed into the release.
Kevin</description>
		<content:encoded><![CDATA[<p>Hal,<br />
In agile software development, the iterations act as the traffic lights.  Only at an iteration boundary is the Customer permitted to steer the project (ie. request newfeatures, change direction etc).  Between times, new features flow undisturbed into the release.<br />
Kevin
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
