Powerful Techniques for Minimizing Project Changes

The following techniques are powerful change prevention actions we can take:

Clear project definition—The more effort spent upfront 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—Discussed in previous posts 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—Although formal sign-offs do act as strong “stick” incentive to get stakeholders involved, there is nothing like having professional, knowledgeable, and 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/no-go decisions at phase-ends

Use WBS to illustrate impact—This technique might 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 effect 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 might 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 affect the customer experience), you can guide the CCB to defer the request to a future project or a post-implementation phase.

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.

Although 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. Hence using the above discussed techniques must be carefully used to minimize project changes.