Wouldn't it just be easier to forbid requirements changes on a project?
The way things change on this project, we're going to end up producing a race car when the customer originally wanted a bicycle. Wouldn't it just be easier to forbid requirements changes on a project?
No doubt there are times when we all feel it would be great to issue a ban declaring requirements changes unlawful—times when it would be a lot easier to "just say no" to the folks requesting changes. But, tempting as it sometimes may be, refusing all changes is the wrong approach for a couple of reasons:
Requirements changes may be needed for the project to meet the most important goals. The fact is, as we never tire of repeating, requirements change. Business needs change, the economy changes, technology changes. It can be dangerous for the requirements to remain static and not change in step. (A Vision document and a Flexibility Matrix are two items that can help a team define up front, and document changes to, what is MOST important to customers and the company.)
NOTE: The inevitability of change has brought us valuable, widely used iterative project methodologies such as Agile. These approaches embrace the reality of changing business needs and technologies, and enable project teams to work with change to achieve successful solutions. (See our Agile resources for info on agile concepts and techniques.)
Requirements and overall scope changes may be needed to be successful given new constraints. The original plan may have called for certain resources that are no longer available. A new business need might suggest an earlier release date, and we have to decide between finishing everything on the original schedule, or releasing earlier with less scope. (Cost-Benefit Analysis, Late Cost Per Week, and Trade-off Tables are all tools that can help a team weigh the options and make decisions.)
Requirements changes may be needed to correct mistakes. Changes can improve a project by incorporating missed requirements or clarifying inaccurate requirements. A great number of project overruns and failures can be traced to missed or faulty requirements, so the sooner they are caught and corrected, the better (and cheaper!) for the project overall.
Whatever the reason for project changes, if you define a change control approach (using a simple change form, if desired) that's appropriately scaled to the project and team, you'll find that managing changes isn't so bad after all. Some basic components of the change control process are relatively easy to scale to your situation, regardless of your formal documentation process or whether you've decided to review changes remotely or face-to-face.
A requirements change control process should:
Allow any team member or stakeholder to submit an idea for a change
Communicate to everyone how changes should be suggested and how they will be reviewed
Allow a change idea to be vetted by a small subset of project team members to ensure its value, feasibility, and legitimacy
Include due diligence for evaluating the impact on the project and/or solution
Clarify who gets to ultimately decide on whether the change should be made
Clarify how any changes should be documented and proactively communicated.