To do this right, you must work backwards a bit and must also think about normalization rules a bit.
The biggest issues are going to be "What questions will you need to ask?" You have indicated that you wish to do some sort of totals, perhaps broken out by departments.
In practical terms, this means that there must a distinct data element in the table to support asking the question. I.e. if you want a breakout by department, then at least a department code must be part of the record. If you want all questionnaires to be anonymous then you must NOT have a name or personal identifier in the record. (In that case, you would use an autonumber field to assure unique record identification.)
If all departments get the same exact questionnaire, and the only possible answers are Yes, No, and Shrug, then I would perhaps build a "quick and dirty" record that showed the department code and one slot for each of the 20 or so answers that everyone answers. If not everyone gets the same questions, this would not work.
I would assign 20 or so INTEGER or BYTE (not LONG INTEGER) fields, one per question, and build a data entry form using an option group with values "YES" (=1), "NO" (=-1), and "SHRUG" (=0). Where of course SHRUG is all non-committal answers and is also the default value for the field.
Then you could do reports to total up the integer fields. If you have a total of X records, then you can get results either of two ways.
The simple-minded result is to sum each column individually. If the column total is X, everyone voted YES. If the column total is -X, everyone voted NO. Otherwise, you had a mixed bag.
The slightly (but ONLY slightly) trickier method is to build a crosstab wizard where each possible answer is one column and each possible question is one row. Then you would get counts of all possible responses.
Now, to get the breakouts, you just write the queries to select for department (or break on department). To do cross-correlations, make one of the other questions the selection break criterion. (Like, show me the count on question 6 for all folks who answered question 5 as YES.)
If this seems too simple-minded for you, it is because you didn't explain any other bells and whistles you might have wished to see. But just remember that earlier principle. If it ain't in the data set, you can't use it in a report.
