Time Estimates - Black Art? [modified]
-
Anna-Jayne Metcalfe wrote:
Basically, if you can break the task down into small pieces (say 2 days work or less), you've a far better chance of coming up with an accurate estimate.
Aye! Scrum has also helped us come up with realistic (i.e. mostly correct) time estimates. /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
That's great to hear. :) 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.
-
Good article. So really we need to be gathering statistics ongoing as to how long it took at the task level vs the project level to get a bearing on where the estimates are failing. This last one isn't that bad. I'm late by about 8 hours or so. Better than a month, but even this grates on me. This statement is false.
That's the general idea. Most of us have been bitten by inaccurate estimates and badly resourced projects, so the more we can do to improve our estimates (or disprove others!) the better. 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.
-
Chris S Kaiser wrote:
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 would say I'm pretty good at it. My methodologies are basically to drill into the requirements, putting together both a confidence level and a time estimate. If the confidence level is low, I drill further. If that's not possible, and often it isn't, at least I can say to my client that I don't really have any way of estimating the time here without spending time to do further analysis. This happens often enough when dealing with new technologies, or the requirements simply can't be defined yet, etc. And lastly, after all the analysis, I follow the "Ross Rule of PI", named after a hardware guy I used to work with. I multiple all estimates by 3. Seriously. This helps to factor in testing, documentation, bug fixes, refactoring, etc. It also makes me look like a miracle worker (a la Scottie of Star Trek) when I get things done in less time. :) [edit] Oh, and one more thing. I also break the project up horizontally into milestones, and I tell my clients, we will revisit the time estimate for each milestone after completing the preceding one. It's interesting you posted this question. After responding to your other post, I was beginning to thing, this would be a good article. [/edit] 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
-- modified at 16:49 Monday 17th July, 2006
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.
-
From what I have seen, unless the project is something minor, most estimates fail to be accurate. In most cases you are either finished early (and have time to add more polish) or you are racing frantically trying to complete the project without losing your shirt. The best method to help reduce losses or loss of projects due to overbidding is to keep detailed logs of what you work on and how long it takes you to complete each task. When building an estimate, you can eye out what it took you before to complete and have a ballpark figure. Of course, this is relative to the tools you use. If you have to use tools (libraries, compilers, utilites) that have been recently updated, you may run into problems raising the costs. Other factors might apply such as working in a lower level language/technology such C++ vs a higher level, you may have less errors and greater accuracy to duplicate results the higher you go. I know for me, I dramtically reduced lots of simplistic errors which were simple typos or oversights after moving to C#/.NET from C++/Win32. Add to this, times when you work slightly outside of your norm, using a new library/technology and have to learn all the work arounds ;) Finally, after all your planning you push out your bid and in the process of doing the work, you run into a simple little bug in the OS or the technologies you are using and find it has just consumed 25% more time. This happens, and usually it means you eat it. As an example, a client need an ASP.NET app to work with MS Access. No problem, do this all the time, but I ran into an error which took time to track down about storing large data objects in Access. It is not that I did not plan the time, it was that I ran into a limitation of the technologies in use. I am not so sure that it is an "Art", but more of a "reasonable guess". The best a person can do is to keep a detailed log of every step and see how that applies to the future. Personally, I would try not give a "bid" on a large scale project, but rather in segments. Rocky <>< Latest Post: ASP.NET HttpException - Cannot use leading "..".. Blog: www.RockyMoore.com/TheCoder/[^]
Rocky Moore wrote:
I am not so sure that it is an "Art", but more of a "reasonable guess". The best a person can do is to keep a detailed log of every step and see how that applies to the future.
A developed skill based on data that increases competence iteratively seems to be the consensus. This statement is false.
-
Anna-Jayne Metcalfe wrote:
Basically, if you can break the task down into small pieces (say 2 days work or less), you've a far better chance of coming up with an accurate estimate.
Aye! Scrum has also helped us come up with realistic (i.e. mostly correct) time estimates. /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
Looks interesting. I like the domain name although it might be reaching a bit. ;) http://www.controlchaos.com/ This statement is false.
-
Chris S Kaiser wrote:
I don't understand your assumption that I was talking about bidding vs estimating.
Chris S Kaiser wrote:
might be a detriment to retaining the project?
"retaining" :)
Yeah, language might be remiss here. I'm working a contract where the main project comprises smaller projects within the larger framework. So I was commenting on the potential results of always exceeding the estimates, they may choose not to renew the contract. Although, I'm not really worried about that in this position, it was just hypothetical. This statement is false.
-
Chris S Kaiser wrote:
By giving an estimate that is based on the facts that limited requirements require a wider estimate range that soon becomes unacceptable to management as they've already given a hard date that must be met.
If there is already a date then what is the estimate for? :confused:
Chris S Kaiser wrote:
and it exceeds the date promised to the client, it could effect the renewal of the contract.
Sounds like you are "bidding" again. :confused:
Chris S Kaiser wrote:
But the effort to get at accurate estimates is what this is about.
An "accurate" estimate is only obtainable from "accurate requirements". Anything else is just a "guess" not an estimate.
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.
-
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
-
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.
-
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.
-
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!) -
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.
-
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.
