I am new to database design and in some ways may not even have any business making databases, but I am giving it a go and have a potential client who wants an estimate for a job.

Is there a format/template that anyone could recommend for making a quote or estimate for a job. The bottom line will probably be around $25K, so its not a small job and I want to make a thorough estimate.

Briefly, the job is a language school in Europe that needs a database to track its student body data, from application and matriculation, to tuition payment, housing details and finally to departure.

Any advice is much appreciated.

I usually don't include much about the technical details of a solution in my quotes. For example, I will not outline things such as table names, functions etc. I generally break things down as such:

Basic project requirement outline
Plain-english description of the proposed solution
Logistics and schedule for receipt of deliverables
Project Breakdown

• Initial Planning/Requirements Generation - This is the money part. All of the following are listed in hours
• Project-specific planning steps go here. If there's specfic meetings or extensive commuting required, this is where you track those hours. I usually go something like "Acquire overview of project and specific requirements" and "Additiona/misc refinement of project criteria". You'll need some slush room here, everytime.
• Back End Design/Development - Fairly self explanatory. This is where you detail how many hours or percentage of resources will be thrown at developing the actual back end as well as testing your datamodel.
• Client Front End Design/Development - Again, fairly self explanatory. I usually include a few hours for gathering process information and focus groups in here. Development of application flow would go in here. Of course the actual development itself and testing as well.

There are probably much better templates out there and I welcome you to share what else you find. A good proposal can make all the difference, I'm CONSTANTLY looking for better ways to construct mine.

Hi Teddy,

That is very helpful, and very generous. Thank you for taking the time to write out those ideas. I'll try it out and maybe respond with more questions.

And by all means, I'll let you know if I come up with something useful to share.

This might be a dumb question, but it appears from what you posted that you actually itemize the proposal to some degree.

Do you find that clients need that part? Or is it more for your own information?

It is most definately for the client's benefit. I have submitted a few proposals with a ball park hours estimate and invariably receive a request for itemization of hours quoted. Client's like to know WHAT they're paying for as well as HOW MUCH they're paying. I try to put that right up front.

It also helps for cost-justification on my end. A lot of clients don't realize how much of the average consultants time is spent in the planning and design phase, often involving many hours of face time with their employees or internal clients. I've run into more than one entity that felt IT solutions should simply be ordered and delivered. My breakdowns help the lay-person understand the full projected life-cycle of their project.

interesting. i am starting to think that my potential client is not such a good first client. tell me what you think.

the client is a school in europe. their consultant is my primary contact, and he imagines it to be that i will only work through him... but the end-users are administrative staff at the school in europe. i will have minimal time with the actual users, only him...

what is your impression of that situation? he has mentioned travel as a poss., and i 'm thinking that i need to insist on it.

If you are going to be paid by the consultant, then that's all that you need to worry about. The consultant is then your customer, and all you need to do is keep your customer happy with your work.

If you are going to be paid by the school, that's a very different story.

-PatP

Indeed. The fact that your client is working with a school means nothing to you. Not unless he wants you to speak with them.

Of course, this bottleneck in communication will probably tack a few hours on to your planning phase as you will have to marshal specification requests through an intermediate...

I wrote a very similar web based application for something exactly like that. the app is completely web based. it covered student grades, housing, tuition, testing and a variety of other things. I can show you some basics of it if you want. I can probably help out if you want, possible even do some sub contracting, or be a consultant to you. I have been designing software for 24 years.


so, who is paying you, the school or him ?
is your billing being done by the hour, or are you going to flat rate it ?

are you making an online database/ website ? or a client server VB App ? or single PC VB app ?

if you are making an online website/database, are you expected to make it with a pile of graphics and flashy ?

will this be strictly used by the school administration, or will this be also used by the students to do self help, lookups, and inquiries ?

I have found that most programmers are very aggressive on time estimates. while they may have the skills to do it, they often overlook the "oh shit" factor and the MANY.. "oh by the way" 's of the client, plus of course the "oops's" that life throws at you, like the hot water tank blowing up on a Friday afternoon when you wanted to work on this project alone all weekend long.
so whatever amount of time that you estimate it will take you to do this. double or triple it.

the estimate should also spell out several things.
1) what it includes
2) what it does not include
3) what it can include as an additional fee
4) what it is not going to include regardless (work you are not willing to perform)

examples :
#1
will test with windows version xx and xxx
will include 5 phases of user approval (spell out each phase)
will be tested with version x of IE, version xx of Firefox

#2
does not include unlimited updates after final build, delivery and approval.


#3
additional modifications not expressed during the 5 phase approvals can be included for an additional fee.
rebuilds and annual maintenance (including maintaining product compatibility with other installed software) may be added for an additional fee
(important, like if the client installs a new database driver and your app blows up, its not your fault)


#4...
contractor will not perform work to modify firewalls
contractor will not be responsible for additional networking


you need to have a "payment for work performed" clause, or a "cancellation" clause
if you start working on the project, and they cancel out on you after you have xxx many hours in, you get paid for those hours you spent working on this.
"client may cancel this project prior to 10 hours of work having been performed without additional compensation. after 10 hours the flat rate of $$ per hour will be bill for all time actually spent on this project if project is cancelled"


your "multiple approval" phase :
create an actual sign off form where it requires multiple signatures that the end users have to review a revision of information you provide to them and they sign a form saying it is accurate and nothing is missing. if anything is missing, the form is signed as "requires the modifications listed" and have all mods requested listed.

your first "client approval" should be a list of all of the data fields they want to keep track of , a description of what each data field represents and a cross reference of what fields trigger or interact with or depend on other fields. Use diagrams.
This is important. It is almost guaranteed that after you get like 50 hours into design, they will come back and say "oh by the way... we need it to keep track of (blah blah blah)". when they do then you start the approval phase over again. Include the changes and then go back for approval. You need to establish some type of cut off points, or "change/modifications fees" otherwise the clients may be changing their minds constantly as to what they want... or forever expanding the scope of the project .

After all fields are approved, then you need to possibly sit with the end users and design the screen layouts of how they want the information presented.

Your 2nd client approval should be screen layouts.
How the information will look on the screen. This is important as again after you start designing the thing and show it to them, they will almost guaranteed say "this field needs to be on this screen too. And that field need to come before this other field. Field 4 can only be this, if field 2 is this option.
You should present every page layout that you can think of to capture the data necessary,

After you have these 2 primary approvals out of the way.. then you can start thinking about the database design. Table structure field locations, cross references and dependencies.

Schools (at least the ones I have dealt with) are notorious for delaying payments until they are "approved by the board" or "approved at the meeting" which they mysteriously sometimes forget to address payments of services due during the period. I had one school account hold me off for almost 3 months for 50,000 and it damaged my relationship with my supplier. They killed my net terms.
You should also consider some type of incremental payments at each of the client approval phases. If you have 5 approval phases, plus final delivery, then you might have 7 payments total. 1 deposit, 1 payment for each of the 5 stages and 1 at final delivery. With the bulk at the end, or progressively larger towards the end.

This is all just off the top of my head... I have a proposal for 1 client that was like 40 pages long.
Hope this helps.....

I have returned here after leaving one post and I wanted to revisit this thread to say thank you to all the people who spent time answering my question back in January. I know, a long time ago. But still.... thanks a lot. It was helpful information.

I ended up applying for a desk job, and got it, so no consultancy for me.

Hasta luego,

dmj