Ideally, formal procedures should be in place for IT users to be able to request IT hardware and software changes, for users to be notified whether the requested changes are approved, and for users to confirm that the tasks performed to address the requested changes are completed. Actually, informal procedures are often followed by users to initiate changes in IT. A review of available literature shows that informal procedures to manage change could pose an obstacle for the efficient use of resources and for ensuring that projects meet organizational goals (Damodaran, 1996). Without formal procedures, it is unlikely that adequate communication between the user and IT staff would be possible, hindering the benefit of the participatory design process.
The physical processes involved in making changes to IT are considered to be part of a changes management system. Change management is defined as a process of identifying, evaluating, tracking, managing, implementing, and reporting the requests for changes to the IT (Midha, 1997). When organizations address system analysis and design issues of an information system , systematic approach should be established for carrying out the steps necessary to design, build, implement, and maintain the system. While each organization may vary the details of the method, it most often resembles the System Development Life Cycle (SDLC) (Kendall, K. & Kendall, J., 2002, p. 10).
In the last phases of the SDLC, maintenance of the system is required when the need for changes in the system have been evaluated. According to K. Kendall and J. Kendall, there are two reasons for system maintenance. The first reason is to correct software errors known as software bugs. The second reason is to enhance the software's capabilities in response to user requests, business changes, and or changes in technology. The end-users of the field office are extremely involved with tasks related to IT maintenance. Field offices, as participants in the SDLC, are in need of establishing change management procedures for addressing their system maintenance issues.
While formal change management systems are in place at the upper levels of the Organization, the understanding of change management needs at the regional and field office levels of the Organization has been lacking. At the beginning of 2005, Central Region Headquarters issued a directive to establish requirements for a change management system at the regional level and to encourage field offices to establish their own change management plans:
Local offices need to establish local Configuration Management plans for system hardware, software and communications which are not subject to national or regional Change Management policies. This includes non-baseline software applications and capabilities in national systems [ ] or regional systems. Configuration Change Policy is established by the MIC [ ] and managed locally by the Electronics System Analyst (ESA) or Information Technology Officer (ITO), depending on the particular system or software capability. Each office should decide what change management process best suits their needs, based on the extent and complexity of equipment to be managed. (Organization Central Region, 2005, p. 3)
With the freedom to self-manage their own change management program, the field offices have an opportunity to establish change management procedures that work best for the office's managers, IT users, and IT staff. Change management systems serve management and information system builders by allowing them to monitor and establish controls on services provided to the user. Discussion of change management systems in the Organization often focus on system analysis and software development rather than user support. A possible reason for this is the Organization wrongly considers tasks performed to meet user needs as the intended goals of the user support program and not the means to achieve those goals.
In most change management systems, the user is seen as someone who is involved with identifying initial problems. The user also can provide feedback about whether the changes made through the change management system were appropriate or not. However, as previously stated, IT users in the Organization's field offices may not only be the users of IT, but also the participants in developing the software which will be used for the changes in the IT. For example, the author surveyed the Organization's Local Application Database, a database used for distribution of applications written by users located at the Organization's various field offices. As of March 2005, there were a total of 811 documented applications written by field office staff available for distribution throughout the Organization. The significance of this is that services provided by the field office user support program are not only necessary for the users who request changes to IT, but also for users participating in end-user software development.
Change management systems can also be considered to be the interface between the organization and the user. IT project managers have a responsibility to weigh the interests of their organization and the needs of the users when building and maintaining IT systems:
In general, users do not understand their needs in terms of the goals of the organization. The organization must reconcile the goals and the user needs. It is the project manager who must have the skills for this reconciliation. (Jiang, Chen, & Klein, 2002, p. 23)
Change management systems provide a method for weighing the needs of the user with the needs of the organization when those groups are in conflict. Without change management procedures in place, users are less likely to have their request for changes to the systems approved. This is because organizations cannot easily determine how well a user's request for change are in step with the organizational goals and plans. The change management system offers a method for providing a means for the two groups to collaborate and coordinate with one another.
Improving change management can also help address the burdens IT may place on the user. For example, it is not uncommon to hear users express concerns about "information overload" or "too many changes to keep up" caused by IT systems. In many situations, user training is used as the solution to enable users to cope with the burden caused by IT. While providing training may decrease some of the IT burdens users experience, the author argues that such complaints from users also indicate a flawed change management system. A change management system not only approves on and implements on changes to IT systems, it also tracks the pace and schedule the tasks and projects are to be completed. Training alone will not prevent the poor performance of users caused by the introduction of too many changes. An IT case describing this very issue can be found in the report, Managing the Impact of Change:
Even when the goals are clearly seen as beneficial to the company and workforce, such as an improvement to efficiency or revenue-enhancing opportunities, the change brings a level of risk, discomfort and uncertainty. If there are too many change events at once, the effectiveness of the group the program was designed to help improve will be disrupted. And without a structured, high-level approach to managing change and how it affects various organizational units, the success of a company's internal initiatives is left to chance . . . We started off by asking ourselves whether the various organizational units throughout the company could absorb all of the changes we were planning for them, and we set about creating the processes and tools to make the organization more efficient at managing this critical process. (Retna & Stabler, 2005, ¶ 3)
A change management system that allows its users to provide input into not only what changes should take place in IT systems, but also when such changes are to be implemented is beneficial to both the user and the organization.
Once a user's request for a change to an IT system has been approved, there is a question as to how the changes should be implemented. In most circumstances, maintenance tasks in the form of configuration changes, code debugging, or minor software "plug-ins" are involved. Regardless of the type of maintenance task performed, the number of steps necessary for the changes is relatively low and requires no significant change to the information system. There are, however, situations where the user's request cannot be fulfilled without significant changes to the current information system and must be addressed through the development of a new information system. In such cases, one should consider whether the primary focus of the change management system will be geared for the maintenance needs of current IT or for providing support for the management of a new IT project.
The management of new IT projects requires an increase in resources that organizations need to consider. When a significantly large number of tasks and corresponding resources are required to meet the needs of the user, the role of the change management system is no longer focused on maintenance needs. Instead, change management systems must focus on the entire SDLC which includes the planning, designing, testing, and implementation of a new system. When new IT projects are involved there is increase interdependency between the user support program and other IT programs such as software development, systems analysis, and IT program management. The Organization needs to recognize and appreciate the demands that user support can make on other IT programs.
Utilizing the analysis of change management systems already in use, considering organizational policies, and using professional observation, a change management system for the field office can be developed. The author has composed a description of the Ideal Field Office Change Management System (Table 1) for meeting the needs of users at an Emergency Field Office. Two subsystems are part of the proposed ideal change management system, the Approval Management System and the Project and Task Management System. There are two reasons for splitting the Field Office Change Management System into two subsystems. First, by identifying two subsystems, implementation of the Field Office Change Management System can be accomplished in two phases. Second, it identifies the existing information system serving the upper level of the organization as one of the two subsystems.
Approval Management System
Project and Task Management System
While there have been several attempts to implement a change management system at the field offices, most of them have fallen short in addressing the needs of the user support aspects of IT in the field offices. Improvements in the existing change management system can be identified by comparing the existing system with the ideal system. However, there is no well defined change management system currently in place, and there are discrepancies in the mostly informal procedures used in the current change management system. Because of the complexities of modeling an informal system, a strict comparison of the actual system to the ideal system is difficult. Therefore, the author has chosen to point out a number of shortcomings of the current change management system (Table 2).
An Assessment of Current Field Office Change Management System
Shortcomings of the Current Approval Management System
Shortcomings of Current Project and Task Management System
Bryan Ruby is the owner and editor for CMS Report. He founded CMSReport.com in 2006 on the belief that information technologists, website owners, and web developers desired visiting sites where they could learn about content management systems without the sales pitch. Besides this site, you can follow Bryan at Google+ and Twitter.