Question Database Work

[Bolloc]

Hi everyone, I am thinking of doing a one off job to create an Access db and am hoping to get some info on how to go about the finer details of it.

So things such as cost, how much do typical db's cost (not a complicated one) or the hourly rate to develop one. Do you have contracts that cover maintenance and warranty, and discuss whether your VBA code can be distributed or whether it should be protected.

I understand some of you cannot give away too much infomation but just a general idea would be of great help.

Thanks

 

[CJ_London]

there is no such thing as a typical db and there are many ways of charging. Only thing I would say is if a client has contracted you to build a db for them - they own the code, not you.

Hourly rates vary from a few dollars to $100+ - depends on your specific skills and experience in the particular field the db covers and what you need to earn.

With regards warranties you should have a user acceptance testing procedure in place which the client signs off. Put a time limit for completion of the testing - perhaps 3 months, maybe more. May also have a period of running in parallel with existing systems before full 'go live'.

Ask the client their budget - if you can't do it within their budget or can't build their budget for additional functionality they would value, there is not much point in wasting your time talking about it.

Maintenance - some clients prefer 'time and materials' others prefer to pay a monthly/annual fee. This may or may not include upgrades. If going for a maintenance agreement, ensure you have KPI's in place - maximum initial response time to acknowledge an enquiry with an expected resolution time, hours of work (M-F, 24/7 etc)

I typically charge 40% on commission, 40% on ready for testing and 20% after user testing is complete. If I have an ongoing agreement to maintain (either T&M or monthly/annual fee) I supply a .accde and keep the code myself, otherwise I supply a .accdb. Reason is if I am going to maintain it, I don't want others messing with it.

 

[Bolloc]

Thanks for the reply CJ.

I like the idea of producing an .accde if maintaining their db, I have developed a db before and the client had a habit of cocking about with the code and initially claiming it wasn't his doing.

As I am not established I would not be replicating your percentage rates but am thinking more along the lines of producing a working example before any monies are paid, this could be in .accde format and I could prob easily put in a time limit such that it would not work after a certain date.

So for an example of a typical db, how much would something similar to the Northwind Traders db cost?

 

[CJ_London]

no idea, you are not talking like for like. Northwind is a template, it is not a finished product. I presume by cost you mean 'sell for'. Google for similar products and see what they sell for - they will have more bells and whistles. You can always start with thinking about what you would pay for it.

In terms of cost, you need to work out how long it will take you to develop, multiply by the rate you need per hour/day whatever to come to a figure.

 

[Bolloc]

Okay thanks for your reply CJ.

 

[CJ_London]

for a client to buy an application (bespoke or otherwise) they need to be able to justify the cost to themselves - initial outlay, ongoing support - they will want to know what you have in place to cover the situation if you get run over by a bus.

So think in their terms of what it is worth to them to perhaps save time (will they get their weekends back? or can save a person, or can use that time more profitably elsewhere?), make fewer mistakes (which costs in terms of time/return shipping/additional stock), open up new opportunities (more sales), produce things cheaper (lower wastage and/or more efficient use of equipment through better planning), improved communications between staff, etc

Think also about integration - there are a lot of apps out there that are free or not expensive - but they don't talk to each other or at best only at a superficial level - and probably don't quite do what they want - they will often want a system that does it their way, not have to change their ways to conform with an off the shelf system, even if they do tend to reflect best practice.

 

[Bolloc]

As far as I can tell it is a spreadsheet problem that has gotten out of hand, the client still wants to use Excel's functionality so it is ripe for integration. I guess if you can show a solution that saves 5-10 hours per week and then multiply that up to per year then you will have a good starting price to negotiate from.

And yeah, the old 'getting run over by a bus' conundrum. There should be more Access developers about, or should there? lol.

 

[JHB]

..
And yeah, the old 'getting run over by a bus' conundrum. There should be more Access developers about, or should there? lol.

Yes, but for others to work on your code it requires that the code is well documented (also in the code) and the code is readable, ie procedure/sub names, controls, variables, etc. have meaningful names, otherwise it will often be cheaper to start from scratch again.

 

[CJ_London]

There should be more Access developers about

I've often wondered about creating a loose network of professional developers who are happy to support each others work (including applying standards for naming conventions, levels of documentation, use of common procedures etc) for an agreed range of fees to get around the bus problem. Perhaps called 'theBusGroup'!

otherwise it will often be cheaper to start from scratch again

not from the clients perspective!

 

[JHB]

... Perhaps called 'theBusGroup'!

 

[CJ_London]

the other name I had was

notUnderTheBusGroup

but a bit of a mouthful

 

[Bolloc]

If the query ever came up and you didn't wanna collaborate with the nearest Access developer outlet then I would probably see if someone on here would be your back up. As long as you can connect remotely using a common app like TeamViewer (is that what you all use?), just advertise your services, webpage or contact info in your signature and take it from there.

 

[CJ_London]

won't work I'm afraid - I'm under a bus, unable to communicate, let alone negotiate rates and availability, provide code etc.

It needs prior agreement and trust plus a common communication path for help which would initially contact the original or designated developer and if no response pass on to someone else who can meet the required SLA's.

Sometimes confidentiality agreements need to be signed and developers would need a commonly accessible location for the code. Also some of my more remote clients give me remote access via terminal server or citrix - typically this means having a fixed IP address and anyone stepping in would need the same access.

 

[Bolloc]

I don't think anything too formal needs to be arranged as most databases (if designed properly) should keep on chugging away long after any bus has made mincemeat of the creator. Just as long as there are alternative recommended developers that can be contacted to sort any new agreements, if it is a database that needs high availability then a second developer should be on standby preferably not too far away.

 

[CJ_London]

should keep on chugging away

I'm not talking about bug fixes User testing should cover that - there shouldn't be any although I accept that some bugs can take a long time to emerge with the confluence of unanticipated circumstances.

Much of my support work is around extending the system to work with new communication methods, reach other parts of the business, provide additional functionality, changes as a result of regulatory change etc.

A recent one was HMRC (UK tax) required a different report submission document to a new fixed layout and with additional information which was not stored in the db. it required designing a different report output to a to a different file type, write routines to gather data from other datasources plus develop some additional reporting and data verification routines so the client could cleanse their data.

Others include customer satisfaction analysis, need for employees to be able to work whilst disconnected from the backend, introduction of SMS texting for appointment reminders etc.

Anyway, enough on the subject, I do need to get on