Change management
Students should understand there are a number of factors that need to be managed to ensure change is successful. The way that change is managed can have significant effects on employers and employees.
Change management tries to manage:
- Workforce issues, such as redundancy/retraining
- The time frame involved in merging the two systems
- Testing of the combined systems/new data
- Data entry if migration not possible
- Costs involved in the aligning of the two systems
- Changeover decisions such as parallel running etc
SL version[edit]
When you have a system that is working, it is common to get requests to change the system. There is a difference between a feature request, and a bug report. If something if isn't working, a user should file a bug report and report it needs to be fixed. If everything is working and the user wants to change it, we begin the change management process.
The important thing to understand about change management is you MUST carefully consider all the possible ramifications of the change. Changes must be carefully planned, implemented, tested and then refined. We don't just make a change without thinking because this could create unintended problem later on. We could also create technical debt that we will need to pay later. Changes should follow the same process as building software (that is, the design cycle).
Change requests usually originate from:
- system enhancement requests from users
- events in the development of other systems
- changes in underlying structure and or standards (e.g. in software development this could be a new operating system)
- demands from senior management (Dennis, Wixom & Tegarden, 2002).[2]
HL version[edit]
Change management should be supported by a change management system. This is a system which tracks requests for change, assigns unique ID to a change request, and allows developers to collaboratively work on the change. Every part of a change needs to be recorded and tracked.
The more complex a system is, the more important it is to manage change effectively.
Finally, just because a user requests a change doesn't mean you should make it. Requests for change are related to the stability of a system. If a change would radically change the system, or make it less stable (or secure) the change may have to be denied. Please be careful, because systems must support users. If you do not change, your users will start using better systems.
Real-world practical advice[edit]
"Hey can you change this one little thing for me?". This is a very common request. Here's the thing: users think a request is minimal, "no big deal" or "just a little thing". But because end-users don't have a full picture of a system, they do not have information to evaluate if a change is minimal or if it is more involved.
When a user asks you to change something, you should smile and take a deep breath. You should then spend time carefully understanding exactly what functionality the user wants and how you can best plan and implement the functionality.
In larger organizations, there is a well-established Request For Change process which uses a change request form[3]. Always think before you make a change.
Standards[edit]
- Describe the need for change management.