Automated tools can help your change control process operate more efficiently. Many teams use commercial problem- or issue-tracking tools to collect, store, and manage requirements changes. A list of recently submitted change proposals generated from the tool can serve as the agenda for a change control board meeting. Problem-tracking tools can also report on the number of requests in each status category at any given time, the origins of the change requests, and other parameters that can give you insight into the change activity on your projects.
Because the available tools, vendors, and features frequently change, I won’t provide specific tool recommendations here. Instead, I’ll provide some general guidance about how to effectively incorporate such tools into your software development process and how to use the tool’s reporting capabilities to get a handle on the project’s change activity. Look for the following features in a tool to support your requirements change activities:
- Lets you define the data items included in a change request.
- Lets you define a state-transition model for the change-request life cycle.
- Enforces the state-transition model so that only authorized users can make the permitted status changes.
- Records the date of every status change and the identity of the person who made it.
- Lets you define who receives automatic email notification when an originator submits a new request or when a request’s status is updated.
- Produces both standard and custom reports and charts.
Some commercial requirements management tools have a simple change-proposal system built in. These systems can link a proposed change to a specific requirement so that the individual responsible for each requirement is notified by email whenever someone submits a pertinent change request.
Tooling Up a Process
When I worked in a Web development team for a large corporation, one of our first process improvements was to implement a change control process to manage our huge backlog of change requests. We began with a process similar to the one described in the previous article in this series on change control. We piloted it for a few weeks by using paper forms while I evaluated several issue-tracking tools. During the pilot process we found several ways to improve the process. We also discovered several additional data items that should be included in the change requests. We selected a highly configurable issue-tracking tool and tailored it to match our process.
The team used this process and tool to handle requirements changes in systems under development, defect reports and suggested enhancements in production systems, updates to Web site content, and requests for new development projects. Change control was one of our most successful process improvement initiatives. Our process and tool really helped this extremely busy team manage its dynamic backlog of requests effectively.
Status Overkill
It’s easy for people to get carried away with all the options they have available with a change control tool. I saw a good example of this once when I was visiting a client site. That very day, someone was configuring the team’s new change control tool. He was planning to set up no fewer than fifteen unique statuses for change requests. While I can imagine that these statuses all made some sense, the fact is that no one is going to use them all in practice. Some of them were transient statuses, through which a change request might pass just briefly on its way from one status to another. In reality, no one is going to update the contents of the change-request database frequently enough for these short-lived status changes to be useful.
Be sure to take a pragmatic approach to the tools and processes you use. If the process and tool are overly complex and do not add evident value to the organization, team members will find ways to bypass the process or revert to handling things manually instead of through the tool. This undermines the effort and gives the whole concept of process a bad reputation.
Measuring Change Activity
Software measurements provide insights into your projects, products, and processes that are more accurate than subjective impressions or vague recollections of what happened in the past. The measurements you select should be motivated by the questions you or your managers are trying to answer and the goals you’re trying to achieve. Measuring change activity is a way to assess the stability of the requirements. It also reveals opportunities for process improvement that might lead to fewer change requests in the future. Consider tracking the following aspects of your requirements change activity:
- The number of change requests received, currently open, and closed.
- The cumulative number of changes made, including added, deleted, and modified requirements (You can also express this as a percentage of the total number of requirements in the baseline.)
- The number of change requests that originated from each source.
- The number of changes proposed and made in each requirement since it was baselined.
- The total effort devoted to processing and implementing change requests.
- The number of cycles through the change process that it took to correctly implement each approved change (Sometimes changes are implemented improperly or cause other errors that need to be corrected.)
You don’t necessarily need to monitor your requirements change activities to this degree. As with all software metrics activities, understand your goals and how you’ll use the data before you decide what to measure. Start with simple measurements to begin establishing a measurement culture in your organization and to collect the key data you need to manage your projects effectively. As you gain experience, make your measurements as sophisticated as necessary to help your projects succeed.
Figure 1 illustrates a way to track the number of requirements changes your project experiences during development. This chart tracks the rate at which requests for new requirement changes arrive. You can track the number of approved change requests similarly. Don’t count changes made before baselining; you know the requirements are still evolving prior to establishing the baseline. Once you’ve baselined the requirements, though, all proposed changes should follow your change control process. At that point you should also begin to track the frequency of change (also called requirements volatility) that Figure 1 illustrates. This change-frequency chart should trend toward zero as the project approaches its ship date. A sustained high frequency of changes implies a risk of failing to meet your schedule commitments. It probably also indicates that the original baselined requirements were incomplete, suggesting that improving your requirements elicitation practices might be a good idea.
A project manager who’s concerned that frequent changes might prevent the project from finishing on schedule can gain further insight by tracking the requirements change origins. Figure 2 shows a way to represent the number of change requests that came from different sources. The project manager could discuss a chart like this with the marketing manager and point out that marketing has requested the most requirements changes. This might lead to a fruitful discussion about what actions the team could take to reduce the number of post-baselining changes received from marketing in the future. Using data as a starting point for such discussions is more constructive than holding a confrontational meeting stimulated by frustration.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
