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. 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—As mentioned before, the more complete requirements are defined and understood, the likelihood of scope changes are reduced.
- 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 projects that are client-vendor oriented. 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” incentives 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. TipRather 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.
- 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, early and frequent product reviews, 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—This is another technique that will not prevent change requests, and that might not be applicable to all project situations; however, if it does work, 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 definitely is part of your risk response plan, too, but part of your watchdog mindset is to keep a close eye on the project assumptions and constraints. If these change, your project will definitely be impacted.
Leave a Reply