<?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: You Can&#8217;t Manage or Improve what You Don&#8217;t Understand</title>
	<link>http://www.reformingprojectmanagement.com/2007/01/31/750/</link>
	<description>The magazine for the project age</description>
	<pubDate>Fri, 16 May 2008 02:58:31 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.5</generator>

	<item>
		<title>by: Jim Kissane</title>
		<link>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12970</link>
		<pubDate>Tue, 06 Feb 2007 11:14:51 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12970</guid>
					<description>I agree with you and Greg completely.  Wile you can complete a project you don't understand, you can't learn from it, or duplicate it in the future.  Here's a thought to ponder - How do you gauge (assess) understanding?  One of the leading areas of inquiry in my Workforce Development blog (&lt;a href="http://kissaneasylum.typepad.com/workforce_development/" rel="nofollow"&gt;http://kissaneasylum.typepad.com/workforce_development/&lt;/a&gt;) has to do with assessing skills.  Is understanding a skill or a competency?  How does one assess how a person (or for that matter - an organization) comes to "understand something?</description>
		<content:encoded><![CDATA[<p>I agree with you and Greg completely.  Wile you can complete a project you don&#8217;t understand, you can&#8217;t learn from it, or duplicate it in the future.  Here&#8217;s a thought to ponder - How do you gauge (assess) understanding?  One of the leading areas of inquiry in my Workforce Development blog (<a href="http://kissaneasylum.typepad.com/workforce_development/" rel="nofollow">http://kissaneasylum.typepad.com/workforce_development/</a>) has to do with assessing skills.  Is understanding a skill or a competency?  How does one assess how a person (or for that matter - an organization) comes to &#8220;understand something?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Joe Ely</title>
		<link>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12860</link>
		<pubDate>Thu, 01 Feb 2007 21:14:39 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12860</guid>
					<description>Diana said it better than I did...let's not have metrics for metrics' sake.  

Hal, your steady encourgement for good conversations is very relevant as well.  

The metric, per se, can be akin to using a hammer instead of a wrench to tighten a bolt.  Both tools are valid, but only in the right setting.</description>
		<content:encoded><![CDATA[<p>Diana said it better than I did&#8230;let&#8217;s not have metrics for metrics&#8217; sake.  </p>
<p>Hal, your steady encourgement for good conversations is very relevant as well.  </p>
<p>The metric, per se, can be akin to using a hammer instead of a wrench to tighten a bolt.  Both tools are valid, but only in the right setting.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Diana Hutchinson</title>
		<link>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12853</link>
		<pubDate>Thu, 01 Feb 2007 15:25:22 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12853</guid>
					<description>The challenge for managers is to decide what is most important.  Metrics for metrics sake are worse than meaningless as they drive busywork.
Once we have a metric that is important, I agree it should drive another layer of investigation/discussion into what drives that metric.  If we just measure something without thinking about how we can improve that metric, we may not get to the root causes and the best possible end result.</description>
		<content:encoded><![CDATA[<p>The challenge for managers is to decide what is most important.  Metrics for metrics sake are worse than meaningless as they drive busywork.<br />
Once we have a metric that is important, I agree it should drive another layer of investigation/discussion into what drives that metric.  If we just measure something without thinking about how we can improve that metric, we may not get to the root causes and the best possible end result.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Bob Wells</title>
		<link>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12852</link>
		<pubDate>Thu, 01 Feb 2007 15:25:11 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12852</guid>
					<description>Aren't humans universally/norotiously transactional?  I think Drucker is right to imply a measurement is always going to drive behavior, and Oglesby simply adds that if the resulting behavior is going to be termed "management," then there is a prerequisite of understanding.</description>
		<content:encoded><![CDATA[<p>Aren&#8217;t humans universally/norotiously transactional?  I think Drucker is right to imply a measurement is always going to drive behavior, and Oglesby simply adds that if the resulting behavior is going to be termed &#8220;management,&#8221; then there is a prerequisite of understanding.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Hal</title>
		<link>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12851</link>
		<pubDate>Thu, 01 Feb 2007 14:54:28 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12851</guid>
					<description>I find that 'understanding' comes from conversation.  Being in conversation about measures can contribute to understanding what is going on.  Posting measures in prominent locations close to the process being measured and proximate to the people who are involved in the process can lead to further understanding.

Also, there's nothing better to avoid misunderstanding than annotating charts calling attention to special cases, changes in process, and anomalous events.</description>
		<content:encoded><![CDATA[<p>I find that &#8216;understanding&#8217; comes from conversation.  Being in conversation about measures can contribute to understanding what is going on.  Posting measures in prominent locations close to the process being measured and proximate to the people who are involved in the process can lead to further understanding.</p>
<p>Also, there&#8217;s nothing better to avoid misunderstanding than annotating charts calling attention to special cases, changes in process, and anomalous events.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jim Dallas</title>
		<link>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12845</link>
		<pubDate>Thu, 01 Feb 2007 12:50:49 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12845</guid>
					<description>Hal, after reading Critical Chain a while back I spent some time thinking about "understanding as the real project constraint", rather than time. This resonated because a lot of a PM's real fears (losing key people, stakeholder relations, changing scope, appropriate levels of documentation, having the right architect) are to do with understanding, as are many methodology discussions (pair programming, iteration lengths etc.) 

Some of the interesting areas to explore are
i) How much time to spend (over) communicating ? How/whether to verify whether communication is understood
ii) How much time to spend on-boarding people/ preparing on-boarding material
iii) What is the rhythm of understanding (e.g. daily wiki updates, weekly meetings, controlled document releases). What are the media (stories,  specs, pictures). What is the culture
iv) What is the 'cost' to the project to re-understand, or to absorb a change in understanding
v) When &#38; what should people not try to understand/ When should the whole team understand 
vi) What are the right 'chunks' to cut a project into - Who does this ? - can they be treated as black-box by the other teams ? How does a sub-team and a PM negotiate how they will be measured ?


Didn't come up with any definitive answers, but it's a fun line of enquiry and a lot of good PM practices can be linked back to an 'understanding view'

Last story - I interviewed a PM professor in the UK years ago while speccing a tool to give Sponsors detailed granular data on a project - his response was - 'the sponsors are usually accountants - if you give them detailed data about an area they don't understand, they will believe they do understand and just cause trouble'
 
Cheers
Jim
(ps  - love your work &#38; Blind Men+ the elephant)</description>
		<content:encoded><![CDATA[<p>Hal, after reading Critical Chain a while back I spent some time thinking about &#8220;understanding as the real project constraint&#8221;, rather than time. This resonated because a lot of a PM&#8217;s real fears (losing key people, stakeholder relations, changing scope, appropriate levels of documentation, having the right architect) are to do with understanding, as are many methodology discussions (pair programming, iteration lengths etc.) </p>
<p>Some of the interesting areas to explore are<br />
i) How much time to spend (over) communicating ? How/whether to verify whether communication is understood<br />
ii) How much time to spend on-boarding people/ preparing on-boarding material<br />
iii) What is the rhythm of understanding (e.g. daily wiki updates, weekly meetings, controlled document releases). What are the media (stories,  specs, pictures). What is the culture<br />
iv) What is the &#8216;cost&#8217; to the project to re-understand, or to absorb a change in understanding<br />
v) When &amp; what should people not try to understand/ When should the whole team understand<br />
vi) What are the right &#8216;chunks&#8217; to cut a project into - Who does this ? - can they be treated as black-box by the other teams ? How does a sub-team and a PM negotiate how they will be measured ?</p>
<p>Didn&#8217;t come up with any definitive answers, but it&#8217;s a fun line of enquiry and a lot of good PM practices can be linked back to an &#8216;understanding view&#8217;</p>
<p>Last story - I interviewed a PM professor in the UK years ago while speccing a tool to give Sponsors detailed granular data on a project - his response was - &#8216;the sponsors are usually accountants - if you give them detailed data about an area they don&#8217;t understand, they will believe they do understand and just cause trouble&#8217;</p>
<p>Cheers<br />
Jim<br />
(ps  - love your work &amp; Blind Men+ the elephant)
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: .Joe Ely</title>
		<link>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12842</link>
		<pubDate>Thu, 01 Feb 2007 12:05:08 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2007/01/31/750/#comment-12842</guid>
					<description>Do we combine these two concepts, Hal, by saying "Only measure that which you understand." ??  

If I understand something well (say my finished good inventory), I can measure it with confidence, knowing it shoud lead me to good actions.  

OTOH, if I don't understand something well (say a nagging yield problem) measuring it will only breed frustration;  driving understanding, rather than merely measuring it, will more likely lead to implmentable solutions. 

Good post!</description>
		<content:encoded><![CDATA[<p>Do we combine these two concepts, Hal, by saying &#8220;Only measure that which you understand.&#8221; ??  </p>
<p>If I understand something well (say my finished good inventory), I can measure it with confidence, knowing it shoud lead me to good actions.  </p>
<p>OTOH, if I don&#8217;t understand something well (say a nagging yield problem) measuring it will only breed frustration;  driving understanding, rather than merely measuring it, will more likely lead to implmentable solutions. </p>
<p>Good post!
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
