That requirements will change is a given. How you plan for and manage that change is crucial. Think about what you want to accomplish with your change management, what you want to protect yourself from, what you want to avoid, and then put in place the practice that makes sense for you.
Having a tool that will
• allow anyone to enter a change request
• maintain information associated with the change to help with its evaluation
• track the request
is a good start, but not sufficient.
You must also have a process in place to
• review and triage change requests, evaluating both their importance and impact (to schedule, ultimately)
• place the accepted requirement changes (or new requirements) into the requirement baseline for the proper release
The triage and evaluation are usually done by committee, with some preliminary evaluation done by someone who understands the change and/or the impact. The “committee” part of this practice makes it look complicated and heavy, but having a review team (usually called something like “software change review board” or SCRB) meet regularly isn’t all that onerous. We used to meet once a week, but there were times when there weren’t change requests, only bug reports (which were handled by a similar process/team), and so we didn’t meet. When more frequent meetings were necessary, we held them.
The team should consist of a representative of each stakeholder group. In our case, we had QA (running the meeting), Engineering management, Technical Support, and Product Marketing evaluating changes. It’s very important to have input from those who can evaluate the effort needed to implement a change and the impact on the rest of the system. Often there will need to be a tradeoff between doing this change or new requirement and doing something else. So that means that engineering representation is very important. Product Marketing is the organization that will be able to evaluate the importance of the change to the ultimate customer. So their input is important as well.
But if it makes more sense, you could create a process that has only engineering meeting regularly, with the other disciplines weighing in on request. Again, evaluate what makes sense for your situation, and if you find a need to change the process later, do that.
When there’s no need to meet, don’t meet. When you do meet, make sure that the meeting is managed so the discussions don’t go off track and so that detailed evaluations can be done offline. Emergencies don’t need to wait until a regularly scheduled meeting. Just call a meeting (or handle it via phone or email, as an exception).
Don’t let the notion of a “process” be a reason to not manage changes. Think of the real purpose of this – to avoid “scope creep”, to be sure that changes aren’t introduced without a really good reason, to understand and evaluate the change, to see how making the change affects the schedule or the integrity of the product, and if the change is accepted, to get the right wording into the requirements baseline and let the appropriate engineers know what to do.
When you address these issues, you’ll have the right practical change management.
Anita Wotiz
www.duckpondsoftware.com (see the Consulting tab)
Instructor, UCSC Extension in Silicon Valley
Software Requirements Engineering and Management (next class Aug 2009)
Software Project Planning, Monitoring, and Management (next class Oct/Nov 2009)
