It is said that the only constant in the world is change. You can make perfect plans, but they cannot account for every potential change that may occur. The longer your project, the more likely you will be dealing with changes. This is one reason why the TenStep process understands that the initial definition and planning processes do not have to be perfect. You and your team need to do the best job you can given what you know at the time. That is good enough. After that you need to manage the changes.
There are a number of aspects of change that can occur on a project.
- Scope changes
- Configuration changes
- General changes (non-scope, non-configuration)
On most projects, the most important aspect of change is scope change management.
Scope is the term used to describe the totality of the work and the overall boundaries of the project. Scope is used to define what the project will deliver and what it will not deliver. For larger projects, it can include the major deliverables that are created, the affected organizations, the transactions impacted, the data types included, etc.
If you look at the reasons that projects fail, it is usually the result of two problems. Either the team did not spend enough time defining the work and / or there was a lack of scope management. Even if the project manager did a good job of defining scope, the hard part comes in having to manage the project within that agreed-upon scope.
The purpose of scope change management is to protect the viability of the approved Project Charter and the approved business requirements. In other words, the Project Charter defines the overall scope of the project, and the business requirements define the deliverables in detail. The project team committed to a deadline and budget based on this 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 new estimated cost, effort and duration now become the approved target.
Sometimes the project manager thinks that scope management means having to tell the client no. That makes the project manager nervous and uncomfortable.
However, the good news is that managing scope is all about getting the sponsor to make the decisions that will result in changes to project scope.
This is very important. Few clients can see and express every requirement up-front. Therefore, there are usually changes that need to be introduced during the project. These changes may be very necessary for the solution and there may be valid business reasons why they should be included. The project manager and project team must recognize when these changes are requested. Then they must follow a predefined scope change process. 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.
Configuration management is the term given to the identification, tracking and managing of all the assets of a project or the characteristics (metadata) of the assets. In some organizations this process is more narrowly defined to mean only the management of the physical assets.
Your project may experience changes that do not necessarily fall under scope change management or configuration management. These changes can be grouped into a general change management category. For instance, lets say one of your team members leave and needs to be replaced. This would not be an example of scope change and it is not a configuration change. It is a general change. In this case, you may need to document the fact that a resource change occurred, determine the impact of the change, put a plan in place to manage the change, etc. In many respects, you will follow a similar process to that of a scope change request, although this change, and the impact on your project, is not the result of a scope change request.
One of the key differences between general change management and scope change management is that you expect that is a scope change is 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. In fact, there may be an impact on schedule and budget. However, there should not be an automatic expectation that a schedule or budget change would be granted.