What Causes Unplanned Scope Changes?

To better manage project changes and project risks, and to minimize the number of scope changes, it is important to understand the leading causes for unplanned scope changes on a project.

• Shift in business drivers Due to the dynamic nature of the business world today, things can change quickly. These business changes can have an immediate impact on existing projects. Examples of business drivers that can alter a project's scope include
  • Available budget/funding for the project
  • New government regulations
  • Changing target market for the product
  • Time-to-market pressures
  • New business opportunities
  • Changing customer priorities
  • Unexpected market or world events
• Shift in project acceptance criteria Addresses changes in either the targeted completion date, financial return on investments, client satisfaction ratings, quality levels, other expected benefits, or the stakeholders who need to approve.
• Shift in technology With the move to shorter duration and phased projects, this is not as much of an issue as it has been in the past. However, there are still times when new technology becomes available during a project that will significantly meet the needs of the customer much better than what is currently planned.
• Poor scope statement If the scope statement is incomplete, ambiguous, inconsistent with project assumptions, or does not address the complete business workflow process, you are much more likely to have project scope changes. Of course, this would only happen on projects that you inherited and would never happen on projects that you helped define. Right?
• Poor requirements definition There are entire training courses on requirements definition and requirements management due to the importance they play on project success. Suffice to say, the more gaps that you have in your requirements, the more scope changes you are likely to have. For your awareness, here is a list of the leading reasons for poorly defined requirements:
  • Ineffective or wrong techniques used to gather requirements
  • Communication breakdowns between analysts and stakeholders
  • Requirements are not aligned with project scope
  • Requirements do not address complete process work flow
  • Documented requirements are not meaningful to targeted audience
  • Requirements not reviewed for inconsistencies
  • Requirements not verified for correctness and completeness
  • Missing stakeholders
  • Users signoff without a "real" understanding of what the documented requirements mean