Spec'ing is good, up to a point. I won't rehash what the others have said except walk a fine balance between too much spec'ing and too little spec'ing. Couple things: 1. With an experienced, communicative and mature development team your spec need not be super detailed. Let the developers have some freedom. Otherwise they will rebel. The converse is true, with a young, immature team spec till you bleed from your ears because new guys need to be hand held or you will end up with a de-reailed product which does nothing the client wants. 2. Baseline early, freeze late. i.e. Find a point at which your spec reaches enough detail to produce a usable product from and baseline it. Allow changes to be made but nothing too major after that. Freeze things only once the product is near completion. This avoids feature changes happening during testing (which is a nightmare). 3. Read up about MSF (Microsoft Solutions Framework). It really does work and is a great framework. With a bit of adaptation it will fit most development houses and projects.
MSF at Microsoft
Useful practical MSF use
Oh and a bit of advice: Become an analyst but leave a couple of toes in development world. I personally love analyst work, but sometimes I just want to see a few Dim fubar as integer lines as opposed to Stabilisation offers a product a chance to reach...;P regards,
Paul Watson Cape Town, South Africa e: paulmwatson@email.com w: vergen.org