In this case, “changes” are usually based on sudden alterations of requirements during the project or on the realization that the implementations of specifications will be more complex – or indeed impossible – in the manner that was originally intended.
So in these cases, change management does indeed mean a significant intervention in the project. The risk management methods that are applied additionally and simultaneously are insufficient to guarantee success of the project. The necessary instruments will also require flexible handling.
If the situation boils down to the duration of the project as the principle aspect, it will be necessary during change to check whether the technical requirements (e.g. product version, support services) and other factors have become different as well. Doing so ensures that the preconditions defined in the original planning retain their validity.
While in practical settings there may certainly be circumstances that make change (specifically in ongoing projects) necessary (e.g. changes in case law or legislation), the majority of changes that are typically encountered can be prevented by prudent investments in the identification of requirements and in project planning. Meaningful “requirements engineering” (recording and analyzing requirements as an upstream process) and other processes can help to avoid this type of “changes”.
This statement retains its validity for the agile approach as well. After all, it is absolutely essential that any components of the solution that require smooth integration in the platform are clearly defined in the architecture and that their functions are implemented purposefully.