One of the things I've been working on is specs. I think of myself as being kind of good at the functional spec -- I'm not always clear on the precise technical means to accomplish the things that people want to do with systems and services but I'm very articulate about what we're trying to get done. I love writing specs, and I find them to be useful tools to
- prompt questions from the non-technical customers and the programmers alike, all of which can make the project better
- make it clear what we're doing and what we're not doing
- avoid heartbreak and disappointment at the end of the project
So as the spec-gal, you also need to make sure that the customers and the programmers know that the spec is a living document, and features may be added or removed, but everyone's gotta know about it and agree to it.
*Yes, I know this conversation isn't about a computer programming project, but I think the common elements are easy to see: unrealistic expectations, the technical execution staff going off and not communicating with the customer thoroughly, with a hearty dose of mental illness. Pretend instead of "helicopter" they're talking about "dynamic form handling widgets" or somesuch.