Hi EB,
If there are any "industry-standard" network monitoring methods, I am not aware of them: just general guidelines.
First of all, if the network you're walking into is undocumented, that will be your first order of business. Nothing else will make sense until you know the topologies you're facing, is it a switched or shared environment, and the products.
A tool that may take some of the leg/grunt/guess-work out of this is 3com's Network Supervisor. The basic version is available for just the hassle of registration. It will discover your network and try to group your nodes according to the switches/hubs they're attatched to. If your infra-structure happens to be 3com, it works great: it even gives you the port and unit number devices are connected to and the speed/duplex settings. If the infra-structure is another vendor, it does the best it can, and can still be helpful for getting the overview.
Once you get the 50,000 ft view, you'll need to verify as much as possible: especially where the uplinks are and what their capacities are (10/half, 100/full, gig etc) and who's connected to who. You'd better start drawing up a map.
You'll also need to find out about existing VLANs etc. It's going to mean a lot of logging into the network devices and reviewing configurations.
Once you know how the network is segmented, you can start thinking about looking at traffic patterns on the different segments. This is a little tougher in a switched environment than a shared environment. This is a good place to have a decent management package. I use Network Instruments Observer, which is a servicable product. It can loop through the ports of most switches and give you a good over-all view of the traffic on each. Placing probes at a couple strategic points of the network, with a roving probe you can move around, can give you a pretty good look at your traffic patterns. Such packages also usually come with error detection, broadcast storm detection, etc. There are lots of other packages out there. I won't carry forward with that discussion as you didn't mention what, if anything, you had available to you.
If you have no software or hardware management tools or sniffers, you'll have to start with stats available on the network devices. Start at the center of the network (presumably there will be some sort of central network switch) and view the statistics for it's ports. Pick out any that have a lot more traffic than the average, or that show errors, and start following those through the network to see who they're supporting and where all of the traffic is comming from. If a lot of errors are showing, try to follow them through the workgroup devices to specific ports - usually the port with the highest counts will be the source, although switch settings can disguise the guilty parties by passing errored packet through and making everyone look guilty.
Ultimately, it's going to be about becoming familiar with your traffic patterns. There are no concrete rules that say "traffic levels less than 10% are ok". It depends on your topology and your applications. If your users are complaining that things are slow at 15% utilization, you have to fix it regardless. If you're running 40% on a switched segment and no one is complaining, all you have to worry about is future growth.
As far as expansion goes,as in the instance of expanding to a new floor. It's going to be the same groceries. First you'll have to find out who is going into the new section, how many ports they represent, what the current traffic patterns of those users are. Then you'll need to find out what existing infra-structure is available, if any. If you have to provide cabling and all, then the size of the area and the distance from the center of your network have to be examined, the ole 100 meter rule. If you have long distances to contend with you'll need fiber, otherwise, CAT-5E or CAT-6. Selection of links from workgroup switches, how many links per stack, how many ports per stack, etc are going to depend on the traffic patterns you noted for the people going into the new areas.
I realize this information is very general. Without more detailed information, it must be. Also, I apologize if I'm providing information that is too basic. You didn't specify your degree of experience.
