<?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: Management-as-Determining?</title>
	<link>http://www.reformingprojectmanagement.com/2002/10/30/22/</link>
	<description>The magazine for the project age</description>
	<pubDate>Fri, 04 Jul 2008 13:45:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.5</generator>

	<item>
		<title>by: Buck
        </title>
		<link>http://www.reformingprojectmanagement.com/2002/10/30/22/#comment-400</link>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2002/10/30/22/#comment-400</guid>
					<description>
        Hi,
I would just like to comment on one of your last sentences,
&gt;Better (much better) is to add detail no sooner than it is needed (acting a the last responsible moment) taking advantage of what is revealed and learned.

Sometimes, it`s hard to pinpoint the last responsible moment and sometimes you have to stake your claim early in a project otherwise you have a repeated discussion on decisions you make later in the project.

Imagine an IT project where you state that the language of choice is xyz for the apropriate reasons...
Now if you state this early in a project, all involved can get accustomed to the thought and in the end they will follow.
Now if you decide on such a vital detail in the middle of a project this decision might be exploited for various targets like e.g. an excuse why the project is late...
And you might get into repeated arguments when you least need them (in the middle of a running project)
So it`s a tough call to make this last responsible moment...
Even though I like the concept, I find it hard to implement.

Bye

Buck
      </description>
		<content:encoded><![CDATA[<p>Hi,<br />
I would just like to comment on one of your last sentences,<br />
>Better (much better) is to add detail no sooner than it is needed (acting a the last responsible moment) taking advantage of what is revealed and learned.</p>
<p>Sometimes, it`s hard to pinpoint the last responsible moment and sometimes you have to stake your claim early in a project otherwise you have a repeated discussion on decisions you make later in the project.</p>
<p>Imagine an IT project where you state that the language of choice is xyz for the apropriate reasons&#8230;<br />
Now if you state this early in a project, all involved can get accustomed to the thought and in the end they will follow.<br />
Now if you decide on such a vital detail in the middle of a project this decision might be exploited for various targets like e.g. an excuse why the project is late&#8230;<br />
And you might get into repeated arguments when you least need them (in the middle of a running project)<br />
So it`s a tough call to make this last responsible moment&#8230;<br />
Even though I like the concept, I find it hard to implement.</p>
<p>Bye</p>
<p>Buck
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mary Poppendieck
        </title>
		<link>http://www.reformingprojectmanagement.com/2002/10/30/22/#comment-401</link>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2002/10/30/22/#comment-401</guid>
					<description>
        A set-based design concept can be very useful for thinking about when to make decisions.  Delaying decisions is the equivalent of maintaining options, a very find economic approach to business.  In design, one maintains options by defining the constraints of choices, rather than making a choice and iterating on it.  As time progresses and more knowledge is gained, the constraints are narrowed.  This is the way Toyota designs cars.  Of course, a fine sense of timing is required to know when decisions have to be made, but my observation is that we have a great tendency to want to ‘lock in’ decisions as soon as possible, while the bias to make them as late as possible tends to be counter to our ‘culture’.
      </description>
		<content:encoded><![CDATA[<p>A set-based design concept can be very useful for thinking about when to make decisions.  Delaying decisions is the equivalent of maintaining options, a very find economic approach to business.  In design, one maintains options by defining the constraints of choices, rather than making a choice and iterating on it.  As time progresses and more knowledge is gained, the constraints are narrowed.  This is the way Toyota designs cars.  Of course, a fine sense of timing is required to know when decisions have to be made, but my observation is that we have a great tendency to want to ‘lock in’ decisions as soon as possible, while the bias to make them as late as possible tends to be counter to our ‘culture’.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mary Poppendieck
        </title>
		<link>http://www.reformingprojectmanagement.com/2002/10/30/22/#comment-402</link>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2002/10/30/22/#comment-402</guid>
					<description>
        I like to divide planning into two types:

1.  Plan to Learn

2. Plan to Execute

The first type of planning is good.  The second type of planning has a great tendency to make decisions before their time.  It is the failure to keep options open, even when there is little cost to doing so, that makes ‘planning to execute’ ineffective in a changing environment.
      </description>
		<content:encoded><![CDATA[<p>I like to divide planning into two types:</p>
<p>1.  Plan to Learn</p>
<p>2. Plan to Execute</p>
<p>The first type of planning is good.  The second type of planning has a great tendency to make decisions before their time.  It is the failure to keep options open, even when there is little cost to doing so, that makes ‘planning to execute’ ineffective in a changing environment.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Buck
        </title>
		<link>http://www.reformingprojectmanagement.com/2002/10/30/22/#comment-403</link>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2002/10/30/22/#comment-403</guid>
					<description>
        Hi Hal,
&gt;proneness to naivete. 
I don`t think it to naiive
only sometimes you just have to adapt to your environment and if you are in
a rough environment you have to adapt, sometimes...
I always have to take that into account when I´m writing PM Handbooks for different companies.
Depending on the whole interpersonal chemistry that is current in a company
I sometimes have to spell out every step right down to the smallest detail, including escalation chains and sometimes it`s ok to wrap it all up in 10 pages...
It´s a strange world out there ;-)

Bye

Buck

P.S. I like the anagramm, although I haven`t found the solution yet...
      </description>
		<content:encoded><![CDATA[<p>Hi Hal,<br />
>proneness to naivete.<br />
I don`t think it to naiive<br />
only sometimes you just have to adapt to your environment and if you are in<br />
a rough environment you have to adapt, sometimes&#8230;<br />
I always have to take that into account when I´m writing PM Handbooks for different companies.<br />
Depending on the whole interpersonal chemistry that is current in a company<br />
I sometimes have to spell out every step right down to the smallest detail, including escalation chains and sometimes it`s ok to wrap it all up in 10 pages&#8230;<br />
It´s a strange world out there <img src='http://www.reformingprojectmanagement.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>Bye</p>
<p>Buck</p>
<p>P.S. I like the anagramm, although I haven`t found the solution yet&#8230;
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
