Forgive me, but... On with the 'old perfessor' hat...
The first and most important part of any programming project is to make the mental association somewhat akin to the statement, "the map is the territory." You are, in some obscure way, building a mathematical model of some aspect of your business. Access happens to make this easier than some systems, but technically that is what you are doing.
Before you take the leap, if you are not familiar with normalization, I highly recommend a Google-search on "database normalization." This will return roughly a gazillion hits. Only look at reputable university articles or papers published on the web sites of well-known DB software companies. Download and study the articles that seem to you to be the easiest to understand. Skip any articles from "Joe's consulting company" or the like. They probably have web bugs all over the place just waiting to pounce on someone who NEEDS to get pop-up ads about database design services.
So start with this rule: If you can't do it on paper, you can't do it in Access. (Why? you may ask...) Because if you don't understand the problem well enough to do it on paper, Access won't help. Access is where you go once you know what you want to do well enough to program it.
The trick is to do this once on paper and see what you had to do to do it. Make careful notes of the data you had to have. Make notes on each type of computation, collation, search, sort, formula, etc. One thing I often suggest if it gets complex enough involves stuff that most offices either have or can easily afford. Get yourself a dry-marker board and assorted colors of dry erase markers. And a good eraser, unless you are the type who does crossword puzzles in ink.
Get yourself a box of sticky-note pads. Not a little pack or two. Get a BOX. A CASE. A CRATEFUL. You'll distribute the leftovers to your office-mates when done, so it isn't as wasteful as it sounds. The materials are all re-usable.
Now take that paper record of how you got to the answer manually. For every different type of entity you had to "touch" to get something, define a table. Don't be surprised if you find that you have to return to this step now and then. Sometimes the separate nature of business entities is less obvious than other times. Your normalization rules will help you identify what goes in which table. This is DEFINITELY a case where the apples and oranges rule (which gets you to 3rd normal form) comes into play.
You have talked about suppliers. Obviously, a supplier table will be one of the things you draw. You mentioned "past projects" - another table. You will probably run into a normalization issue the first time you had more than one supplier working on the same project or the first time you had the same supplier working on more than one project - or some combination of both. You will need some sort of JOIN (linking, intersection, overlap - pick your favorite word for this concept) table.
Draw the tables so that you have room to populate them with "records" drawn on the sticky notes. Be sure that you have every table populated at least with two or three records. That should be enough to support the process of walking through a query, form, or report.
Now decide what reports you want, one report at a time, and see what you are asking to see. Remember the next rule: Access can't show what it don't know. Translation: Setting up tables isn't enough. Set up the fields to support the questions you wanted to ask. I.e. if you want to summarize performance, you need performance fields.
OK, you can say this last rule was too darned trivial - but if you look at how many posts are in this forum, you will realize we've probably seen every common mistake and quite a few uncommon ones. Failing to include data to support your goals happens to fall into the 'common' category.
Are you done? Heck, I don't know that ANY Access project is ever done. Because, you see, success engenders demand. Also known as the "Field of Dreams" syndrome. "If you build it, they will come!"
We had a small personnel database back in 1988. That simple little database has gone through FIVE platform expansions and is STILL active. It started on a dedicated back-end called an IDM and is now on a full-blown enterprise-class ORACLE server (not a PC, either.) Why? Because, bless you for asking, ... it worked!
When people find out that YOU have their answers, they come to you with their questions. Like moths to the flame, you will have the unenlightened seek your flame of knowledge... (Ooops... switched over to prose mode... it's what I get for being a part-time fiction writer.)
Anyway, the ONLY solution to this is always proper preparation, something that not everyone gets to see these days. Colleges don't always expound on the costs of inadequate research ahead of time. The final rule, and forgive me for getting earthy... (Use your imagination on the substitutions) a.k.a. the 7-p rule: P|$$-poor preparation promotes p|$$-poor performance.
I hope this helps. (Time to remove the 'old perfessor' hat.)
Good luck. Be methodical. Be successful.
Whoever made this request hasn't a clue.
