Managing Change

1. Managing Change • Key Points • A process to manage requirements can be useful only if it recognizes and addresses the issue of change. • Internal change factors include failing to ask the right people the right questions at the right time and failing to create a practical process to help manage changes to requirements. • In order to have a reasonable probability of success, requirements leakage must be stopped or at least reduced to a manageable level.

2. Change Control Change control is a method for implementing only those changes that are worth pursuing, and for preventing unnecessary or overly costly changes from derailing the project. Change control is an agreement between the project team and the managers that are responsible for decision-making on the project to evaluate the impact of a change before implementing it. Many changes that initially sound like good ideas will get thrown out once the true cost of the change is known.

3. Managing Change Why Do Requirements Change? A requirements management process can be useful only if it recognizes and addresses the issue of change. There are several reasons for the inevitability of changes to the requirements. Some of these reasons are internal factors and may be under our control, but many of them are external factors and are outside the control of the developers and the users.

4. Managing Change External Factors External factors are those change agents over which the project team has little or no control. No matter how we manage them, we must prepare ourselves technically, emotionally, and managerially to be able to address these changes as part of the normal course of software development activity.

5. Managing Change Changes occur for the following reasons. 1- There was a change to the problem that we were attempting to solve with the new system. Perhaps a change occurred in the economy, in government regulations, or in the marketplace and consumer preferences. Because of the fast pace of technology change, it is more and more likely that such changes will take place before we even finish solving the original problem the user described.

6. Managing Change Changes occur for the following reasons. 3- The external environment has changed, which creates new constraints and/or new opportunities. One of the most obvious examples of environmental change is the ongoing improvements in computer hardware and software systems: If tomorrow's computers are 50 percent faster, cheaper, and smaller and run more advanced applications than do today's computers, they will likely trigger a change in the requirements for a system. Before 1995, hardly anyone anticipated the Internet and the World Wide Web. The requirements for a wide range of information systems—from word processors to customer information systems to banking systems—are clearly quite different today from what they were in the pre-Internet era.

7. Managing Change Changes occur for the following reasons. 4- The new system comes into existence. As we discussed, one insidious external factor, and a prime one in the "Yes, But" syndrome, is that the very existence of a new system causes the requirements for the system itself to change. As the organizational behavior evolves around the new system, the old ways of doing things are no longer appropriate; the need for new types of information emerge, and new requirements for the system inevitably develop. Thus, the simple act of delivering a new system elicits additional new requirements for the new system!

8. Managing Change Internal Factors Internal change agents will also contribute new requirements. 1- We failed to ask the right people the right questions at the right time during the initial requirements gathering effort. If our process does not include all stakeholders or if we do not ask all the right questions of them, we contribute to the change problem by simply not understanding the true requirements for the system. In other words, there are far more "Undiscovered Ruins" than necessary, and we are making significant changes that could have been avoided had we developed a more comprehensive understanding up front

9. Managing Change Internal Factors 2- We failed to create a practical process to help manage changes to the requirements that would normally have happened on an incremental basis. We may have attempted to "freeze" the requirements; thus, the "latent," necessary changes piled up until they created such pressure that they inevitably exploded in the face of the developers and the users, causing rework and stress.

10. Managing Change Internal Factors 3- Iterating from requirements to design begets new requirements. As we described in Chapter 20, even if we do everything right, the process of designing the system will expose new requirements and necessitate changes to requirements that have already been elaborated. To ignore this would deprive ourselves of innovative capabilities enabled by design decisions or changes in technology. Worse, we would be forced to pretend that every existing requirement was perfectly understood and elaborated earlier, that no negotiation, compromise, or alternate set of requirements discovered at this time could possibly achieve the user's need as well as (or perhaps better than) the original stated requirement. Either approach would constitute foolishness of the highest order.

11. Managing Change A Process for Managing Change Clearly, given the fact that change is a natural part of the process and that change will come from both external and internal sources, we need a process for managing change. Such a process puts the team in control so that it can effectively discover change, perform impact analysis, and incorporate those changes that are deemed both necessary and acceptable into the system in a systematic manner.

12. Managing Change A Process for Managing Change Building on Weinberg's recommendations, a process for more effectively managing change must include the following steps. • Recognize that change is inevitable, and plan for it. • Baseline the requirements. • Establish a single channel to control change. • Use a change control system to capture changes. • Manage change hierarchically.

13. Managing Change Step 1: Recognize That Change Is Inevitable, and Plan for It The first step is a simple one. The team must recognize that changing requirements for the system is inevitable and even necessary. Some amount of change will occur, and the team should develop an awareness of this issue and a corresponding plan for managing change that should include some allowance for change in the initial baseline.

14. Managing Change Step 1: Recognize That Change Is Inevitable, and Plan for It • As for the legitimacy of change, with the single exception of the Easter Egg, all requests for change can be considered legitimate in that they originate from a stakeholder who has both a real need and the potential to add value to the application. • For example, requests for changes from the development team are legitimate since that team knows more about the system than anyone else does. Some of the "best" requirements come from the implementers who are closest to the system; they best recognize what the system really can do. We should encourage their input to the process since the result will be a better system for our users.

15. Managing Change Step 2: Baseline the Requirements In each iteration, the team should baseline the requirements for the build. The baselining process may be as simple as putting version control on the pertinent artifacts—the Vision document, software requirements, and use-case models—and publishing the baseline for the development team. The collection of itemized requirements in these documents creates a baseline of information about the requirements and anticipated use cases for the system.

16. Managing Change Step 3: Establish a Single Channel to Control Change Ad hoc changes to a software system can easily cause significant and unintended consequences. Although it should be obvious that the existence of a new feature can cause significant impact to software requirements, system architecture, test plans, and so on, all of us have also experienced a worst case in which a "simple change" to code causes unanticipated consequences, occasionally even catastrophic ones. In addition, one proposed new feature might obviate, or make more difficult, an important future system feature that is not even being implemented in this release.

17. Managing Change Step 4: Use a Change Control System to Capture Changes In a sense, it may be easiest to focus on the external, customer-requested changes because they are most readily identified and will tend to naturally find their way into the project via the project management or change control function. However, during development, there will be a tremendous number and variety of other types of potential changes to the system.

18. Managing Change Step 4: Use a Change Control System to Capture Changes Indeed, many of the proposed changes that occur during the design, coding, and testing of a system may appear to be unrelated to requirements, involving corrections to code- or design-level bugs. However, the impact must still be assessed. And yes, as the deadline approaches, we must even make conscious decisions about which bugs will be allowed to remain in the system—due to the potential for the fix to destabilize the entire system and thereby jeopardize the release date—and which ones will be removed. Also, many bugs may affect the requirements, require interpolation between the requirements, or require disambiguation of a known requirement.

19. Managing Change Step 4: Use a Change Control System to Capture Changes The team should implement a system for capturing all change requests. The system should be used to capture all inputs and to transmit them to the authority of the CCB for resolution. The CCB plays a key role in helping the project achieve success and should consist of no more than three to five people who represent the key stakeholders for the project: customers, marketing, and program management.

20. Managing Change Step 4: Use a Change Control System to Capture Changes When considering whether to approve a change request, the CCB must consider the following factors: • The impact of the change on the cost and functionality of the system • The impact of the change on customers and other external stakeholders not well represented on the CCB: other project contractors, component suppliers, and so on • The potential for the change to destabilize the system

21. Change Control • A change control board (CCB) is made up of the • decision-makers, project manager, stakeholder or • user representatives, and selected team members. • The CCB analyzes the impact of all requested changes to • the software and has the authority to approve or deny any • change requests once development is underway. • Before the project begins, the list of CCB members should • be written down and agreed upon, and each CCB member • should understand why the change control process is • needed and what their role will be in it.

22. Change Control Whenever a change is needed, the CCB follows the change control process to evaluate the change: The potential benefit of the change is written down, and the project manager works with the team to estimate the potential impact that the change will have on the project. If the benefit of the change is worth the cost, the project manager updates the plan to reflect the new estimates. Otherwise, the change is thrown out and the team continues with the original plan. The CCB either accepts or rejects the change.

23. Managing Change Step 5: Manage Change Hierarchically The fact that all these people are interested in making changes to the system is not intrinsically bad; aside from the Easter Egg phenomenon, we could even imagine that all these changes are beneficial. However, the fact that the changes might not be documented or analyzed is a problem, and if they're not managed carefully, disaster can occur. A change to one requirement can have a ripple effect in other related requirements, the design, or other subsystems; further, this fact may not be obvious to the requester, who casually asks the programmer to make a "quick and easy" change to the system.

24. Managing Change Step 5: Manage Change Hierarchically The fact that all these people are interested in making changes to the system is not intrinsically bad; aside from the Easter Egg phenomenon, we could even imagine that all these changes are beneficial. However, the fact that the changes might not be documented or analyzed is a problem, and if they're not managed carefully, disaster can occur. A change to one requirement can have a ripple effect in other related requirements, the design, or other subsystems; further, this fact may not be obvious to the requester, who casually asks the programmer to make a "quick and easy" change to the system.