How do you handle scope creep in your development process?
At my prior company, once the requirements were signed off, any changes had to be documented via a Requirements Change form. Then a committee evaluated the costs and time associated with the change, and either approved it, or rejected it.
We're looking to implement some type of process here for late, last minute or forgotten requirements.
Any suggestions would be appreciated.
Software QA Engineer Lead
We conformed to CMM level II at the last place I worked at, which was an outsourced account run by EDS.
Enhancements/changes had to go through the whole Change Management process (which could take weeks) and each change sign-off form had to be signed off by a set level of management, dependent on the risk assigned to each change.
It was all well and good & EDS were very proud of reaching CMM level II standards, but the project ended up being cancelled and EDS lost the account. I (and I wasn't the only one) thought that too much time was being spent on meetings, plans, meetings about the plans, re-planning, following CMM and ISO procedures etc, then there was on actually developing and testing the system.
I think there should be a process to manage Admin creep more then Scope creep!
[This message has been edited by Bug Buster (edited 01-15-2002).]