This seems like the type of application Access was made for, one person app, not a programmer creating it. I would store the file path to objects such as documents, images etc, rather than the actual image. Consider also having a table that stores standard language you might frequently reuse. We did an application to do something like this in my last job and it was quite a bit more work to get it to spit out formatted proposals than you might think (especially if the format varies for RFP to RFP which it can do, same information basically but rearranged). Once it was done, it was easier to do the proposals, but don't think this will be a simple, fast task.
If you separate the backend and the front end and people never work on the same proposal at the same time, you can avoid the problems that Robert mentions. We gave a copy of the front end Access file to each user rather than use a network copy (the backend was on the network, our backend was a SQL server database) and set up a system, so that if they didn't have the most current configuration of the Access front end, they could not open a proposal. That meant everyone had to upgrade when a new version came out and helped keep problems from arising if out of date versions were used. We did this with a local read only table in each person's copy that carried the configuration number of that copy that had to match a backend table that had the most current configuration number in it.
One thing to make sure of is to use a primary key in every table whether you think you need to or not. Access is very picky about updating records unless there is a primary key.