How to use, but not abuse a Functional Spec
There's some great material in 37signal's new book "Getting Real". I just want to comment on one, "There's Nothing Functional about a Functional Spec". Lot's of spot-on points here. These are good points on how a functional specification can be used incorrectly. But there can be legitimate reasons to create and use one, if done properly.
Admittedly, the approach described in their book is typical and suffers from the problems they discuss. Instead, I recommend a different approach as described here in response to 37signal's Functional Spec point-by-point criticisms.
"Functional specs are fantasies" "They don't reflect reality" [of an application]This is true, but they can reflect what the business thinks they want, as a first cut. As a development group, we want to be involved early on in the formative stages of product design. The functional spec gives an introduction into the current thinking of the business. We can digest it and discuss what we think it means and suggest alternatives.
"Functional specs are about appeasement"Often the case, but if the functional spec is followed by real, open and honest dialog, people actually will be involved, rather than just "feel[ing] involved".
"Functional specs only lead to an illusion of agreement"Don't bother getting sign-off. What are they signing off on? It's not detailed enough to mean anything and certainly doesn't represent any mutually understood agreement of either "what is being asked for" or "what will be built".
"Functional specs force you to make the most important decisions when you have the least information"Definitely a danger. Decisions at this point should be non-binding. They should be decisions about the direction to take next, not the final direction.
"Functional specs lead to feature overload"You can push back during the spec phase. Ideally, the spec will primarily contain core functionality. And the functional spec, in particular, should talk about functions, not features.
"Functional specs don't let you evolve, change, and reassess"If you follow the advice above, this won't be the case. The functional spec represents the state of the current thinking, not the final product.
An additional benefit of the functional spec:
The functional spec and subsequent conversations can inform decisions about upcoming hiring needs for technology. While I don't expect a real, binding scope estimate to come from this exercise, you can at least get a ball park of the minimum effort. And that might indicate that you need more people. The work effort implied by the functional can be considered a minimum... I've never seen a project shrink in scope from what was in the functional.