Scope change is often cited as the greatest problem in project performance. In our simulation, we deal with scope endogenously; the actions of the team determine when scope is discovered and what they should do about it.

"Improving Understanding"
As the project unfolds and work is completed, the ability of the team to communicate in a meaningful way with teammates, users and the sponsor grows. For example, when the blueprint of a building is complete or all of the screens on a computer system are built, it is much easier to have a meaningful conversation about user, team and/or sponsor requirements. When the team takes action to harvest this newly created potential for team, user and sponsor communication the clarity of needs, dependencies, and constraints of the project increases. All these new learnings are potential changes in scope that the team must evaluate. If they decide to incorporate the new ideas and they complete the new work, they are create more potential for team, user and sponsor communication. Of course not all ideas are good ideas. The teams will have to make trade-offs between conflicting ideas and they will have to manage bad ideas to keep them out of the scope. This reinforcing loop encourages the team to be receptive of scope change but at the cost of additional work to be done coming from increased scope and rework due to the new requirement.

"No Change Pressure"
Eventually someone on the project will either explicitly or implicitly freeze the scope after which there will be a lot of reluctance to change. This dynamic is easy to see. The more work that comes from changes in scope the lower the schedule and budget adherence becomes. When cost and schedule are too far off of the initial projections the project manager or sponsor will step in a say something like: "We have got to stop redesigning and deliver what we have got. We can always improve it after it is installed." Changes will not be accepted even if relevant and valuable new ideas are being thought up and discovered in the field.

"Don't Listen to Ideas for Change"
If the team does not explicitly freeze scope, they can implicitly freeze it by simply turning a deaf ear to new ideas. When time pressure is high there simply is not time for team coordination, sponsor communication or user interaction. The team does hear any new ideas so there are no new ideas to incorporate.