Time Estimates - Black Art? [modified]
-
I am not speaking to the "political" and "business" aspects of this issue. It was not clear to me that was your question. I was speaking to the "science" of software estimating. The science is simple and the business either supports it or it does not. If it does then a accurate scientific estimate can be produced. If not then whatever is stated verbally or on paper is done so from the perspective of "business" and has nothing to do with scientific accuracy, period. They are two completely different things.
Sure, I take your point. But this is debating semantics. The business is most definately involved in the estimation of the time it takes to produce software. And I don't believe we're solely concerned with scientific accuracy, but with striking a balance that works in the real world. This statement is false.
-
This would be a good article. Especially if it cited real-world examples of successes and failures in the process. I think two seperate sections would be needed though, one where the engineer is directly working with a client and another where the engineer has to work with internal management. It seems to me that it might be easier to convey the reality of the estimation directly with a client than with a management that thinks it can get done in the time they dictate. I could be wrong though. I like the idea of revisiting the estimate with each milestone. That and breaking it down to the task level and documenting the results. This statement is false.
Chris S Kaiser wrote:
It seems to me that it might be easier to convey the reality of the estimation directly with a client than with a management that thinks it can get done in the time they dictate. I could be wrong though.
Doubt it. A client, paying hourly, will ask "how long will this take". A manager, paying salaries, will say "it needs to be done yesterday."
Chris S Kaiser wrote:
Especially if it cited real-world examples of successes and failures in the process.
The problem is, if I cited recent failures from one of my client's in particular, they would know that, as they read my articles, and not be happy with me. It's much easier to write about successes and bury the failures, it seems. Still, something to think about. And I definitely agree, working with clients vs. management is two separate things, no matter how much TQM training you've had, where you're supposed to treat your manager as a client. I wish there was a way for an article to be more like a wiki, where someone could write the core piece and others could make further contributions. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
Chris S Kaiser wrote:
It seems to me that it might be easier to convey the reality of the estimation directly with a client than with a management that thinks it can get done in the time they dictate. I could be wrong though.
Doubt it. A client, paying hourly, will ask "how long will this take". A manager, paying salaries, will say "it needs to be done yesterday."
Chris S Kaiser wrote:
Especially if it cited real-world examples of successes and failures in the process.
The problem is, if I cited recent failures from one of my client's in particular, they would know that, as they read my articles, and not be happy with me. It's much easier to write about successes and bury the failures, it seems. Still, something to think about. And I definitely agree, working with clients vs. management is two separate things, no matter how much TQM training you've had, where you're supposed to treat your manager as a client. I wish there was a way for an article to be more like a wiki, where someone could write the core piece and others could make further contributions. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
That's kinda what I was thinking. This would be much better as a colaborative work. Plus we could get some of those failures without puttin' you on the spot. :laugh:;) This might be a nice enhancement for Chris to consider.. a discussion based article.. dunno. This statement is false.
-
The date given to the customer is by management. The estimate is for management as a reality check as to whether or not the date given to the customer can be met or not. And there's no bidding. No competition. I'm hired as a consultant to work this project, and its renewable, but I was using this scenario hypothetically to discuss this possibility. Sounds like your nitpicking dude.
led mike wrote:
An "accurate" estimate is only obtainable from "accurate requirements". Anything else is just a "guess" not an estimate.
An estimate is a guess. From Wiki: Estimation From Wikipedia, the free encyclopedia Estimation is the calculated approximation of a result which is usable even if input data may be incomplete, uncertain, or noisy. So this is a guess. And your debating semantics here and not addressing the issue. This statement is false.
Chris S Kaiser wrote:
The estimate is for management as a reality check as to whether or not the date given to the customer can be met or not.
Oh... hmmm, never seen that before. That would tend to change things a bit.
Chris S Kaiser wrote:
And your debating semantics here and not addressing the issue.
Not my intention, given your situation I can see how it looks that way.
Chris S Kaiser wrote:
calculated approximation
Exactly what I was saying, the more accurate the information... the more accurate the estimate. That's all I was trying to say. I got a little confused about the whole "bidding" thing. I am easily confused... that's why I need accurate requirements! :laugh:
-
That's kinda what I was thinking. This would be much better as a colaborative work. Plus we could get some of those failures without puttin' you on the spot. :laugh:;) This might be a nice enhancement for Chris to consider.. a discussion based article.. dunno. This statement is false.
Chris S Kaiser wrote:
a discussion based article
It occurred to me that one could make the email address and password public, then people could sign in and edit the article. :) Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
Alright, how many of you claim to be skilled in this area, and what are your methodologies for ensuring accuracy, or at least coming close? I fall victim to the "Can-do" approach. Mostly from some vain need to please. :doh: But half the time I really do think I can get it done in that time, but there always seems to be something that pops up to stall release, whether its an obscure bug or a lack of good requirements. Or something else altogether? This statement is false. -- modified at 13:06 Monday 17th July, 2006
My estimates are very accurate. When I do err, it's usually on the long side. My methodology is simple, but not easily reproduced since it's entirely based on working in the industry for 18+ years. It's not as conscious and deliberate as I make it sound, but I compare the task presented with comparable tasks from my past experience and those where family, friends and collegues have given me a post mortem type critique (I always do post mortem examinations, though usually they are solitary affairs (see below).) I then factor in the number of assets available, their skill level, how they program, how many meetings are held, how clueless product management is, how indecisive upper management is and even how optimistic the developers are when first told about the project (there is generally an inverse relationship between initial optimism and how long it takes to finish a product.) I also factor in the problem areas I foresee (for example, if printing is required, add two to three months right away), the problems with the computer language and/or environment being used and whether or not a technical writer is going to be hired/assigned sooner or later. (This last requirement may seem weird, but I've found that management's failure to assign a technical writer sooner, or even at all, indicates a certain cluelessness about software development and the unwillingness to spend money on assets whose benefits are not immediately obvious.) Post Mortems: Unfortunately, most companies promise they will do these, but rarely do and if they do, it will be a superficial examination that does more harm than good. The reason is simple; most projects fail because of the people with the big paychecks. If you are brutally honest, the fingers end up being pointed squarely at the VPs, CTO and President/CEO. (In my experience, the worse offenders are usually the top level sales managers, followed closely by the CTO.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
He sure does. :) I must admit I tend to read the Business of Software forum rather than the others these days (running a uISV gives me a vested interest! ;)) but they're all well worth a look. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Anna-Jayne Metcalfe wrote:
I must admit I tend to read the Business of Software forum
I took a quick glance there and it looks like there is some pretty good discussions in there :)
-
Chris S Kaiser wrote:
The estimate is for management as a reality check as to whether or not the date given to the customer can be met or not.
Oh... hmmm, never seen that before. That would tend to change things a bit.
Chris S Kaiser wrote:
And your debating semantics here and not addressing the issue.
Not my intention, given your situation I can see how it looks that way.
Chris S Kaiser wrote:
calculated approximation
Exactly what I was saying, the more accurate the information... the more accurate the estimate. That's all I was trying to say. I got a little confused about the whole "bidding" thing. I am easily confused... that's why I need accurate requirements! :laugh:
led mike wrote:
That's all I was trying to say. I got a little confused about the whole "bidding" thing. I am easily confused... that's why I need accurate requirements!
Hah! Good point. ;P This statement is false.
-
Chris S Kaiser wrote:
a discussion based article
It occurred to me that one could make the email address and password public, then people could sign in and edit the article. :) Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
Preferrably with some oversight. heh heh... Estrogen Boy might get disgruntled and lash out. D'oh! Now I've jumped on the band wagon.. for shame for shame.. This statement is false.
-
James R. Twine wrote:
The most important thing you can do when giving an estimate is to remind all parties involved that it is an estimate, and not a firm deadline.
I agree with this, but sometimes you get on a project to find out that sales already sold and promised a date to a client. And its either put yourself to the task or gamble with your employment. I'm a little tired of being the nail that stood up only to get pounded down. This statement is false.
Chris S Kaiser wrote:
I agree with this, but sometimes you get on a project to find out that sales already sold and promised a date to a client. And its either put yourself to the task or gamble with your employment. I'm a little tired of being the nail that stood up only to get pounded down.
In that case, more resources (people and/or money) must be thrown at the problem if the estimates given do not fit the expected timeline. All the while, people must remember that nine women cannot make a baby in one month - some things are a matter of time, plain and simple. Remember - there is always another job. But more than likely, you are a talented developer with existing domain knowledge that is necessary to solve the problem. In other words, there is only one you. It pays to remind people of that fact every now and then. :) Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
My estimates are very accurate. When I do err, it's usually on the long side. My methodology is simple, but not easily reproduced since it's entirely based on working in the industry for 18+ years. It's not as conscious and deliberate as I make it sound, but I compare the task presented with comparable tasks from my past experience and those where family, friends and collegues have given me a post mortem type critique (I always do post mortem examinations, though usually they are solitary affairs (see below).) I then factor in the number of assets available, their skill level, how they program, how many meetings are held, how clueless product management is, how indecisive upper management is and even how optimistic the developers are when first told about the project (there is generally an inverse relationship between initial optimism and how long it takes to finish a product.) I also factor in the problem areas I foresee (for example, if printing is required, add two to three months right away), the problems with the computer language and/or environment being used and whether or not a technical writer is going to be hired/assigned sooner or later. (This last requirement may seem weird, but I've found that management's failure to assign a technical writer sooner, or even at all, indicates a certain cluelessness about software development and the unwillingness to spend money on assets whose benefits are not immediately obvious.) Post Mortems: Unfortunately, most companies promise they will do these, but rarely do and if they do, it will be a superficial examination that does more harm than good. The reason is simple; most projects fail because of the people with the big paychecks. If you are brutally honest, the fingers end up being pointed squarely at the VPs, CTO and President/CEO. (In my experience, the worse offenders are usually the top level sales managers, followed closely by the CTO.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
I like the idea of doing post mordems. My time is more like juggling live fish than anything else though, and some of those fish get slippery. Documentation is another poor area of mine. We have technical writers documenting the product, and that's actually out of my cycle and estimates, but does factor into the end date, what I have trouble with is producing documentation for the development itself. Like relationships between data, overview of the framework, using doxygen style comments and actually producing an intranet version of the api. etc.
Joe Woodbury wrote:
he reason is simple; most projects fail because of the people with the big paychecks. If you are brutally honest, the fingers end up being pointed squarely at the VPs, CTO and President/CEO.
This is one of those things that while most people will agree with, in practice the developers take the hit. This statement is false.
-
Chris S Kaiser wrote:
I agree with this, but sometimes you get on a project to find out that sales already sold and promised a date to a client. And its either put yourself to the task or gamble with your employment. I'm a little tired of being the nail that stood up only to get pounded down.
In that case, more resources (people and/or money) must be thrown at the problem if the estimates given do not fit the expected timeline. All the while, people must remember that nine women cannot make a baby in one month - some things are a matter of time, plain and simple. Remember - there is always another job. But more than likely, you are a talented developer with existing domain knowledge that is necessary to solve the problem. In other words, there is only one you. It pays to remind people of that fact every now and then. :) Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)James R. Twine wrote:
nine women cannot make a baby in one month
I'm gonna plagerise this if you don't object. I like it.
James R. Twine wrote:
In other words, there is only one you. It pays to remind people of that fact every now and then.
Yeah, true.. and I'm isolated in this sense. Ever the balancing act. My current scenario really isn't that bad. I would consider it one of the good ones for sure. And the due dates were kinda made before my time. I inherited a project another guy failed to finish. But these things crop up from time to time and I'd just like to get better at managing it from my end. This statement is false.