It's said that the only constant in the world is change. You can make a great plan, but you can't account for every potential change that may occur. The longer your project is, the more likely you'll be dealing with changes. Since you can't predict every change, the best that you can do is that manage the changes that do happen.
There are three aspects of change that can occur on a project.
1. Scope change
This is the most important change to manage. Scope is defined at two levels — high-level scope describes the boundaries of the project and the major deliverables to be built; Low-level scope is defined through your approved requirements.
The purpose of scope change management is to identify change and manage it effectively. It also protects the project team from changes made after the commitments to schedule and budget are agreed to. In other words, the project team committed to a deadline and budget based on the high-level and detailed scope definition. If the deliverables change during the project (and usually this means that the client wants additional items), the estimates for cost, effort, and duration may no longer be valid. If the sponsor agrees to include the new work into the project scope, the project manager has the right to expect that the current budget and deadline will be modified (usually increased) to reflect this additional work. This process ultimately brings the appropriate information to the project sponsor and allows the sponsor to decide if the modification should be approved based on the business value and the impact to the project in terms of cost and schedule.
2. Configuration change.
Configuration management is the the identification, tracking and managing of all the assets of a project, and the characteristics (metadata) of the assets. (In some organizations this process is more narrowly defined to mean only the management of the physical assets.) In most projects, configuration management doesn't come into play. However if your project uses or builds a large number of components, parts, artifacts, equipment, and so on, configuration change management could be very important.
3. All other changes.
Your project may experience changes that don't necessarily fall under scope change management or configuration management. These changes can be grouped into a general change management category. For instance, let's say one of your team members leaves and needs to be replaced. This would not be an example of scope change or configuration change. It's a general change. In this case, you may need to document the fact that a resource change occurred, determine the impact of the change, and put a plan in place to manage the change. In many respects, you'll follow a similar process to that of a scope change request.
One of the key differences between general change management and scope change management is that you expect that if a scope change is requested and approved, you will change your budget and schedule to accommodate the change. You should not have that same expectation for non-scope related changes. For example, in the example above when a team member needed to be replaced, there was definitively a change, and there will probably be an impact on the project. However, there is no expectation that this change will result in an approved schedule or budget change.
As a project manager, you should focus on making sure that you manage scope change, which is a primary culprit when projects have problems. However, you should be aware that your project may need to have a configuration management and general change management process as well. Managing all these aspects of change may save you countless hours of trouble.