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
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)
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
does not include unlimited updates after final build, delivery and approval.
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)
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.....