Possibly look at a web based database.
This part cannot be done with Access alone. You COULD have an Access front-end for control and management, but there is currently no easy solution to use an Access back-end on the web. Not saying impossible. I said "not easy" and meant exactly that. In theory, it IS possible to specify an ACE engine as the target of a web page doing lookups. In theory... but I have not seen any practical cases mentioned that didn't have massive limitations.
What is much more common is to find some type of ODBC back-end that both web pages and Access forms can see from separate apps. Many others have suggested SQL Server or some other SQL-based active back-end. I have to concur. The problem with government systems is the extensive record-keeping typically required and that means you have to employ a system that doesn't fold every 2 Gbytes. SQL Server has a very high capacity. I know the U.S. Government also likes ORACLE, and they have a pretty good capacity, too.
Can anyone give me any advice or examples, on how to write a good SOW for the creation of a database and some ballpark figures on what it would cost?
When writing a statement of work, you need to consider various phases and aspects of the work. Working BACKWARDS with regard to the project, ...
1. You need to define clear and very specific goals i.e. explain exactly what must be delivered, in what form, with what function, and
with what ownership. If you skip the "code ownership" part, the moment you touch the code, you might get hit with breach of contract. So you have to reference salient parts of the U.S. Copyright Act of 1975 (and parts as subsequently amended.)
2. You need to include estimates of required system capacity short-term, intermediate-term, and long-term, with provisions for archiving where needed to minimize the size of the working files. You also need to address minimum acceptable speed for certain processes, which probably would reflect back to the minimum network quality and speed that you would have to obtain or provide. You would also probably have to provide the platforms for this project unless you are asking your vendors to provide hardware too.
3. You need to specify interface attributes, as in "What do you expect users to do with this product?" You also need to specify interface attributes with other government agencies because they probably WILL NOT want ODBC connectivity. With the U.S. Navy, we always exported files in .CSV format because it was the lowest common denominator among some of the agencies (eighteen in total) that had to exchange data.
4. Where regulatory statutes apply, you must explicitly include either the statutes themselves, or (as was typical for U.S. Navy), a reference to the Standards Documents that were applicable to the project. At the Naval Enterprise Data Center/New Orleans, we typically would see references for at least a couple of dozen sections of U.S. Code, all of them "included by reference." Since you are talking Bureau of Indian Affairs stuff, I know for an ever-loving hard fact that you will have lots of U.S. Code references.
5. Other than references to U.S. Equal Employment Opportunity regulations (see my point #4 above), you should not deal too much in exactly how the winning vendor would populate or manage the production team. Otherwise, you will end up micro-managing the vendor, which is guaranteed to run over budget and schedule as the vendor has to schedule "progress" meetings. Trust me, in that context, progress and Congress are the same. Neither one gets anything done on time or under budget.
6. You kill your chances of ever getting a sane contractor to bid on this at all if YOU offer the ballpark figures. However, until you have the detailed statement of "desired end product" there will be no way for any sane person to make such an estimate. But it is worse than that. Do YOU know all of the applicable regulations and how they will affect estimators in the various companies? All of the regulation requirements will ONLY slow down the project since the bidders will have to include a "compliance validation" position or an increment of hours for such validation. Add anywhere from 5% to 15% overhead right there, depending on just how many compliances you specify.