The Project Specifications Document
Documentation is a lot like flossing. Done with regularity and diligence, it can stave off a disaster, but it’s immensely tiresome, and the negative effects of neglect aren’t immediate. Unless it’s a deeply ingrained habit, we tend to avoid it.
The most crucial type of documentation is the kind that’s written before a new project even starts: the Project Specifications document, or Specs. A good Specs can save a company boatloads of time and money, and can even be fun to put together. It’s also an absolutely essential step before beginning to build any large-scale programming, design, or other engineering project.
Software developer and entrepreneur Joel Spolsky worked at Microsoft before founding his own company, and has been writing essays at Joel on Software for nearly a decade. He has written a superb series on Painless Functional Specifications that I strongly recommend. It’s in four parts:
- Part 1: Why Bother? — Joel explains exactly why Specs are so crucial, even though engineers tend to regard them with wariness.
- Part 2: What’s a Spec? — A look at the document itself, including a fun Sample Specs for a silly application.
- Part 3: But… How? — By designating (or hiring) a Program Manager! Joel explains how this position works.
- Part 4: Tips — The task is only as daunting as you let it be. The final entry contains tips to make it painless.
Specs are especially important for non-technical owners and managers whose company is about to embark on a technical project—like a Website redesign, or building a new sales database. Without a high-level Specs that you can both understand and sign off on, you’re just inviting your project team to spend their time—and your money!—inefficiently. Be sure to insist on a Spec from the project leader before any actual development work begins, and you’ll save yourself a guaranteed headache (or toothache) in the future.
Welcome to 
