<?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/"
		>
<channel>
	<title>Comments on: Reflection: Unrealistic Schedules</title>
	<atom:link href="http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/</link>
	<description>Practical methods for successful software management.</description>
	<lastBuildDate>Mon, 03 Aug 2009 05:32:33 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Bill Miller</title>
		<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/comment-page-1/#comment-64</link>
		<dc:creator>Bill Miller</dc:creator>
		<pubDate>Fri, 05 Oct 2007 18:57:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/#comment-64</guid>
		<description>I was hoping you were saying that, but I wasn&#039;t really sure.  I agree there&#039;s more to planning a project than just getting good estimates.  All of the points you raise are relevant and necessary aspects of creating and delivering on a successful plan.  For me, though, it all starts and ends with having the best possible estimates, and estimating in such a way that the deliveries are trackable as they are being developed.  Otherwise, we are back to taking the developers word for it when your 50% into the time budgeted and he says he&#039;s 75% complete, and then the deadline passes, and he&#039;s 98% complete for the next 8 weeks.  Obviously something is wrong. Metrics give you a way to see something is wrong early and to quantify it, so that the developer and the manager can make intelligent decisions without being in denial.</description>
		<content:encoded><![CDATA[<p>I was hoping you were saying that, but I wasn&#8217;t really sure.  I agree there&#8217;s more to planning a project than just getting good estimates.  All of the points you raise are relevant and necessary aspects of creating and delivering on a successful plan.  For me, though, it all starts and ends with having the best possible estimates, and estimating in such a way that the deliveries are trackable as they are being developed.  Otherwise, we are back to taking the developers word for it when your 50% into the time budgeted and he says he&#8217;s 75% complete, and then the deadline passes, and he&#8217;s 98% complete for the next 8 weeks.  Obviously something is wrong. Metrics give you a way to see something is wrong early and to quantify it, so that the developer and the manager can make intelligent decisions without being in denial.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ray koscinski</title>
		<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/comment-page-1/#comment-63</link>
		<dc:creator>ray koscinski</dc:creator>
		<pubDate>Fri, 05 Oct 2007 16:42:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/#comment-63</guid>
		<description>I believe you&#039;ve misread me.  I&#039;m not at all suggesting that we don&#039;t size projects, rather my point is about doing proper scheduling.  

Some people are better at seeing the big picture and are able flush out the risks, their likelihood and cost.  While others are very good just estimating their 20 lines of code.  But knowing that it will take X days to cut so many lines of code does not make a schedule.  And at the end of the day our customers don&#039;t care how accurate we were with our estimates on effort to code a module, but scream at our accuracy on the overall schedule.  Some people can&#039;t see the forest through the trees and are better suited for telling me the size of a tree and not how long it will take them to walk thru the forest.  Make sense?</description>
		<content:encoded><![CDATA[<p>I believe you&#8217;ve misread me.  I&#8217;m not at all suggesting that we don&#8217;t size projects, rather my point is about doing proper scheduling.  </p>
<p>Some people are better at seeing the big picture and are able flush out the risks, their likelihood and cost.  While others are very good just estimating their 20 lines of code.  But knowing that it will take X days to cut so many lines of code does not make a schedule.  And at the end of the day our customers don&#8217;t care how accurate we were with our estimates on effort to code a module, but scream at our accuracy on the overall schedule.  Some people can&#8217;t see the forest through the trees and are better suited for telling me the size of a tree and not how long it will take them to walk thru the forest.  Make sense?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill Miller</title>
		<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/comment-page-1/#comment-61</link>
		<dc:creator>Bill Miller</dc:creator>
		<pubDate>Fri, 05 Oct 2007 04:38:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/#comment-61</guid>
		<description>Ray, you raise some valuable points.  The quality of the estimate is dependent on the skill of the estimator, but that doesn&#039;t imply the estimator shouldn&#039;t use the best tool for the job, or that estimating is some black art only possible by the right person with divine insight.  I curse my guitar everyday because I can&#039;t play like Jimmy Hendrix.  It&#039;s not the guitar&#039;s fault the music I make with it sounds like noise.  

I believe estimating is a skill that anyone can learn to do if they choose to learn and do it.  Not everyone will be as good at it who learns how to do it.  We can never take the skill/talent element out of the job.  That&#039;s what makes olympic champions.  It&#039;s the individual that&#039;s perfected the skills to the highest level that comes out on top.   It&#039;s the same for writing code and estimating.  Some people are more skilled/talented at it than others.  Those teams that follow the best practices and are the best skilled at them will perform the best.  Using the the right tool and having a bad outcome is not evidence of using the wrong tool.  We need to be careful of not throwing the baby out with the bath water.

Are you suggesting that sizing a project isn&#039;t the right approach?  Or that in constuction they don&#039;t size the jobs first?</description>
		<content:encoded><![CDATA[<p>Ray, you raise some valuable points.  The quality of the estimate is dependent on the skill of the estimator, but that doesn&#8217;t imply the estimator shouldn&#8217;t use the best tool for the job, or that estimating is some black art only possible by the right person with divine insight.  I curse my guitar everyday because I can&#8217;t play like Jimmy Hendrix.  It&#8217;s not the guitar&#8217;s fault the music I make with it sounds like noise.  </p>
<p>I believe estimating is a skill that anyone can learn to do if they choose to learn and do it.  Not everyone will be as good at it who learns how to do it.  We can never take the skill/talent element out of the job.  That&#8217;s what makes olympic champions.  It&#8217;s the individual that&#8217;s perfected the skills to the highest level that comes out on top.   It&#8217;s the same for writing code and estimating.  Some people are more skilled/talented at it than others.  Those teams that follow the best practices and are the best skilled at them will perform the best.  Using the the right tool and having a bad outcome is not evidence of using the wrong tool.  We need to be careful of not throwing the baby out with the bath water.</p>
<p>Are you suggesting that sizing a project isn&#8217;t the right approach?  Or that in constuction they don&#8217;t size the jobs first?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill Miller</title>
		<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/comment-page-1/#comment-60</link>
		<dc:creator>Bill Miller</dc:creator>
		<pubDate>Fri, 05 Oct 2007 04:06:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/#comment-60</guid>
		<description>RaviKant, thanks for commenting and the for the kind words.  You&#039;re right it&#039;s really difficult to pushback on the schedule from the bottom-up. The one thing you have control over is the quality of what you deliver.  You need to make sure it&#039;s the best, even if it means you have to suffer the pain of delivering it late. I&#039;ve found, as long as deliveries aren&#039;t too late, everyone forgets the small slip if what&#039;s delivered is great. Develop a reputation for delivering high quality, and most good managers will go to bat for you.

Please keep reading and keep sharing.</description>
		<content:encoded><![CDATA[<p>RaviKant, thanks for commenting and the for the kind words.  You&#8217;re right it&#8217;s really difficult to pushback on the schedule from the bottom-up. The one thing you have control over is the quality of what you deliver.  You need to make sure it&#8217;s the best, even if it means you have to suffer the pain of delivering it late. I&#8217;ve found, as long as deliveries aren&#8217;t too late, everyone forgets the small slip if what&#8217;s delivered is great. Develop a reputation for delivering high quality, and most good managers will go to bat for you.</p>
<p>Please keep reading and keep sharing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill Miller</title>
		<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/comment-page-1/#comment-59</link>
		<dc:creator>Bill Miller</dc:creator>
		<pubDate>Fri, 05 Oct 2007 03:50:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/#comment-59</guid>
		<description>Steve,  thanks for commenting.  I like your point about discounting and hitting sales targets.  It&#039;s certainly a case of the pot calling the kettle black. Pointing out the other guys failings, while it feels good, isn&#039;t very productive. Sometimes in life you just have to suck it up, and not let the environment/people distract you from your interests.  

Developing software and selling in a competitive marketplace is a tough business.   I don&#039;t believe anyone has ill intent; I believe we all lack the tools to manage the circumstances better: sales and engineering.

There are no perfect answers, but there are things we can do to manage the circumstances better, and maybe when we manage them well because we have the right tools, it feels like perfection, though it can never be perfect.  My goal is to share with you some tools and techniques that have worked very well for me:  I&#039;m not just writing about things I think would work.  Not everyone is going to like them or agree with them, but I can tell you they work extremely well when used effectively.  I think our quest for the perfect answer prevents us from embracing the best solution.

Please keep reading and keep sharing.</description>
		<content:encoded><![CDATA[<p>Steve,  thanks for commenting.  I like your point about discounting and hitting sales targets.  It&#8217;s certainly a case of the pot calling the kettle black. Pointing out the other guys failings, while it feels good, isn&#8217;t very productive. Sometimes in life you just have to suck it up, and not let the environment/people distract you from your interests.  </p>
<p>Developing software and selling in a competitive marketplace is a tough business.   I don&#8217;t believe anyone has ill intent; I believe we all lack the tools to manage the circumstances better: sales and engineering.</p>
<p>There are no perfect answers, but there are things we can do to manage the circumstances better, and maybe when we manage them well because we have the right tools, it feels like perfection, though it can never be perfect.  My goal is to share with you some tools and techniques that have worked very well for me:  I&#8217;m not just writing about things I think would work.  Not everyone is going to like them or agree with them, but I can tell you they work extremely well when used effectively.  I think our quest for the perfect answer prevents us from embracing the best solution.</p>
<p>Please keep reading and keep sharing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Johnson</title>
		<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/comment-page-1/#comment-58</link>
		<dc:creator>Steve Johnson</dc:creator>
		<pubDate>Fri, 05 Oct 2007 02:42:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/#comment-58</guid>
		<description>Furthermore I find that sales people--and many executives--think that talking is working and that they can just talk about it until it comes true. But talk is cheap while work is dear. At some point, someone actually has to do some work. My technique: turn it around. Whatever a sales person says about development, say about sales people. Sales: &quot;Why can&#039;t you ever deliver on schedule without descoping?&quot; Dev: &quot;Why can&#039;t you ever sell without discounting?&quot; They can&#039;t stand their own ridiculous statements used against them. How is it that we expect near-perfect estimation from a developer when no one believes a sales person&#039;s  estimate until December 32?</description>
		<content:encoded><![CDATA[<p>Furthermore I find that sales people&#8211;and many executives&#8211;think that talking is working and that they can just talk about it until it comes true. But talk is cheap while work is dear. At some point, someone actually has to do some work. My technique: turn it around. Whatever a sales person says about development, say about sales people. Sales: &#8220;Why can&#8217;t you ever deliver on schedule without descoping?&#8221; Dev: &#8220;Why can&#8217;t you ever sell without discounting?&#8221; They can&#8217;t stand their own ridiculous statements used against them. How is it that we expect near-perfect estimation from a developer when no one believes a sales person&#8217;s  estimate until December 32?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ray koscinski</title>
		<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/comment-page-1/#comment-57</link>
		<dc:creator>ray koscinski</dc:creator>
		<pubDate>Thu, 04 Oct 2007 21:10:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/#comment-57</guid>
		<description>I believe part of the problem is that Developers are never trained in the art of estimating.  Instead they learn to first write code, then write more complex code, then design and if they are real good, then architecture.  But you rarely see where organizations train people on the art of estimation.

Taking your example of construction, I&#039;ve acted as a GC on a few homes being built.  What I found is that many professionals lack the same skills.  They know how to weld a pipe or bang a nail and can even tell you how many 2x4s they need to put that wall up.  But most all blow just how long it will take them to put the wall up.

The best estimators in the construction field end up retiring their hammers and welding irons and instead become the owners of successful businesses with teams under them.  The art of estimating is far different than the art of doing the work.  Why is this?

Because you need people who are bigger thinkers to estimate and not people who are great coders, great designers or even great architects.  These big thinkers have to see all the pitfalls of the projects, really understand Risk Analysis and what really goes on during the course of a day.  The great &quot;do&#039;ers&quot; are great at doing because they can focus on a problem and solve it properly.  But these type of people&#039;s strongest asset is their ability to focus.  What is the flip side of this?  They&#039;re so focused that they don&#039;t see the distractions of the day.  They don&#039;t see all those risks that are going to hit them and throw them off schedule.

Estimating is a skill that demands a certain personality.  Sometimes this can&#039;t even be tought, but is part of your make up.  I think we all know those people out there who are so damned focused you often say &quot;that&#039;s the man I want on this job&quot;, yet these are the same people you tend to steer far away from looking at bigger issues, solving issues that involve lots of people.  Or you even tell others &quot;please stay away from Bob as he&#039;s focused on this job and I can&#039;t have him distracted&quot;.  Because we all know these very focused minds when distracted often go deep dive into their distraction forgetting what they were originally working on.  

Something to think about.</description>
		<content:encoded><![CDATA[<p>I believe part of the problem is that Developers are never trained in the art of estimating.  Instead they learn to first write code, then write more complex code, then design and if they are real good, then architecture.  But you rarely see where organizations train people on the art of estimation.</p>
<p>Taking your example of construction, I&#8217;ve acted as a GC on a few homes being built.  What I found is that many professionals lack the same skills.  They know how to weld a pipe or bang a nail and can even tell you how many 2&#215;4s they need to put that wall up.  But most all blow just how long it will take them to put the wall up.</p>
<p>The best estimators in the construction field end up retiring their hammers and welding irons and instead become the owners of successful businesses with teams under them.  The art of estimating is far different than the art of doing the work.  Why is this?</p>
<p>Because you need people who are bigger thinkers to estimate and not people who are great coders, great designers or even great architects.  These big thinkers have to see all the pitfalls of the projects, really understand Risk Analysis and what really goes on during the course of a day.  The great &#8220;do&#8217;ers&#8221; are great at doing because they can focus on a problem and solve it properly.  But these type of people&#8217;s strongest asset is their ability to focus.  What is the flip side of this?  They&#8217;re so focused that they don&#8217;t see the distractions of the day.  They don&#8217;t see all those risks that are going to hit them and throw them off schedule.</p>
<p>Estimating is a skill that demands a certain personality.  Sometimes this can&#8217;t even be tought, but is part of your make up.  I think we all know those people out there who are so damned focused you often say &#8220;that&#8217;s the man I want on this job&#8221;, yet these are the same people you tend to steer far away from looking at bigger issues, solving issues that involve lots of people.  Or you even tell others &#8220;please stay away from Bob as he&#8217;s focused on this job and I can&#8217;t have him distracted&#8221;.  Because we all know these very focused minds when distracted often go deep dive into their distraction forgetting what they were originally working on.  </p>
<p>Something to think about.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RaviKant</title>
		<link>http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/comment-page-1/#comment-55</link>
		<dc:creator>RaviKant</dc:creator>
		<pubDate>Thu, 04 Oct 2007 15:36:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.yuwantitwhen.com/blog/2007/10/04/reflection-unrealistic-schedules/#comment-55</guid>
		<description>Well said Bill. One reason I commonly see for committing to unrealistic schedules is short-sighted career planning. People over-commit to make things look good in the short term. And in big teams, schedule pushback is bottoms-up is difficult to do. 

Very educational blog. Keep up the good work.</description>
		<content:encoded><![CDATA[<p>Well said Bill. One reason I commonly see for committing to unrealistic schedules is short-sighted career planning. People over-commit to make things look good in the short term. And in big teams, schedule pushback is bottoms-up is difficult to do. </p>
<p>Very educational blog. Keep up the good work.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
