<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" 
         xmlns:thr="http://purl.org/syndication/thread/1.0" 
         xmlns:wfw="http://wellformedweb.org/CommentAPI/">
  <link rel="alternate" type="text/html" href="http://blog.jackvinson.com/archives/2004/06/07/task_slippage_isnt_the_point.html" /> 
  <link rel="self" type="application/atom+xml" href="http://blog.jackvinson.com/archives/2004/06/07/task_slippage_isnt_the_point.xml" />
  <id>tag:blog.jackvinson.com,2007://1/tag:blog.jackvinson.com,2004://1.272-</id> 
  <updated>2007-12-03T12:04:51Z</updated>
  <title>Comments for Task slippage isn&apos;t the point</title> 
  <subtitle>Jack Vinson writes about knowledge management, personal effectiveness, theory of constraints and more.  As of December 2007 Jack will likely start writing about product management too.</subtitle>
  <generator uri="http://www.sixapart.com/movabletype/">Movable Type 4.01</generator>

  <entry>
    <thr:in-reply-to ref="tag:blog.jackvinson.com,2004://1.272" type="text/html" href="http://blog.jackvinson.com/archives/2004/06/07/task_slippage_isnt_the_point.html"/>

    <id>tag:blog.jackvinson.com,2004://1.272.p84</id> 
    <link rel="alternate" type="text/html" href="http://blog.jackvinson.com/archives/2004/06/07/task_slippage_isnt_the_point.html#p84" /> 
    <title>Trackback in article Rat's head and ox's neck from ...no straight lines...</title>
    <author>
        <name>...no straight lines...</name> 
        <uri>http://nsl.blogspot.com/2004_06_01_nsl_archive.html#108683531414472849</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://nsl.blogspot.com/2004_06_01_nsl_archive.html#108683531414472849"> 
        <p>
              A recent post over at Knowledge Jolt with Jack discussed the importance of keeping your eye on the big picture and not becoming consumed with any particular task. This is a lesson that can be learned from chess as well, and was described in The Book ... <a href="http://nsl.blogspot.com/2004_06_01_nsl_archive.html#108683531414472849">[Read More]</a>
        </p>
    </content>
    <published>2004-06-10T03:15:40Z</published>
    <updated>2004-06-10T03:15:40Z</updated>


  </entry> 

  <entry>
    <thr:in-reply-to ref="tag:blog.jackvinson.com,2004://1.272" type="text/html" href="http://blog.jackvinson.com/archives/2004/06/07/task_slippage_isnt_the_point.html"/>


    <id>tag:blog.jackvinson.com,2004://1.272.1525</id> 
    <link rel="alternate" type="text/html" href="http://blog.jackvinson.com/archives/2004/06/07/task_slippage_isnt_the_point.html#comment-1525" /> 
    <title>Comment from matti salminen on 2005-09-19</title>
    <author>
        <name>matti salminen</name> 
        <uri>http://www.itensil.com</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://www.itensil.com">     
      <![CDATA[ <p>Heureka! </p>

<p>My experience is that often the key is simply in keeping the tasks flowing and making sure nobody drops the ball. </p>

<p>A due-date driven system almost guarantees that any given task will only be started at its due date, minus an optimistic minimum time that the task performer thinks it will take. There is an increasing probability of task level failure depending on both physical and logical distance from the task source.</p>

<p>To counter that I have been tinkering with a concept of "due date-less" tasks, primarily  driven by task flow and "task landing time", rather than individual due dates. </p>

<p>If you as a process owner can maintain an overall view of the status of all tasks, and if you have the means to re-direct tasks on the fly, you will have substantially improved your chances for better on-time performance.</p> ]]>
    </content>
    <published>2005-09-19T22:55:48Z</published>
    <updated>2005-09-19T22:55:48Z</updated>

  </entry> 

  <entry>
    <thr:in-reply-to ref="tag:blog.jackvinson.com,2004://1.272" type="text/html" href="http://blog.jackvinson.com/archives/2004/06/07/task_slippage_isnt_the_point.html"/>


    <id>tag:blog.jackvinson.com,2004://1.272.1551</id> 
    <link rel="alternate" type="text/html" href="http://blog.jackvinson.com/archives/2004/06/07/task_slippage_isnt_the_point.html#comment-1551" /> 
    <title>Comment from jackvinson on 2005-09-20</title>
    <author>
        <name>jackvinson</name> 
        <uri>http://blog.jackvinson.com</uri>
    </author>
    <content type="html" xml:lang="en" xml:base="http://blog.jackvinson.com">     
      <![CDATA[ <p>Isn't this great?  Your idea of "due date-less" tasks is very much in line with the Theory of Constraints idea of Critical Chain Project Management.  This is a method for managing projects where you don't ask "when will you be done," but "how much longer until you are done."  This implicitly acknowledges the fact that individual task timing estimates can never be 100% correct.  Rather than load all the uncertainty into each task, pull it out to the project as a whole.  And when you are managing the project, don't look to the individual dates but to the status of the project overall.  <br />
</p> ]]>
    </content>
    <published>2005-09-20T15:37:30Z</published>
    <updated>2005-09-20T15:37:30Z</updated>

  </entry> 

</feed>
