Is your Requirements Change Mgmt Art or Science?

Encarta gives one definition of art as "beautiful or thought-provoking works produced through creative activity". It defines science as "an activity that is the object of careful study or that is carried out according to a developed method". Which category does your requirements change management process fall into? Is your change management process consistent from project to project? Could you rewind history 12 months and describe the exact process to a colleague or easily train a new hire employee on the process? If you answered no to these questions then I would argue that your requirements change management process is an art. I think we can all agree that our goal is to move this process to a science.

Many companies today author and manage their requirements in Microsoft Word or similar tools. MS Word allows for change tracking, permission restriction, comments, etc but does it really enforce change management? These word documents often get emailed around for additions/deletions, approvals, and eventually onto development and testing. How do you ensure that those organizations receive the correct version? Perhaps your organization has taken it one step further and uses Sharepoint to attempt to keep the latest version available. This process may work in principle but what happens when development and testing have already begun and the requirements change? I would still argue that this is art and not science.

Science requires that an organization use a requirements management system that supports a flexible change management process. The ability to define a process, enforce it, and manage that process is critical to increasing the quality of requirements as well as efficiently communicating continuous change. Traditional requirements management tools are not very adept at managing or communicating a complex change management process. These tools offer some basic notifications of change either through concepts such as suspect links or email; however, they do not provide any data as to why the change occurred or whether it was an authorized change. Many of these systems have no concept of a workflow driven process; rather they rely on the users to understand when and where change should apply. This can lead to confusion and rework as systems become large and additional users interact with the same requirements.

The ideal requirements change management solution should allow an organization to develop a workflow based system that may be simple or complex based on the maturity of the organization. Some key functionality areas include the ability to submit a change request into the system that can be discussed and approved or denied based on appropriate roles defined within the system. The change request will have a defined lifecycle that may include stages such as need more information, duplicate, approved, or in progress to name a few. The system should be capable of automation and enforcement by defining the appropriate data that must be entered for a given change request and once processed will automatically promote the change request to the appropriate state and parties. Furthermore, the system should be able to easily link to the artifacts needing change whether that is an entire requirements document, a specific requirement or a subset of requirements. Finally, the system should provide dynamic reports and metrics to deliver statistics concerning requirements churn, outstanding change requests, and overall project status.