Here are some recent very useful links on writing a “scope and expectation” documents, basically why its important to take the time to create a document for the client on project specifications, rather than “winging it” (thanks to Melissa at the local Portland Drupal group who sent me these)
Painless Functional Specifications - Part 1: Why Bother? - Joel on Software
I for one have been involved in lots of projects that were started on a very informal process, then had “mission creep” set in, hoping to pack anything they think of into the project. Not a good place to be for either party, actually. Having a comprehensive process for a discovering the design and structure of a website or design piece that best serves the clients goals, and writing a formal document that encompasses this in the form of deliverables as well as setting the scope of the project is a must do for any new project, and ensures a sustainable working relationship and a happy client (as well as a happy web developer/designer).
But, how far to take the general, “all at once” approach to making a specifications document, and when to generalize and when to further define what you are doing?
From the other side of the spectrum, You can’t really plan it all at once - it “makes business sense to defer details until they are needed”.
