Powerful Techniques for Minimizing Project Changes

While we want to be prepared for project changes when they occur, we want to spend most of our energy preventing the need for changes in the first place. The following techniques are powerful change prevention actions you can take:

• Clear project definition The more effort spent up-front to get agreement on clear project objectives and success criteria from the appropriate stakeholders, the less likely we are to get change requests during the project.
• Solid requirements definition Mentioned before when we looked at the common reasons for scope changes.
• Trace requirements There is nothing like linking any work specification to its original source to control project scope. By tracing and showing the relationship from the original business objectives down to the detail design specification, you can identify (and possibly eliminate) any scope expansion when it is first proposed. If the proposed feature does not link directly to a higher level specification, it is a potential scope change.
• Formal acceptance sign-offs Formal sign-offs are a key aspect of change control management, especially for client-vendor oriented projects. The formal record of review and acceptance of a given deliverable helps to keep expectations aligned and minimize potential disputes.
• Engaged stakeholders While formal signoffs do act as strong "stick" incentive to get stakeholders involved, there is nothing like having professional, knowledgeable, engaged stakeholders who are committed to doing their best as the best weapon against unplanned scope expansion. A team of people who want to work together and get the job done can accomplish the work at hand with a "less formal" level of project management.
• Use the right project approach This technique is more about risk management, but change control and risk management are very intertwined. As mentioned before, if you know there is likely to be a high degree of change, structure your project in a manner that allows for deliberate, planned scope expansion (prototyping, iterations, cycles, and so on). For all projects, the following approaches help reduce the number of project changes:
  • Emphasis on project definition and planning
  • Shorter timeframes (1 year or less is preferred)
  • Pilot tests
  • Phased implementations
  • Go-NoGo decisions at phase-ends

• Use WBS to illustrate impact This technique may not prevent change requests from being submitted, but it can help you classify something as a change (and not part of the intended scope), and it can help you communicate the impact of the proposed change. By reviewing your detailed WBS, you can show that the work for the proposed feature was never accounted for, and you can show what other work items will be affected by adding the proposed change.
• Defer to post-implementation Another technique that will not prevent change requests, and that may not be applicable to all project situations; however, if it does, it can reduce impact on the project success factors. If the change request is legitimate, but is not absolutely critical to the initial release (there is not a workaround, it does not adversely impact the customer experience), you can guide the CCB to defer the request to a future project or a post-implementation phase.

  tip

  Rather than capturing assumptions and constraints in various project documents, capture them together in a single document. This makes it easier to communicate, update, and track throughout the project.

• Track assumptions and constraints This is definitely part of your risk response plan too, but part of your "watch dog" mindset is to keep a close eye on the project assumptions and constraints. If these change, your project will definitely be impacted.