Print this chapterChange Management
Application Change Management
Change Management Procedures
Change control management is in effect from the time the work product is accepted as complete until the project is retired. First, baseline work products that are to be managed are identified. A baseline work product is a product that is considered complete and that is the basis for other, current work by the project development team. A baseline document would be, for instance, the functional requirements specification after it is accepted by the user.
A history of change request file actions for a functional specification are listed here as an example.
1. Create Open Request
2. File Impact Statement
3. File Approval of Schedule and Cost signed by User/Owner
4. Complete Project Manager's Check List for the Change
5. File Documentation relating to changes. If documentation or programs changed, identify date and items updates completed. If procedures or training changed, identify dates at which revisions were operationalized.
6. File Close Request Form Approved by User/Owner
7. Summarize Dates, Durations, and Costs
First, the baseline document is frozen, then change requests are added, but no action is taken. The fourth request, for example, might be urgent and receive immediate attention. When the functional specification is updated to accommodate the change, it is again frozen and the work continues. The three previous requests might have been added to the application if they did not significantly alter it. They may just as likely be ignored until after the application is implemented.
Changes can be classified in several ways. First, they can be classified by type as eliminating defects, improving performance, or changing functionality. Second, changes can be classified as required or optional. Third, change can be classified by priority
as emergency, mandatory with a required end date, mandatory with an open end date, or low priority. Usually, eliminating defects is a required emergency, while changing functionality is required mandatory maintenance, and improving performance is
optional and might have any priority.
Knowing the change request classification determines whether it is subject to change control or not. Emergency changes usually circumvent the change control procedures in that the activities might all be followed but they are documented after the change is complete. All other change types should be required to comply with change controls.
For example, changes to functional requirements can occur at any time, but once the functional requirements specification is approved, it is frozen until the application is operational. Changes are subject to change control: they are added to a change
request list for future consideration unless given an emergency designation.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
FIGURE 18-4 Sample Change Request Form
A procedure for change control (listed below) requires that a formal request for a change is submitted by the user to the project manager (PM).
1. User sends the project manager and owner (if different person) a Change Request form (see Figure 18-4).
2. Project manager and SE develop an impact statement. At this time, the project manager's Check List is used to identify all work actions and changes relating to the request.
3. The Change Request is discussed with the User/Owner to establish priority, schedule, and cost changes.
4. Agreement is formalized and User/Owner approval of schedule and cost changes is obtained.
5. Using the impact statement, application and all related documentation are changed. Implement the change. As tasks are complete, check off the task on the project manager's Check List.
6. User/Owner approval to close the request is obtained and the request is closed.
The PM and SE define the schedule and cost impacts of the change (see Figure 18-5). The changes are then discussed with the user. Based on the negotiation with the user, the change is assigned a priority for action, and the cost and schedule are changed.
The request, expected date of action, schedule change, and cost increments are added to a project history file. The changes may be monitored by a Change Control Clerk, a person charged with maintaining project history and change control records, and with issuing a monthly change control report. A Change Control File contains all requests, correspondence, and documentation about changes. An Open Change Request is created when the request is made and a change number is assigned. The open change request stays on file until the request is completed, closed, and reported.
As the change is made, affected items are updated, including the appropriate documentation, code, training, and so forth (see Figure 18-6). A project manager's check list is used to check off required actions. The new documentation is filed with the Change Control Clerk who distributes it to all interested parties.
The completion date for the change is entered in the Change Control File. The change is identified as closed in the next status report and the open request is removed from the Change Control File.
Depending on the organization, the IS executive might want to track change requests for projects to identify success in meeting requests. Overall costs of changes for a year are used as one indicator that an application is a candidate for either retirement or reengineering. In such cases, both costs and volumes of change requests are tracked through the change control process. Summary reports by project of the changes over a given period, or comparing periods (e.g., a current period compared to the same period last year) can be developed. Three such reports are shown as Figures 18-7 through 18-9 for total cost by type, cost and schedule impacts, and change requests, respectively.