Shamil Salakhetdinov
shamil at users.mns.ru
Wed Apr 5 15:27:08 CDT 2006
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