The Need for Change Management
The key is that whatever you call it, changes need to be managed and
controlled so that their consequences are assessed before (and if) they are done
and they are approved and prioritised and then introduced at at appropriate
time, together with any other matching changes that need to be done elsewhere.
This is true for any product in any industry, not just IT.
Change management inevitably brings with a level of bureaucracy that can slow
the process down.
The key in any new product development programme is to decide when items
should be brought under formal change control and what that process looks like.
In the early stages it is not productive to have too much in the way of change
control, if any. While a designer is still struggling to come up with a viable
design, he does not want to have to fill in a form every time he changes his
drawing or CAD model.
However once other people become involved, especially purchasing and
manufacturing, then it starts to become important, so that the correct release
level of parts are bought and made. Thus a level of change control is usually
implemented once a part has been officially released.
Types of Change Control
Change control and management processes can take many forms and sometimes
there is a different (less formal) process while a product is still in its
prototype stages, compared to when it is in production. One type of change
control that has gained traction over the years and seems to have quite a lot to
recommend it is the CMII process from the Institute of Configuration Management.
Many PLM vendors have incorporated this process and one of the beauties about it
is that it can have a Fast-track version for minor changes, as well as the Full
Track version that you might expect. See this example for PTC's Windchill PLM
A study by Harris Kern of changes in IT departments found the following: