<?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: AIA  &#8220;Hot Topic&#8221;: Target Value Design</title>
	<link>http://www.reformingprojectmanagement.com/2008/01/13/855/</link>
	<description>The magazine for the project age</description>
	<pubDate>Sun, 20 Jul 2008 18:40:33 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.5</generator>

	<item>
		<title>by: Glen B. Alleman</title>
		<link>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20730</link>
		<pubDate>Wed, 20 Feb 2008 15:36:28 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20730</guid>
					<description>Hal,
Other than the paired working, in aerospace and defense this is called Cost as an Idepedent Variable (CAIV). CAIV creates the "trade space" for making those decisions described in the post. More importantly CAIV allows the buyer to make those trades and understand how cost is seperated from technical performance. The notion that cost and performance as connected remains, but what are the trades between cost and performance when Cost is an Indepedent Variable.</description>
		<content:encoded><![CDATA[<p>Hal,<br />
Other than the paired working, in aerospace and defense this is called Cost as an Idepedent Variable (CAIV). CAIV creates the &#8220;trade space&#8221; for making those decisions described in the post. More importantly CAIV allows the buyer to make those trades and understand how cost is seperated from technical performance. The notion that cost and performance as connected remains, but what are the trades between cost and performance when Cost is an Indepedent Variable.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Bob Ferguson</title>
		<link>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20723</link>
		<pubDate>Fri, 08 Feb 2008 16:14:03 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20723</guid>
					<description>I was particularly struck by bullet 3 "...work together to define the issues and produce decisions then design to those decisions." which product design folks would call the "design rules". It's really difficult to get people to articulate design rules, however, the resulting products tend to have very long lives.

Kim Clark and Carliss Baldwin have some interesting stories about the success of the IBM system 360 and its design rules in their book "Design Rules".</description>
		<content:encoded><![CDATA[<p>I was particularly struck by bullet 3 &#8220;&#8230;work together to define the issues and produce decisions then design to those decisions.&#8221; which product design folks would call the &#8220;design rules&#8221;. It&#8217;s really difficult to get people to articulate design rules, however, the resulting products tend to have very long lives.</p>
<p>Kim Clark and Carliss Baldwin have some interesting stories about the success of the IBM system 360 and its design rules in their book &#8220;Design Rules&#8221;.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Bob Corrick</title>
		<link>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20717</link>
		<pubDate>Wed, 30 Jan 2008 14:03:45 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20717</guid>
					<description>Thank you for this - great reference material for software design disciplines.</description>
		<content:encoded><![CDATA[<p>Thank you for this - great reference material for software design disciplines.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Hal</title>
		<link>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20714</link>
		<pubDate>Sun, 27 Jan 2008 13:42:14 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20714</guid>
					<description>We use a number of practices to notice and share what we are learning.  Teams do frequent retrospectives.  They range from simple plus-deltas at the end of every meeting to organized facilitated retrospectives at the conclusion of design cycles.  Teams also maintain a shared space -- "not here, not now" -- for capturing topics that don't fit with the current design activity.</description>
		<content:encoded><![CDATA[<p>We use a number of practices to notice and share what we are learning.  Teams do frequent retrospectives.  They range from simple plus-deltas at the end of every meeting to organized facilitated retrospectives at the conclusion of design cycles.  Teams also maintain a shared space &#8212; &#8220;not here, not now&#8221; &#8212; for capturing topics that don&#8217;t fit with the current design activity.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Tom Cagley</title>
		<link>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20713</link>
		<pubDate>Sat, 26 Jan 2008 04:21:52 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20713</guid>
					<description>The concpets you describe seem to embrace design less as a single threaded event driven process and more as collaborative process leveraging team knowledge.  Interesting read!

How would you suggest capturing learnings generated during design that may not contribute directly to the current project/

Tom Cagley
Software Process and Measurement Cast 
www.spamcast.net</description>
		<content:encoded><![CDATA[<p>The concpets you describe seem to embrace design less as a single threaded event driven process and more as collaborative process leveraging team knowledge.  Interesting read!</p>
<p>How would you suggest capturing learnings generated during design that may not contribute directly to the current project/</p>
<p>Tom Cagley<br />
Software Process and Measurement Cast<br />
<a href="http://www.spamcast.net" rel="nofollow">www.spamcast.net</a>
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Hal</title>
		<link>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20707</link>
		<pubDate>Mon, 14 Jan 2008 16:53:50 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20707</guid>
					<description>Thanks Karen.  There's quite a bit going on with AIA and lean at this time, particularly in the realm of contracts and BIM.  I'll be writing more on it.</description>
		<content:encoded><![CDATA[<p>Thanks Karen.  There&#8217;s quite a bit going on with <acronym title="American Institute of Architects">AIA</acronym> and lean at this time, particularly in the realm of contracts and BIM.  I&#8217;ll be writing more on it.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Karen Wilhelm</title>
		<link>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20705</link>
		<pubDate>Mon, 14 Jan 2008 15:05:29 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2008/01/13/855/#comment-20705</guid>
					<description>Nice work. I'm glad AIA is tuning in to lean design concepts. It was good that AIA had a representative at last summer's lean construction meetings in Chicago. And these concepts apply to all sorts of project work. I want to remind myself to think that way.</description>
		<content:encoded><![CDATA[<p>Nice work. I&#8217;m glad <acronym title="American Institute of Architects">AIA</acronym> is tuning in to lean design concepts. It was good that <acronym title="American Institute of Architects">AIA</acronym> had a representative at last summer&#8217;s lean construction meetings in Chicago. And these concepts apply to all sorts of project work. I want to remind myself to think that way.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
