RE: [U2] Estimating Timelines
Analysis, design, and testing always take longer than programming. Even with a code change of one line you may take a lot of time analyzing the problem and the best way to fix it. Jerry Banker > -Original Message- > From: John Rodgers [mailto:[EMAIL PROTECTED] > Sent: Friday, March 07, 2008 4:01 PM > To: u2-users@listserver.u2ug.org > Subject: [U2] Estimating Timelines > > Snipped from Louie's contribution on the Include Wierdness > > - I have noticed that some programmers inflate their estimates by > 10 > times, just so they will look good finishing early. We have to > beaccurate, without lying. > > > Speaking for myself, this is usually necessary because today's > applications are so complex that all the dependencies are impossible to > forecast. > > It is not a question of lying - it is a question of trying to > anticipate > the worst case. > The first estimate you give is the only one that "management" (your > customers) will ever remember. You can explain the changed > circumstances until you are blue in the face - it makes no difference. > The customer cannot see the issues. You are late in delivering. > > > A good example just occurred today. > > Set up a control flag for particular function. > > Easy enough - we already have a screen for these things - just add one > field > Should be about an hour. Tops. No big deal. > > Add the field and test it. > SB+ spits it back at me with a "matrix out of range" error. > > These are linked screens - we are on the fifth screen. > I smell a big problem. > > I create a sixth screen and put the field on that additional screen. > Now I get a different (more informative) message. "Too many fields on > linked screens". > > As I suspected - we have hit the limit of this arrangement. We are on > an > old version. > > Now I have to totally re-design this set of screens. > With Page forward and back keys > Don't forget the Inquiry mode - How do I make those use the same screen > defns? > Make sure it functions "exactly" as it did before - it does not want to > because the sub-screens are a different herd of cats. > > Now, how much time should I have estimated for this task? > And this is not unusual. > > Does anyone out there have any thoughts on THIS issue? > I think it (estimating timelines) is one of the more difficult tasks we > face. Especially when interfacing to an existing mature application. > Coding is the easy part of this job. > > > Cheers > > > JR > > > > > > > > > John Rodgers > > Masonite International > > Tel: (813) 2612396 ext 3036 > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Estimating Timelines
I have to weigh in on this in support of everything stated so far. John is right, the first estimate is the one that "sticks" so that estimate has to factor in what is known about the problem, solution, and path at the time the estimate is requested, which is often before any real discovery has taken place. The less information known before the estimate, the higher the estimate will be, if for no other reasons than to make sure everyone is covered with no surprises. And of course, while customers will do their best to give all of the information needed at the outset of the task, the reality is that any and all information needs to be weighed against some kind of objective review to ensure that the information is accurate and complete. In fact, I believe that ensuring that all of the important information is on the table is a real art form! (I mean, hey, that's what discovery and analysis are for, right?) And as Jerry said, there can be a lot of time invested in those tasks. Asking someone to estimate a complete job - which includes the discovery and analysis needed to estimate the remainder of the tasks - without having those tasks completed in advance is pretty much asking for an unknown on a fixed timeline, which is as close to an impending failure as one can intentionally get. For the past several years I've been taking a multi-stage approach to the larger projects. Certainly on a smaller project I've finally gotten to a point where I can spitball an estimate pretty reliably, but on the big ones I'll estimate the discovery separate from the analysis separate from the implementation+testing+installation. And of course, documentation is also estimated separately. Most customers - to date - have been pretty happy to give me a small budget for discovery knowing that it pays big dividends in more accurate estimates for the rest of the project. And accurate, on time, and on budget makes everyone happy. -K http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Estimating Timelines
I've been meaning to blog on this for a while, thanks for the opportunity: removepleaseNebula-RnD.com/blog/general/2008/03/estimates1.html > From: John Rodgers > Speaking for myself, ... today's > applications are so complex that all the dependencies are > impossible to forecast. It is not a question of lying - it > is a question of trying to anticipate the worst case. The first > estimate you give is the only one that "management" (your > customers) will ever remember. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Estimating Timelines
I have found the double principle always works quite well and ends ups accurate enough to keep all parties satisfied. Do all your research, planning, etc and finally take that bottom line number and double it. So, if you say a project will take 5 working days to complete, present it as a 10 day project. This allows time for unanticipated factors, and allows a little extra time to clean and tighten up the final product. I have consistently found this to allow me enough (yet not too much extra) time to complete a task properly and has given the end users/customers a satisfied feeling of time allotment. Cheers, Barry Rogen PNY Technologies, Inc. Senior Programmer/Analyst (973) 515 - 9700 ext 5327 [EMAIL PROTECTED] - Far better it is to dare mighty things, to win glorious triumphs even though checkered by failure, than to rank with those poor spirits who neither enjoy nor suffer much because they live in the gray twilight that knows neither victory nor defeat.t. roosevelt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony G Sent: Sunday, March 09, 2008 4:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Estimating Timelines I've been meaning to blog on this for a while, thanks for the opportunity: removepleaseNebula-RnD.com/blog/general/2008/03/estimates1.html > From: John Rodgers > Speaking for myself, ... today's > applications are so complex that all the dependencies are > impossible to forecast. It is not a question of lying - it > is a question of trying to anticipate the worst case. The first > estimate you give is the only one that "management" (your > customers) will ever remember. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ 10/3/2008NOT INTENDED AS A SUBSTITUTE FOR A WRITING NOTHING IN THIS E-MAIL, IN ANY E-MAIL THREAD OF WHICH IT MAY BE A PART, OR IN ANY ATTACHMENTS THERETO, SHALL CONSTITUTE A BINDING CONTRACT, OR ANY CONTRACTUAL OBLIGATION BY PNY, OR ANY INTENT TO ENTER INTO ANY BINDING OBLIGATIONS, NOTWITHSTANDING ANY ENACTMENT OF THE UNIFORM ELECTRONIC TRANSACTIONS ACT, THE FEDERAL E-SIGN ACT, OR ANY OTHER STATE OR FEDERAL LAW OF SIMILAR SUBSTANCE OR EFFECT. THIS EMAIL MESSAGE, ITS CONTENTS AND ATTACHMENTS ARE NOT INTENDED TO REPRESENT AN OFFER OR ACCEPTANCE OF AN OFFER TO ENTER INTO A CONTRACT. NOTHING IN THIS E-MAIL, IN ANY E-MAIL THREAD OF WHICH IT MAY BE A PART, OR IN ANY ATTACHMENTS THERETO SHALL ALTER THIS DISCLAIMER. This e-mail message from PNY Technologies, Inc. is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Estimating Timelines {Unclassified}
And then, you have the "client factor", as in * Work out a rough estimate * Double it * And multiply this result by the "client factor" to give the actual estimate You know what I mean, * If you ever find such a beast, a really good client that knows what they want and is capable of articulating that, gets a "1" or "1=" * The average clueless client gets about a "2" or "3" * Anyone with 'President' or 'Director' in their job title gets at least a "5" * And we all have those 'Oh, maybe I forgot to mention ...' clients that definitely rate a "10" Yeah, I'm getting cynical in my old age Regards Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: Saturday, 8 March 2008 12:28 p.m. To: u2-users@listserver.u2ug.org Subject: Re: [U2] Estimating Timelines I have to weigh in on this in support of everything stated so far. John is right, the first estimate is the one that "sticks" so that estimate has to factor in what is known about the problem, solution, and path at the time the estimate is requested, which is often before any real discovery has taken place. The less information known before the estimate, the higher the estimate will be, if for no other reasons than to make sure everyone is covered with no surprises. And of course, while customers will do their best to give all of the information needed at the outset of the task, the reality is that any and all information needs to be weighed against some kind of objective review to ensure that the information is accurate and complete. In fact, I believe that ensuring that all of the important information is on the table is a real art form! (I mean, hey, that's what discovery and analysis are for, right?) And as Jerry said, there can be a lot of time invested in those ta! sks. Asking someone to estimate a complete job - which includes the discovery and analysis needed to estimate the remainder of the tasks - without having those tasks completed in advance is pretty much asking for an unknown on a fixed timeline, which is as close to an impending failure as one can intentionally get. For the past several years I've been taking a multi-stage approach to the larger projects. Certainly on a smaller project I've finally gotten to a point where I can spitball an estimate pretty reliably, but on the big ones I'll estimate the discovery separate from the analysis separate from the implementation+testing+installation. And of course, documentation is implementation+testing+also estimated separately. Most customers - to date - have been pretty happy to give me a small budget for discovery knowing that it pays big dividends in more accurate estimates for the rest of the project. And accurate, on time, and on budget makes everyone happy. -K http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Estimating Timelines {Unclassified}
Several years ago I worked for a Consulting firm that gave weekly classes on job estimation. What you are calling the client factor, they called the confidence factor. It is real and very useful. >>And then, you have the "client factor", as in >>* Work out a rough estimate >>* Double it >>* And multiply this result by the "client factor" to give the actual estimate Charles Shaffer Senior Analyst NTN-Bower Corporation --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
