Change Request Management | Project Management with the IBM Rational Unified Process: Lessons From The Trenches

All software projects need a tool for tracking change requests, defects, enhancement requests, and any information that follows a specific process. Because change requests may be submitted for potentially any artifact created on a software project, it is helpful if the tool can integrate with as many of the tools maintaining these artifacts as possible.

Features Needed in Change Request Management Tools

The following sections describe at a high level the functionality needed in a change request management tool.

Customizable Data Fields

Every software project differs in its need for the information to be tracked in a change request. Therefore, it is important that a change request tool let you create customized user interface screens containing user-specified fields for collecting information for each change request. This allows the organization to tailor to its own needs the data collected for each project.

Customizable Change Request Lifecycle Process

One characteristic of a change request process is that it typically has a series of states the request moves through as it is processed. By examining the state of the change request, you instantly know where the change request is in the process. To move from one state to another, a user performs an action that causes the change request to move to the next state defined in the process. A change request tool should allow the designer to define his own states and the actions that cause the request to move from one state to another. Just as with data fields, the change request lifecycle process is different for each organization, and even within the organization, it differs from project to project. Figure 6-2 shows a simple change request process.

Figure 6-2. A simple change request process for tracking defects

With time, an organization becomes more comfortable with its chosen change request management tool, and its change request process becomes more sophisticated. Consequently, the change request management tool needs to be able to modify the change request process to grow with the organization. Figure 6-3 shows an example of a complex change request process that was modified over time to fit an organization's growing needs.

Figure 6-3. A complex defect management process that evolved over time

Customizable Behavior

Because infinite unknowns and countless possibilities exist for customizing the change request process, there is no way a tool vendor can anticipate every conceivable way a company might want to customize a tool. Therefore, the tool should be able to be modified or altered through the writing of scripts or code. The tool should have a published application programming interface (API) that can be used in conjunction with scripts to facilitate manipulation of the artifacts controlled by the tool.

Querying and Reporting

Since the change request management tool will be used to field change requests on nearly all artifacts produced by a project, querying and searching capabilities are needed to allow users to locate and find change requests of interest. It is also quite common for change requests to be discussed openly in meetings, so the tool should provide summary reports and printable reports of each change request in the system.

Metrics Collection

The change request management process is a key indicator of a project's status and health. Accordingly, the change request management tool should either provide or integrate with tools that provide metrics data on collections of change requests. As examples of the kinds of metrics needed, consider the following:

As defect submissions trend downward over time, this may be a sign that code quality is improving. Consequently, charts and metrics that illustrate trends can be useful for assessing code quality.
Charts and metrics that measure how long each change request stays in each state can indicate the project's ability to process incoming change requests. Used in conjunction with trend charts, this can indicate if the project organization is understaffed.
Simple counts of the number of change requests in various categories can provide important information as well. For example, if change requests are assigned to specific individuals on a project team, it is useful to see how many change requests are assigned to a single person. This may show that although the number of change requests overall is reasonable, certain individuals might be overloaded with processing change requests. These types of charts are called distribution charts. In this example, distribution charts could be used to perform resource leveling.

Integration with Other Tools

Because change requests can affect most artifacts on a project, a useful capability is to be able to identify which change requests (if any) affect a given artifact. For example, for the requirements management tool, given a requirement, what change requests have been submitted against that requirement? For a file under control of a configuration management tool, what change requests have been submitted that affect that file? An even better capability would be that the artifact to which a change request is attached cannot be modified unless the associated change request is approved.

Another integration that is useful is with testing tools. The testing process creates many artifacts, such as test plans, test scripts, and test results. The testing process itself can generate new change requests in the form of defects that are submitted when tested behavior does not meet the expected result. In addition, changes to requirements may necessitate changes to test scripts. Integration between the testing tool and the change request management tool can help you understand and track these changes.

Other Important Features

Other important aspects of change request management tools include the following:

Customizable e-mail notification is useful if specific conditions can be defined where the tool automatically sends e-mail to notify a predefined list of people when a certain condition occurs. For example, when a developer has fixed a defect and the code is ready for independent testing, the tool could be customized to automatically send e-mail to the testing group when the developer marks the change request as completed.
Of all the tools used on a project, the change request management tool is one tool that may need to be accessible to both end users and customers. Accordingly, it is imperative that the tool is as easy to use as possible.
In an outsourcing situation, the change request management tool needs a Web-based interface that could be deployed over the Internet if needed.