August 10, 2015 at 8:24 pm
Comments posted to this topic are about the item Making Guesses
August 11, 2015 at 3:43 am
I agree on the concept of making "guess-timates" when asked to provide estimated time and scope. Almost without fail, any estimate--made in good faith--will be received as having been cast in stone. What we understand, that management or others down the line in an IT shop don't (or won't), is that many IT projects have a margin of error of 100%. Especially for projects that have never been done before. A mechanic can estimate how long a brake job will take on a certain vehicle because it's been done millions of times. But IT projects aren't like that. We can only give what I've called "guess-timates" based upon similarities with other projects. The farther into the project we go, we can ratchet down the estimate more accurately; but to create a project plan that is inflexible is simply irrational. The project manager then uses his/her negotiating skills to bring management into the real world. I shudder each and every time I'm asked for an estimate on any project... especially when I know the one asking is famous for scope creep!
:w00t:
----------------------------------
Randy Worrell
August 11, 2015 at 5:31 am
Of consider the related scenario where the decision-makers incorporate guidelines or guesstimates from a previous project which has little to no relationship to reality in the new project.
"What do you mean that won't work? You said it would the last time!"
At which point you start banging your head on the wall (or other convenient large, solid object).
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
August 11, 2015 at 6:50 am
IT needs a more general version of Hofstadter's law. That is why when asked to estimate time, I generally add a 150% pad (100% for issues during dev, 50% for issues found in QA). For horsepower, triple it, and for storage go with 10X. If you think it will be 5GB, but you tell them 50, then when it is only 20 you have room to grow. Or if 50 isn't enough you can tell them you only expected it to be 5 and were giving yourself space.
August 11, 2015 at 7:36 am
Everyone I know keeps saying that "Disk space is cheap". I know better but it's still cheaper than having to work within ridiculously small confines on an unknown project. While I appreciate that SAN administrators DO have a job to do, they should never get upset when someone says something like "We need 20GB in the short term and we'll be able to drop back to 5GB when we're done". They should just leave the space so that they won't have to add it later when someone finds out their original estimate was incorrect.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2015 at 7:50 am
Disk space truely is cheap. Yes, we can get a lot more storage space for our money today, but the I/O speed hasn't kept up at the same pace. So, when an application database team requests an order of magnitude additional space, the real concern shouldn't really be cost but rather how the unexpected usage and growth rate impacts performance.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 11, 2015 at 8:00 am
Disk space actually isn't cheap if you have no more space in a rack and have to meet the corporate standard of "all disks must be properly racked in a SAN or iSCSI appliance". 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2015 at 8:06 am
In many fields, the difference between the textbook exercises in school and the real world is exactly that: you have no good information to go by. There are gaps, uncertainties ("things we don't know and things we don't know we don't know"). Whether DBA, engineer, contractor or mechanic, experience and an intuitive sense of where things are likely to be going can make all the difference.
...
-- FORTRAN manual for Xerox Computers --
August 11, 2015 at 8:08 am
Xavon (8/11/2015)
IT needs a more general version of Hofstadter's law. That is why when asked to estimate time, I generally add a 150% pad (100% for issues during dev, 50% for issues found in QA). For horsepower, triple it, and for storage go with 10X. If you think it will be 5GB, but you tell them 50, then when it is only 20 you have room to grow. Or if 50 isn't enough you can tell them you only expected it to be 5 and were giving yourself space.
Not sure who Hofstadter is/was. Have to look him/her up.
We just always called it "The Scotty Factor" named for the immortal character Montgomery Scott from Star Trek.
I think somewhere in an episode/movie he told someone that if you triple the actual time and manpower something takes and do it in half the time and half the manpower, you look like a genius.
But, I've always padded time and resources for a project by 1.5-4.0x (depending on length, complexity, manpower, number of unknowns, etc.) so that it reduces the likelihood of surprises that cause a full halt to a project that needs to be put in place.
Or as my parents always taught me: better safe than sorry.
August 11, 2015 at 8:18 am
jckfla (8/11/2015)
Xavon (8/11/2015)
IT needs a more general version of Hofstadter's law. That is why when asked to estimate time, I generally add a 150% pad (100% for issues during dev, 50% for issues found in QA). For horsepower, triple it, and for storage go with 10X. If you think it will be 5GB, but you tell them 50, then when it is only 20 you have room to grow. Or if 50 isn't enough you can tell them you only expected it to be 5 and were giving yourself space.Not sure who Hofstadter is/was. Have to look him/her up.
We just always called it "The Scotty Factor" named for the immortal character Montgomery Scott from Star Trek.
I think somewhere in an episode/movie he told someone that if you triple the actual time and manpower something takes and do it in half the time and half the manpower, you look like a genius.
But, I've always padded time and resources for a project by 1.5-4.0x (depending on length, complexity, manpower, number of unknowns, etc.) so that it reduces the likelihood of surprises that cause a full halt to a project that needs to be put in place.
Or as my parents always taught me: better safe than sorry.
Hofstadter's law is : "Everything takes longer than you plan, even when you take Hofstadter's law into account."
We like to use the phrase 'under promise, over deliver'.
August 11, 2015 at 8:35 am
jckfla (8/11/2015)
Xavon (8/11/2015)
IT needs a more general version of Hofstadter's law. That is why when asked to estimate time, I generally add a 150% pad (100% for issues during dev, 50% for issues found in QA). For horsepower, triple it, and for storage go with 10X. If you think it will be 5GB, but you tell them 50, then when it is only 20 you have room to grow. Or if 50 isn't enough you can tell them you only expected it to be 5 and were giving yourself space.Not sure who Hofstadter is/was. Have to look him/her up.
We just always called it "The Scotty Factor" named for the immortal character Montgomery Scott from Star Trek.
I think somewhere in an episode/movie he told someone that if you triple the actual time and manpower something takes and do it in half the time and half the manpower, you look like a genius.
But, I've always padded time and resources for a project by 1.5-4.0x (depending on length, complexity, manpower, number of unknowns, etc.) so that it reduces the likelihood of surprises that cause a full halt to a project that needs to be put in place.
Or as my parents always taught me: better safe than sorry.
Poor Scotty. It seems like in every other episode Captain Kirk is demanding "Scotty, we need more power!" while the Enterprise gets slammed by Klingon disruptors or some other crisis.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 11, 2015 at 8:37 am
Steve, this topic is one of the few where I haven't completely understood what you're saying. For that reason I might answer it wrong, and answer the wrong question. I'm sorry if I do.
I've been in my job only a few months. I've not been in any project planning yet, just haven't been here long enough to have been involved in such a thing. But what I have seen is that this organization is solidly committed to the Waterfall methodology of project management. There are very powerful politics that will not be denied; it's waterfall and nothing else. Therefore I can only imagine (since I've no experience at project planning in this organization yet) that time estimation is extremely important and failing to meet estimates will not be easily tolerated. Therefore I can only imagine that a lot of time goes into estimating how long it will take to do anything.
Kindest Regards, Rod Connect with me on LinkedIn.
August 11, 2015 at 8:52 am
Scotty did say that but it was to Geordi LaForge (not sure on spelling) when he was on Star Trek Next Gen. I only remember this because I have a great memory not that I watched every episode at least twice.
On another note it is always better to under promise and over deliver so I always pad pad and more pad. I have found that I usually need the first 2 pads anyway.
August 11, 2015 at 9:03 am
I almost shouted an audible "AMEN!" when I read today's editorial.
I have found the most difficult part of making educated guesses is getting enough information to even start[/b] with.
Requester: We need a database for our new client/project/application/latest-management-shiney.
Me: No problem! How big is the estimated initial data set going to be within the first year?
Requester: We don't know.
Me: Okay, how many users/records/transactions do you expect on a daily basis?
Requester: We don't know.
Me: Uh, okay. Then what type of data will this database be holding? XML, large text fields, instrument telemetry, images?
Requester: We're not sure yet.
Me: Unfortunately then I can't really help you yet.
Requester: But we have to have the project/cost/ROI estimates by tomorrow!
Me: ...
Requester: Okay FINE! We'll try to answer some of your questions. I guess we have some time, the go-live deadline isn't for another 3 days.
Me: <Eye twitches>
And if disk space is so cheap then how come we can never get it in the budget?! Management-"But we just bought you disk last year!"
And @jckfla - You are dead on with "The Scotty Factor".
August 11, 2015 at 9:26 am
jckfla (8/11/2015)
Not sure who Hofstadter is/was. Have to look him/her up.
.
Hofstadter's book Gödel, Escher, Bach ranks at the top of my book list. Entertaining and inter-related dissertations on logic, mathematics, philosophy, music, art...
...
-- FORTRAN manual for Xerox Computers --
Viewing 15 posts - 1 through 15 (of 44 total)
You must be logged in to reply to this topic. Login to reply