Comments on: Never Be Responsible For Your Estimations Again http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/ Ideas for building efficient developers and software Tue, 09 Mar 2010 19:29:12 -0500 hourly 1 By: Adron http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/#comment-1882 Adron Wed, 30 Apr 2008 21:38:17 +0000 http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/#comment-1882 The only problem with even that answer, is that the project manager, lead, or client will end up picking some ridiculous date anyway and holding someone to it. Of course even then a developer must fight on and repeat, time again and time again, that the estimate is an ESTIMATE and not a deliverable date. I wonder how much companies waste in this type of idiotic behavior. I'm thinking a safe estimate of the "waste" would be in the 10%+ margin - AT MINIMUM. The only problem with even that answer, is that the project manager, lead, or client will end up picking some ridiculous date anyway and holding someone to it.

Of course even then a developer must fight on and repeat, time again and time again, that the estimate is an ESTIMATE and not a deliverable date.

I wonder how much companies waste in this type of idiotic behavior. I’m thinking a safe estimate of the “waste” would be in the 10%+ margin – AT MINIMUM.

]]> By: Hank Lynch http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/#comment-855 Hank Lynch Mon, 31 Dec 2007 16:12:18 +0000 http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/#comment-855 Yeah, I've had my ass handed to me before on this one too. I estimated out a project, padded it nicely, and handed it off to management. We were in a strict CMMI process driven shop, and they placed an "X" on a calendar based on initial signoff of the SOW. That was the release date, period. In the months that followed, our doc phase went about 3 times longer than it should have, but the calendar release date never changed, then I went to Tech Ed for a week, got assigned to other clients, and arrived back in the office days before the release date on the calandar. We were not even close to releasable code. Management put us on a forced march, 20 hr shift the day before release, absurd. Make a long story short, I gave the estimate, management couldn't control the situation with the client to mention that we were running behind in the early stages, and I got my ass handed to me for a failure I was only marginally involved in, because I gave the initial estimate. I no longer work for that management team or company, but it is now a firm practice of mine to estimate by phase, and avoid calandars at all cost. Using language like, "...based on the completion of X, it should take between X, and Y weeks to complete..." People understand the reason for any ambiguity if you just expalin it to them. You can't make sure that they like it, but you can make sure that they understand. Yeah, I’ve had my ass handed to me before on this one too. I estimated out a project, padded it nicely, and handed it off to management. We were in a strict CMMI process driven shop, and they placed an “X” on a calendar based on initial signoff of the SOW. That was the release date, period.

In the months that followed, our doc phase went about 3 times longer than it should have, but the calendar release date never changed, then I went to Tech Ed for a week, got assigned to other clients, and arrived back in the office days before the release date on the calandar. We were not even close to releasable code. Management put us on a forced march, 20 hr shift the day before release, absurd.

Make a long story short, I gave the estimate, management couldn’t control the situation with the client to mention that we were running behind in the early stages, and I got my ass handed to me for a failure I was only marginally involved in, because I gave the initial estimate.

I no longer work for that management team or company, but it is now a firm practice of mine to estimate by phase, and avoid calandars at all cost. Using language like, “…based on the completion of X, it should take between X, and Y weeks to complete…”

People understand the reason for any ambiguity if you just expalin it to them. You can’t make sure that they like it, but you can make sure that they understand.

]]> By: Jeremy N http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/#comment-412 Jeremy N Mon, 29 Oct 2007 19:31:07 +0000 http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/#comment-412 Unfortunately between having plumbers and handymen provide estimates to a home owner and software development today the definition of the word estimate turned into a synonym for the word “fixed bid” with devastating results. Although I haven’t personally used Max’s concept of large ranges, I have been a fan of the phrase “this is the time it would take with my current understanding.” Then when new understanding is discovered I considered it a change order much like if the scope had changed otherwise. For the clients that haven’t been trained I could see a lot of value in Max’s proposal for never being responsible for your estimations again. Side Note: I am telling some of you right now you really need to put the smack down on your managers for putting you in darn right crappy positions. Unfortunately between having plumbers and handymen provide estimates to a home owner and software development today the definition of the word estimate turned into a synonym for the word “fixed bid” with devastating results.

Although I haven’t personally used Max’s concept of large ranges, I have been a fan of the phrase “this is the time it would take with my current understanding.” Then when new understanding is discovered I considered it a change order much like if the scope had changed otherwise. For the clients that haven’t been trained I could see a lot of value in Max’s proposal for never being responsible for your estimations again.

Side Note: I am telling some of you right now you really need to put the smack down on your managers for putting you in darn right crappy positions.

]]> By: james http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/#comment-221 james Mon, 03 Sep 2007 11:37:47 +0000 http://www.codesqueeze.com/never-be-responsible-for-your-estimations-again/#comment-221 In a position I have since left, I was relied on to do estimates which I would be held to (yet being pressured to keep them low), and then they would go to the customer as a fixed-price quote. Time was never allowed for things like testing - Nope, virtually as soon as the project had sputtered into life, it was deployed. It didn't matter if I raised objections about the process or the way we overworked our developers, as my manager was too weak to be firm with clients (and unwilling to fire bad ones). I am now the fifth person to resign from his 8 person team in 1 year. Basically, they're screwed, since I'm taking a hell of a lot of domain knowledge with me (I was the "whatever it takes" guy, out of a team of apathetic 5:01 programmers). Feels good to be gone :) In a position I have since left, I was relied on to do estimates which I would be held to (yet being pressured to keep them low), and then they would go to the customer as a fixed-price quote.

Time was never allowed for things like testing – Nope, virtually as soon as the project had sputtered into life, it was deployed. It didn’t matter if I raised objections about the process or the way we overworked our developers, as my manager was too weak to be firm with clients (and unwilling to fire bad ones).

I am now the fifth person to resign from his 8 person team in 1 year. Basically, they’re screwed, since I’m taking a hell of a lot of domain knowledge with me (I was the “whatever it takes” guy, out of a team of apathetic 5:01 programmers).

Feels good to be gone :)

]]>