In this section I described this pandemonium where everyone is sharing, "show me yours, I'll show you mine", and in general providing feedback. I discussed the need for feedback, and some ways the feedback can be given. The result of it all is change. Changing requirements, changing realization of these requirements. I quoted before: "Unless the job has previously been done and only modest changes are needed, it is best to assume that the requirements are wrong."

There are several reasons why requirements change:

• Stakeholder changes his mind. By discussing, thinking about it and reflecting on the subject, a stakeholder can change his mind on what he wants.
  


• Project team interpreted requirements different than intended by stakeholder. Two people don't understand each other.
  


• "Forgotten" requirements pop up. During the project intake and the requirements determination the scope is determined and the initial requirements are written down. In this process you can forget one or two requirements that appear during the phase of feedback.
  


• Changes in the project surroundings. Things happened outside the project that can affect the project directly. A merger or reorganization, a new policy for buying supplies, a new law, etc. The fluctuation in the surroundings can change requirements. The longer a project runs, the more vulnerable the project is to this type of changes.

The software project manager has to roll with the punches; these changes are a fact-of-project-life, so he has to deal with it. However, to be able to construct something, requirements should be relatively stable, at least long enough to build and test stuff.

This stability, can be forced by not allowing changes to the requirements, they are frozen. Requirements in a project will have alternating periods of change and freeze. It's the role of the project manager to manage this process. It's called "change control": the process by which a change is proposed, evaluated, approved or rejected, scheduled and tracked.

The key issue is to install a change control procedure that forces people to go to one central point of entry for the project. E.g. project management will decide if a change in the requirement set is accepted or rejected. Only one person is allowed to change the set of requirements. This is one procedure I really recommend putting in place.

Links of Interest
The Secret To Coping With Change: MIND + NETWORK