MartyConnelly
martyconnelly at shaw.ca
Wed Apr 5 15:53:41 CDT 2006
I pre-stole it from a prof at University of Victoria. He was teaching Project Management after retiring as a Project Engineer at Boeing. He worked on the 747 Aircraft line. It was good to be taught by a guy who had done it for real for 30 years. Shamil Salakhetdinov wrote: >Marty, it's a great simple story about the fence building - I will borrow >it from you to tell to my customers - OK? :) > > > >> a day per form and two days per report (I'm not >>good at reports <g>). >> >> >I'd roughly estimate 4 (four) days per form with "smart" user-friendly >behavior or report whatever it's in the final system when a lot of advanced >queries and coding is involved and when customer's requirements and >understanding of their own business area and what they wanted to get from an >application developed for them are unclear to say the least (and even if >they have huge BDUF specs this often isn't a sign they know their own >business and what they wanted you to have developed for them in the end). > >I mean if the final system is roughly planned to have, say, 100 forms and >reports then its development(all the objects including database model, >documentation etc.) can be roughly estimated as 400 man/days ~= 17man/months >(22.5 workdays/month). Based on that rough estimation fixed cost can be >calculated. >If they(customer(s)) are ready to pay that in the end - fine - prepare more >detailed plan and start working delivering regularly parts of the >application. If you'll be ready quicker - get a bonus and leave them the >rest of the fixed price. If you will (soon) find that even that time isn't >enough to deliver what they are now see absolutely different than in the >beginning - explain them what happens, trade the new fixed price - if they >agree - continue, if not - quit - it promise to be "endless" story for you >and for the customer, which will end sooner or later without any >satisfaction nor on your nor on their part... > >Of course working on hourly rate as many say here is more realistic approach >but 4 days per form/report for advanced applications seems to work rather >well - just from real life experience... > >Shamil > >----- Original Message ----- >From: "MartyConnelly" <martyconnelly at shaw.ca> >To: "Access Developers discussion and problem solving" ><accessd at databaseadvisors.com> >Sent: Wednesday, April 05, 2006 10:40 PM >Subject: Re: [AccessD] Access Application - per unit cost > > > > >>I used to explain this to clients via the fence post analogy for >>undiscovered problems. >> >>A man wanted to install a new fence, to keep his kids from wandering. >>He would build the fence himself but to save time he would get a >>contractor to dig the post holes. >>The contractor submitted a bid for digging 10 post holes >>but the man wanted it broken down to the unit cost of each post hole >>and would pay accordingly. The contractor agreed. >>On digging the tenth hole a huge boulder was encountered and the >>contractor >>gave up, after realizing it would take several days to remove the boulder. >>So the contractor submitted his bill for 9 post holes, leaving the man >>to find a way of removing the boulder. >> >>Just remember that 90% of the job was completed easily but the final 10% >>was going to be a real bear. >> >>Here is a quote from Rebbeca Riordan a longtime Access Developer >>"And the number of objects absolutely comes into the estimate for the >>fixed-price component. What I used to do when I was churning out systems >>full-time was start with a day per form and two days per report (I'm not >>good at reports <g>). Nothing for tables, since I do the schema as part >>of >>the analysis. Then to that base, I'd add a modifier -- this is a really >>simple form, so figure .04; that's a difficult report, so 1.5, and so >>forth. >>Then there's documentation -- if they want user docs, I figure 150% of the >>development time. Clients _hate_ that, but documentation is >>time-consuming, >>and ultimately, even if you're working fixed-price, you calculate based on >>an hourly rate. I won't do hands-on training, so I can't speak to that, >>but >>I if they want a training guide, it's the same price as the user manual. " >> >>Good bock on the subject >>Rapid Development : Taming Wild Software Schedules >>by Steve C McConnell >> >>PS. I knew one British Access Developer who used to estimate >>by the simple means of 5 pounds per field on a form and used to >>come quite close to the actual cost. But then he had a large toolbox >>of previously written code. >> >> >> >>Barbara Ryan wrote: >> >> >> >>>I have been working on an Access application for several years. My client >>>has asked for a "per unit cost" for the development of this application, >>>although he is unsure what "unit" is most meaningful (e.g., database >>>object, lines of code, etc.). >>> >>>The database functions vary tremendously in their complexity --- e.g., >>>some reports are very simple while others contain several subreports, >>>and/or output spreadsheets or files. The database contains lots of VBA >>>code. >>> >>>Are there any white papers, etc. that address this issue? In your >>>opinion, what is the best method of computing a "per unit cost"? >>> >>>Thanks, >>>Barb Ryan >>> >>> >>> >>> >>-- >>Marty Connelly >>Victoria, B.C. >>Canada >> >> >> >>-- >>AccessD mailing list >>AccessD at databaseadvisors.com >>http://databaseadvisors.com/mailman/listinfo/accessd >>Website: http://www.databaseadvisors.com >> >> > > > -- Marty Connelly Victoria, B.C. Canada