Change Management
A critical component of project monitoring and control is change management. As business requirements and operating environments change all the time, the project manager has to manage change throughout the software development cycle from acquisition,
supply, development, operation, and then maintenance. The guiding principles, techniques, and tools for change management are discussed in this chapter.
Application Change Management
IMPORTANCE
Applications frequently undergo redesign. Three typical conditions for redesign are assignment of a new management team, a project that is chronically over budget, late, and full of bugs, and the loss of the user-owner confidence that the SEs understand their needs. Even without drastic redesign, reviews (e.g., for user agreement or quality assurance) frequently turn up items that were originally compromised or rethought several times before final version agreement. The history of decisions and the reasoning about decisions is rarely kept as part of project notes. But, any project manager and SE can tell you that they frequently rehash the same arguments and reasonings over and over, even reaching the same conclusions.
In a paper-based work environment, keeping track of the history of decisions is not practical; so much paper would be generated that finding anything becomes impossible. In a CASE environment, or in an imaging environment, maintaining the history of application decisions electronically becomes a manageable, and sometimes desirable, activity. The ability to recall reasoning through a decision, whether it is logical or political, can save time and provide continuity between managers.
Finally, changes in the business, legal requirements, or stakeholders in the application can all necessitate legitimate changes to application designs. Knowing the history of decisions sometimes makes them more palatable and easier to convey to staff. For instance, being able to relate a change of design to a developing business situation helps those who must cope with the change appreciate the business of the application. If the change is to keep a valued customer or increase competitiveness in a new area, the systems developers are more likely to be enthusiastic about shifting design.
Changes can be to requirements, designs, programs, interfaces, hardware, or purchased software. Most changes are initiated from within the organization developing the application, but might be motivated by some outside event, such as a change in laws. Using change controls protects the development team from user whims while allowing for action on legitimate requests. The idea that a specification is frozen, meaning not changeable after it is accepted as complete, motivates users to be as complete in their thinking as possible.
Designs do not stay frozen forever. Usually, once an application begins coding, no changes are implemented until the application becomes operational. Then the project manager, SE, and user review the backlog of requests to develop priorities and plan the changes. Some changes may be so critical that the design is unfrozen to add the crucial functionality, regardless of the phase of development.