Requirements change. And changes in requirements can come at any time during the life of a project (or even after that). The later in the life cycle the requirements change, the more severe the impact on the project. Instead of wishing that changes will not happen or hoping that somehow the initial requirements will be "so good" that no changes will be required, it is better to prepare to handle change requests as and when they come. Uncontrolled changes to requirements can have an adverse effect on the cost, schedule, and quality of the project. Requirement changes can account for as much as 40% of the total cost.8
Ravi realized the need for a change management process the hard way. In an effort to please the customer, he readily agreed to make the changes the customer requested. With no control on change requests, the project experienced them at an increasing frequency. In the end, after 60-hour weeks for the team members and an effort escalation of more than 100%, Ravi barely finished the project. What's worse, he found that the customer was still not satisfied because he thought that more changes would have made the product better.
In another project, Mary, a seasoned project manager, recorded each change request her customer made on the phone or through e-mail and informed the customer of the impact of the request on effort and schedule. Not only did the frequency of change requests decrease with time, but also the customer transferred many requests to the next release. The final result? The project was completed in time, and the happy customer actually paid for the extra effort that was incurred in implementing the change requests.
This section discusses the requirement change management process used at Infosys. This process defines the set of activities that are performed when there are new requirements or changes to existing requirements (we will call both of these changes in the requirements). Given the experience of project managers such as Ravi and Mary, the change management process is routinely used by project managers, and specifying it as part of the project management plan is treated less as a planning exercise and more as means for clarifying the process to customers and getting their buy-in.
During project planning, a project manager decides which process is to be followed for handling change requests. The planned process is discussed with the customer so that both the customer and the vendor are in agreement about how to manage changes. Generally, the process specifies how the change requests will be made, when formal approvals are needed, and so on. When a request for a requirements change comes in, the requirements change management process must be executed.
Because change requests have cost implications, it is necessary to have a clear agreement on payment. Frequently, with customer approval, projects build a buffer into their estimates for implementing change requests (typically a small percentage of the total project effort). Such a budget provision simplifies the administrative aspects of implementing approved change requests.
The commonly used change management process at Infosys has the following steps.
1. Log the changes.
2. Perform an impact analysis on the work products.
3. Estimate the effort needed for the change requests.
4. Reestimate the delivery schedule.
5. Perform a cumulative cost impact analysis.
6. Review the impact with senior management if thresholds are exceeded.
7. Obtain customer sign-off.
8. Rework work products.
You maintain a change request log to keep track of the change requests. Each entry in the log contains a change request number, a brief description of the change, the effect of the change, the status of the change request, and key dates. You assess the effect of a change request by performing impact analysis. Impact analysis involves identifying work products that need to be changed and evaluating the quantum of change to each; reassessing the project's risks by revisiting the risk management plan; and evaluating the overall implications of the changes for the effort and schedule estimates. The outcome of the analysis is reviewed and approved by the customer. The change requests are incorporated in the requirements specification document, usually as appendixes. Sometimes the relevant portions of the document are also modified to reflect the changes. Monitoring of approved change requests and ensuring their proper implementation are handled by the configuration management process, which is discussed in Chapter 9.
A change might be classified as minor if the total effort involved in implementing it does not exceed a predetermined value say, two person-days. Minor changes typically become part of the project effort, utilizing the buffer in the planned estimate. Major changes usually have a larger impact on effort and schedule and must be formally approved by the client. Senior management gains visibility in the changes through status and milestone reporting, which are discussed in Chapter 11.
To specify the changes and the output of the change management process, projects generally use a simple template. Each change is assigned a unique reference number that is specified in the template's request number field. The change specification field gives a brief description of the requested change. The category of the change (for example, design change, contract change, functionality change, performance change) and the nature of the change are specified as change category. The summary of the impact analysis is recorded, along with brief information regarding work products that will be affected, the effort involved, and the implications for the schedule. The status of the change request what is being done with it is recorded in the status field. The date of the change request might also be recorded, along with the date the change was approved, if approval is needed. Generally, the projects customize this template to suit their needs.
Figure 3.3 shows a filled-in template for a change request for the ACIC project. The various components in the template are self-explanatory. This example is of a major change request that has an impact on effort as well as schedule. The result of the impact analysis states the impact on these dimensions. The analysis report also states that the customer has approved the impact analysis (including the changes in effort and schedule).
Figure 3.4 gives another example of a change request. In the example, the detailed contents of the impact analysis are not important for the purposes of understanding requirements change management.
Note that although the impact of a change request is specified, and approved, by using the template, the actual tracking of implementation of a change request is handled by the configuration management process, which is discussed in Chapter 9.
One danger of requirement changes is that, even though each change is not large in itself, over the life of the project the cumulative impact of the changes is large. Hence, in addition to studying the impact of and tracking individual changes, you must monitor the cumulative impact of changes. For cumulative changes, a change log is used. To facilitate this analysis, the log is frequently maintained as a spreadsheet. The example in Figure 3.5 illustrates how cumulative changes are maintained. For details of each request, the relevant change request can be accessed by using the change request number and date.
From a spreadsheet of this type, you can immediately see the total cost of the requirement changes made so far. As mentioned earlier, Infosys project managers sometimes plan some buffer for handling change requests. As long as the cumulative effort for all change requests is less than this buffer, nothing special needs to be done. If the cumulative effort of all changes exceeds this buffer, however, further changes can have an adverse effect on total cost and scheduling. In this situation, the project manager must revise the estimates and get them approved.