<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Multiply by Pi</title>
	<atom:link href="http://strom.wordpress.com/2008/03/26/multiply-by-pi/feed/" rel="self" type="application/rss+xml" />
	<link>http://strom.wordpress.com/2008/03/26/multiply-by-pi/</link>
	<description>New and improved with just a hint of lemon</description>
	<lastBuildDate>Mon, 28 Dec 2009 20:05:05 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Bob Denny</title>
		<link>http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71579</link>
		<dc:creator>Bob Denny</dc:creator>
		<pubDate>Thu, 27 Mar 2008 17:34:41 +0000</pubDate>
		<guid isPermaLink="false">http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71579</guid>
		<description>I just saw &lt;a href=&quot;http://www.codinghorror.com/blog/archives/001083.html&quot; rel=&quot;nofollow&quot;&gt;this article by Jeff Atwood&lt;/a&gt;. For my part the biggest work-inflator is &quot;I didn&#039;t really know what I wanted till you delivered what I asked for&quot;.</description>
		<content:encoded><![CDATA[<p>I just saw <a href="http://www.codinghorror.com/blog/archives/001083.html" rel="nofollow">this article by Jeff Atwood</a>. For my part the biggest work-inflator is &#8220;I didn&#8217;t really know what I wanted till you delivered what I asked for&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: strom</title>
		<link>http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71577</link>
		<dc:creator>strom</dc:creator>
		<pubDate>Thu, 27 Mar 2008 07:30:40 +0000</pubDate>
		<guid isPermaLink="false">http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71577</guid>
		<description>Another reader writes:

it is ridiculous that we consultants are so miserable about time estimate. i&#039;ve never been on on a project that&#039;s met it&#039;s time estimate. most have exceeded the time line miserably. a very few have have made it within what i would consider a &quot;normal over- extension&quot;. when that does happen it&#039;s normally been because my consulting group has to deal with a way out of control database or some sort of system outage beyond what the client company would ever admit or even know about.

data management has been the wild buffalo. just as my group is implementing some new functionality in Java on a client&#039;s web site, the data people inform us that &quot;there&#039;s a new installation of Oracle going in on the weekend&quot; - which shuts us down for 3 days through the following Wednesday. 

another buffalo is the &quot;change requirements by appearance&quot; approach of so many on the business side of management. here&#039;s what i mean: 

originally, the requirements on a project demanded that all users enter their user name, email and password; all of a sudden management says, &quot;all we need are the user name and password. trash the email as a requirement.&quot;; 
where do we put the email; 
reply: &quot;on the user&#039;s info page&quot;; 
there never was a user&#039;s info page in the requirements; 
the job continues for 2 more weeks as management decides what to put on the user info page and where to store it;

if i feel cynical that week, i could sit back and wait for the more changes to come. but since i simply cannot be the wisest monkey in the jungle, i figure i better befriend somebody in management to help figure out what&#039;s going on and become part of the decision making process. i then help management come up with an ad-hoc process that solves this problem, management feels good about itself, and i complete the project with a happy client.

thanks for the article. &quot;the rule of pi&quot; is a good one and pretty much matches the real time spent on the projects i&#039;ve been on.</description>
		<content:encoded><![CDATA[<p>Another reader writes:</p>
<p>it is ridiculous that we consultants are so miserable about time estimate. i&#8217;ve never been on on a project that&#8217;s met it&#8217;s time estimate. most have exceeded the time line miserably. a very few have have made it within what i would consider a &#8220;normal over- extension&#8221;. when that does happen it&#8217;s normally been because my consulting group has to deal with a way out of control database or some sort of system outage beyond what the client company would ever admit or even know about.</p>
<p>data management has been the wild buffalo. just as my group is implementing some new functionality in Java on a client&#8217;s web site, the data people inform us that &#8220;there&#8217;s a new installation of Oracle going in on the weekend&#8221; &#8211; which shuts us down for 3 days through the following Wednesday. </p>
<p>another buffalo is the &#8220;change requirements by appearance&#8221; approach of so many on the business side of management. here&#8217;s what i mean: </p>
<p>originally, the requirements on a project demanded that all users enter their user name, email and password; all of a sudden management says, &#8220;all we need are the user name and password. trash the email as a requirement.&#8221;;<br />
where do we put the email;<br />
reply: &#8220;on the user&#8217;s info page&#8221;;<br />
there never was a user&#8217;s info page in the requirements;<br />
the job continues for 2 more weeks as management decides what to put on the user info page and where to store it;</p>
<p>if i feel cynical that week, i could sit back and wait for the more changes to come. but since i simply cannot be the wisest monkey in the jungle, i figure i better befriend somebody in management to help figure out what&#8217;s going on and become part of the decision making process. i then help management come up with an ad-hoc process that solves this problem, management feels good about itself, and i complete the project with a happy client.</p>
<p>thanks for the article. &#8220;the rule of pi&#8221; is a good one and pretty much matches the real time spent on the projects i&#8217;ve been on.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: strom</title>
		<link>http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71576</link>
		<dc:creator>strom</dc:creator>
		<pubDate>Thu, 27 Mar 2008 07:10:52 +0000</pubDate>
		<guid isPermaLink="false">http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71576</guid>
		<description>Another reader writes:

My take on this from my time in IT is that deadlines were fuzzy because they were allowed to be. I met my deadlines because I always assumed I had to but other managers were often allowed to routinely miss deadlines with little consequence.
 
I once had an IT software manager tell me he had the best job in the company. He and his team could spend six months at a time writing requirements with the client for their next project. Then, before any real volume of code was written, the requirements were changed by the client or the project dropped entirely and they could begin again. He told me he never had to actually deliver a working application.
 
He did this for the better part of 5 years...</description>
		<content:encoded><![CDATA[<p>Another reader writes:</p>
<p>My take on this from my time in IT is that deadlines were fuzzy because they were allowed to be. I met my deadlines because I always assumed I had to but other managers were often allowed to routinely miss deadlines with little consequence.</p>
<p>I once had an IT software manager tell me he had the best job in the company. He and his team could spend six months at a time writing requirements with the client for their next project. Then, before any real volume of code was written, the requirements were changed by the client or the project dropped entirely and they could begin again. He told me he never had to actually deliver a working application.</p>
<p>He did this for the better part of 5 years&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bruce Fryer</title>
		<link>http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71574</link>
		<dc:creator>Bruce Fryer</dc:creator>
		<pubDate>Thu, 27 Mar 2008 02:08:35 +0000</pubDate>
		<guid isPermaLink="false">http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71574</guid>
		<description>Actually I was pretty good at estimating IT projects.  Could hit the dates accurately and the budget.  I always figured out the actual budget and put in a 10% cost overrun.   Why?   The unknown always came into play.   Even did an ISO 9001 very large scale project which hit the date and budget.   It was bottom up and then we locked the date.  When the date started to slip we negotiated features (added some, dropped others) and hit the date worldwide for delivery.   

The key is working with a team who is not afraid to say what is happening and have weekly bull sessions.  Market windows are key factors and missing them puts you in a world of hurt.

In the early days before I figured this out I had a formula: multiply by 2 and take the next unit of measurement.  So a 2 week project = 4 months.   Pretty cynical.</description>
		<content:encoded><![CDATA[<p>Actually I was pretty good at estimating IT projects.  Could hit the dates accurately and the budget.  I always figured out the actual budget and put in a 10% cost overrun.   Why?   The unknown always came into play.   Even did an ISO 9001 very large scale project which hit the date and budget.   It was bottom up and then we locked the date.  When the date started to slip we negotiated features (added some, dropped others) and hit the date worldwide for delivery.   </p>
<p>The key is working with a team who is not afraid to say what is happening and have weekly bull sessions.  Market windows are key factors and missing them puts you in a world of hurt.</p>
<p>In the early days before I figured this out I had a formula: multiply by 2 and take the next unit of measurement.  So a 2 week project = 4 months.   Pretty cynical.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mary</title>
		<link>http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71573</link>
		<dc:creator>Mary</dc:creator>
		<pubDate>Wed, 26 Mar 2008 18:55:10 +0000</pubDate>
		<guid isPermaLink="false">http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71573</guid>
		<description>This is so true it hurts. It&#039;s not just IT projects.  

I&#039;ve been burning the midnight oil, the candle at both ends and my eyes out trying to meet  self-imposed deadlines to produce a set of market documentation for a client who would in fact have been perfectly ok with a longer lead time.  

Why the self-delusion?  Partly, it&#039;s misguidedly aspirational (I will be super-efficient on this project as I never was before); partly it&#039;s wilfully ignoring the fact that thinking about something before you do it is part of the process and takes time;  and for the most part it&#039;s that I hope I&#039;ll work faster if I have a looming deadline. 

Great article.</description>
		<content:encoded><![CDATA[<p>This is so true it hurts. It&#8217;s not just IT projects.  </p>
<p>I&#8217;ve been burning the midnight oil, the candle at both ends and my eyes out trying to meet  self-imposed deadlines to produce a set of market documentation for a client who would in fact have been perfectly ok with a longer lead time.  </p>
<p>Why the self-delusion?  Partly, it&#8217;s misguidedly aspirational (I will be super-efficient on this project as I never was before); partly it&#8217;s wilfully ignoring the fact that thinking about something before you do it is part of the process and takes time;  and for the most part it&#8217;s that I hope I&#8217;ll work faster if I have a looming deadline. </p>
<p>Great article.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Flynn</title>
		<link>http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71571</link>
		<dc:creator>Flynn</dc:creator>
		<pubDate>Wed, 26 Mar 2008 13:24:29 +0000</pubDate>
		<guid isPermaLink="false">http://strom.wordpress.com/2008/03/26/multiply-by-pi/#comment-71571</guid>
		<description>What you have written deserves a book or two, hardly a blog post...or response. Each section could be parsed to some benefit.

How long would that take? Well, that needs a breakdown of What would that take? Some immediate organization, some thoughts on what needs researching, some thoughts on where the research would lead, some idea of what assets will be available to start, and what assets will be required post-research. Some idea of the historical precedent is needed - will the corporate desire to get it &#039;right&#039;, to some high standard prevent a target from being reached that might be &#039;good enough&#039; for others? How much energy is available to get any newly found requirements the permissions required to follow-up or utilize? 

Add a percentage for false leads. Add a percentage for tail chasing. Add a percentage for administration. Add a percentage for late coming bright ideas. 

Goodness. My response is getting out of hand.

I had a good experience talking to the chief engineer of a project on day, asking what the project would take. I got a general outline and the usual &#039;a couple of days&#039; and &#039;a few lines of code&#039; answers to the time question. The next day I went back and asked the &#039;what does it take&#039; question about one line of the general outline. Got several more particulars. Did the same thing in short bursts for daze...days. Finally, a usable answer was available. And still, all the vagaries of the research and development unknowns manifested themselves. 

Try that with an artist who has to develop a piece of art. R&amp;D ain&#039;t so obvious a need, but it is there. 

Peer pressure variants (If I don&#039;t do it, the responsibility lands on my co-workers, or Gee, I&#039;ll look like a fool if I hand in something substandard), money, glory, fear, deadlines that can&#039;t move (the convention starts on this date and the product must be shown, working and ready to buy online), deadlines that can shift (the convention starts on this date and the product must be shown, and the main parts need to be working.)

A book or two, perhaps a philosophy.</description>
		<content:encoded><![CDATA[<p>What you have written deserves a book or two, hardly a blog post&#8230;or response. Each section could be parsed to some benefit.</p>
<p>How long would that take? Well, that needs a breakdown of What would that take? Some immediate organization, some thoughts on what needs researching, some thoughts on where the research would lead, some idea of what assets will be available to start, and what assets will be required post-research. Some idea of the historical precedent is needed &#8211; will the corporate desire to get it &#8216;right&#8217;, to some high standard prevent a target from being reached that might be &#8216;good enough&#8217; for others? How much energy is available to get any newly found requirements the permissions required to follow-up or utilize? </p>
<p>Add a percentage for false leads. Add a percentage for tail chasing. Add a percentage for administration. Add a percentage for late coming bright ideas. </p>
<p>Goodness. My response is getting out of hand.</p>
<p>I had a good experience talking to the chief engineer of a project on day, asking what the project would take. I got a general outline and the usual &#8216;a couple of days&#8217; and &#8216;a few lines of code&#8217; answers to the time question. The next day I went back and asked the &#8216;what does it take&#8217; question about one line of the general outline. Got several more particulars. Did the same thing in short bursts for daze&#8230;days. Finally, a usable answer was available. And still, all the vagaries of the research and development unknowns manifested themselves. </p>
<p>Try that with an artist who has to develop a piece of art. R&amp;D ain&#8217;t so obvious a need, but it is there. </p>
<p>Peer pressure variants (If I don&#8217;t do it, the responsibility lands on my co-workers, or Gee, I&#8217;ll look like a fool if I hand in something substandard), money, glory, fear, deadlines that can&#8217;t move (the convention starts on this date and the product must be shown, working and ready to buy online), deadlines that can shift (the convention starts on this date and the product must be shown, and the main parts need to be working.)</p>
<p>A book or two, perhaps a philosophy.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
