st because a network is small enough for you to memorize every IP address doesn't mean it should not be documented. Requirements Documents One of the things you should do at the start of any project, regardless of your percep- tion of available time, is write a requirements document. This document should include all the requirements for the project as you understand them, as well as any and all assumptions being made. Even if the requirement is simply "design a new corporate network," write that down, and include all the assumptions that you'll be making to accomplish that goal. When you've finished your requirements document, send it to everyone who's involved. This list should include your boss, at an absolute minimum. Depending on the corporate culture, you may also wish to include project managers, the VP who is responsible for funding the project (the sponsor), and anyone else involved in the process. Your boss may wish to forward this document to the other parties instead of having you send it to them directly. Either way, you need to publish something that dictates what you will be designing and why. Writing a requirements document is one of the best things you can do to protect yourself later on when the project scope changes. The scope will change. I can't think of a single project that I've worked on where it didn't. Scope change is a fact of life with projects. For example, if you order a T1 for Internet connectivity, and the VP gives you grief because he doesn't think it's enough bandwidth, you should be able to point to the requirements document that you published at the beginning of the project (which hopefully backs up your decision). This takes the heat off of you because you sent out a document describing the needs being met by your design. If he didn't know about the T1, he didn't read the document. A requirements document does not need to be large or complicated-in fact, the simpler the document is, the better chance it has of being understood. All points should be made as simply as possible (e