Originally posted by Corey McGlone:
Are you still in the analysis phase and collecting requirements, or have you determined your requirements already and are ready to do your design? Scope creep isn't a phase. Scope creep happens when you allow requirements to change even after they should be been frozen.
Agreed; technology doesn't solve bad project management.
I would suggest an ammendment; waiting for a complete freeze on requirements isn't the only way to manage requirements. It is an important way to manage them if you are negotiating the terms of a fixed-price contract.
In other situations you can find a different balance between being able to depend on stable requirements yet allowing for reasonable change to requirements. Basically you:
1. gather and analyze requirements
2. prioritize them
3. break the project into stages based on requirement priority and risk management
4a. freeze the requirements for the stage you are working on
4b. (simultaneously) allow any incoming requirements changes to go into a hopper you don't act on.
5. go back to step 1 until done
You don't get this for free, in any way shape or form. The time for your total project can stretch, and you can be faced with re-work. It does allow you to predict the cost and deliverables of the upcoming stage. At the start of the next stage, if requirements have changed, if you are a skilled project manager or estimator you can say "this change will cost $X; do you want it that badly?".
Scrum is an example of an agile process that tries to do this. It works best if the stages are kept small, so that the risk of immediate re-work is minimized. That doesn't eliminate the risk of major re-work if an assumption-busting requirement appears late in the game, but that is why you want to be in a position to say how much it will cost to accomodate the change.
[ June 06, 2002: Message edited by: Reid M. Pinchback ]