A Strawman Workflow for Requirements Change Management
One of things we are asked to do on almost every project is provide guidance on defining the workflow for managing the changes that inevitably occur to the requirements that the team has worked so hard to capture and document. After doing this enough times, there are certain actors and activities that are pretty standard to the process.
The Activity Diagram included here is a lightweight starting point for defining your Change Management (CM) workflow. You have worked very hard to get a set of requirements worth moving forward with into full-on development activities, the project deserves to have a well-defined CM process that is understood and followed by the team.
A few things about the diagram (which may be a little easier to view here):
• It implies that you have some tool into which Change Requests (CRs) can be entered and tracked. The diagram implies that the tool can automatically notify a project team member when a new CR is created. Having a tool is a necessity, automated email is nice-ity. If you have a tool designed specifically to support a CM process than you’ll have a leg up on automating the management of your CRs, but it can be done with a spreadsheet or document application. Be prepared for a lot of tedious manual work though.
• A Change Manager Role is identified in the diagram. This does not have to be, and for smaller projects will most assuredly not be, a separate full-time resource, but will most likely be a role that is owned by a resource that already owns one or more roles defined for the project. I have seen the QA Lead, Requirements Lead and the PM fulfill this role.
• The Change Control Board (CCB) is a critical part of the CM process. One of the biggest potential bottlenecks to managing change on projects is the ability to expeditiously evaluate and dispatch the Change Requests that are logged. The CCB must be comprised of individuals who can “rule” on the action to take on a CR. Your project may need a separate set of steps for generating, compiling and evaluating CR estimates, but this one is designed to be lightweight, and the assumption is that the CCB is comprised of individuals able to make both the estimates and decisions about how to the act on those estimates.
• The assumption here is that the person managing the requirements will become the CR owner of the assigned CR because the resolution of a CR is most likely going to involve an update to the requirements.
• The ‘Notify SME of CR’ step needs a little explanation as well. This could be a single email exchange with a single SME or it could involve setting up multiple meetings with a group of SMEs, or something else entirely. The idea is that while this activity looks fairly innocuous it could very well be a multi-step process in and of itself–the point being that the time and resources required to execute this step should be well understood, especially when you consider the repeated iterations that are often part of this step in the process.
• The ‘Update Project Models as Appropriate’ activity is also high-level with the understanding that this step will need to be detailed more to account for the particulars of your project—the intent is to hold a place for the activities that are triggered by an update to a requirement. So the intention here is to provide a starting point for a CM process, not define a one-size fits all solution. The final assumption here is that you will need to modify this template to fit the specifics of your project. With that in mind, it is also important to remember that the CM process that is defined at the beginning of the project will evolve as the project progresses and the process is executed in real-time in the midst of the project activities.
