No matter how well a project is planned and how well the requirements are defined, there will always be requests to change something about the project, usually the product being delivered. There are good reasons for this; business doesn't stand still while your project is going on so we expect that ongoing business will trigger the need for changes to the system being built to support that business. These changes are mission critical to the project in many cases. If the system isn't changed to reflect business needs as they will be when the system is implemented, your project will succeed in building a system to support business as it was done 6 months ago! These changes are why project managers need a good Change Management Plan and process.
Failing to properly plan the project's work or sloppy requirements gathering will certainly lead to requests for change and will probably overwhelm the project's resources with change requests to analyze and implement, no matter how solid your Change Management Plan and process are. Failure to define a change management process that meets your project's needs and plan process activities will lead to: the wrong changes being implemented, budget wasted on the wrong changes, failure to reserve sufficient time for analysis of change requests, refusing changes that would add value to the project, exceeding the budget, and late delivery.
Project length is another source of change requests. The longer the project goes on, the more the business changes, the more the business changes, the more the system must change to support the business. The insulation of the development cycle from the impact of change is one objective of iterative development methods. With iterations, fewer changes are likely to be requested. Software development projects with long delivery time lines can expect to experience a flood of change requests towards their end.
All changes are not created equal. Another common error in the area of changes is the tendency to treat all changes in the same way. The administrative effort required to process a request to change the color of a button on a website screen from red to maroon should not be the same as a request to double the number of pages on the website. Attempts to force requested changes through a laborious process designed to support major changes to project baselines will meet with resistance. There are two possible outcomes here. Either the team will prevail and will start making the minor changes behind your back or you will prevail and stifle minor changes that ought to be made because they add value to the product.
Yet another common mistake is to have the wrong people make decisions about changes. This mistake is related to the failure to provide different processes for different changes, but it is possible to provide the right process for each magnitude of change and still identify the wrong people as decision makers. The decision makers for a change should be those people, or that person, who has the best grasp of the pros and cons of the change. The decision maker should also be someone who has the authority to approve any budget changes. The decision on whether to approve the change in the colour of the web screen button should be made by someone who is knowledgeable enough about web design to predict its affect on users. The decision on whether to double the number of screens, and probably double the cost of the project, should be made by someone who has the authority to double the budget. This may be a customer, a sponsor, or an executive steering committee.
