'''ChangeManagement pertaining to software projects'''

Since change is an inevitable factor in the development of software, the processes or practices developed in the management, execution and accounting for the change must be considered.  Changes are not isolated and independent events, and often the effects which are generated by a change can snowball and become unmanageable. 

Therefore: It is necessary before deciding to implement a change, that consideration be made of not only the positive effects of the change, but the side-effects as well, both positive and negative.

This may refrain one from being able to RefactorMercilessly. The resolution from a management point of view is to decouple implementation from publication (or delivery). One may even publish gradually, or backtrack.
-----

Often in BigIron shops there are dedicated SoftwareConfigurationManagement functions. These have a ChangeManagement dimension (or component) to it. In SCM, software configurations can be compared whether they correspond to successive states in time, or to alternative or parallel situations (i.e. in metaphorical space). Somehow, Change Management breaks this clean orthogonality, and introduces an additional, and so far arbitrary, distinction. Thus often, Change Management is handled through a ProcessApproach, instead of through a management one.

----

One could then speak of Change Control instead of Change Management -- The more you control, the less you manage. -- MarcGirod

This is well and good if one can control change. But reality sets in when we suddenly become aware that ChangeHappens. 
* One cannot control change merely by ignoring it or by being totally unaware that it is happening every day. 
* One cannot control change by refusing to allow or make room for change. 
* The best we can do is to RespondToChange. 

If my approach to controlling change is that I refuse to allow it, I am in effect saying something not unlike "Today's machines, methods and means are adequate for now and the foreseeable future." (My 486 was good enough in 1987, and I still use it today). It may be true, but what you were doing then, may not fit what needs to be done today.  

The attempt to avoid change is often the approach taken by the people who are suddenly rudely awakened when they found that they were to be among those who were to be "DownSized".  

One must control change by adapting to the changes, or otherwise the changes will be found changing things you cannot control.  


----

''How can ChangeManagementAppliedToWiki? -- FridemarPache''