It’s true that PMI encourages to keep the project to it’s scope (and boy do we know that scope creep can be a real project killer!), but PMI also encourages to revisit the scope throughout the project lifecycle. In other words, scope can creep, as long as it creeps in a controlled way.

But I agree with you, it is important to A) know how to read between the lines when interpreting requirements to implement a flexible system that will meet today’s requirements, but also tommorow’s requirements, and B) know how to define requirements properly in the first place.

The problem, of course, is that it’s almost always cheaper to paint yourself into a corner in the short-term. From a practical standpoint, too often we design and implement to the current compensation plan *exactly*, rather than designing to how the compensation plan works generally.

Quick example: I want to rank Payees assigned to a Territory within their Region. Great, so I go off and configure the system to rank occupied Territories within their respective Regions. (Let’s assume, too, that I only care about occupied Territories. In other words, I’m ranking the Payees, and not the Territories themselves).

Too bad the *generic* requirement is to rank occupied low-level Geographies within a higher-level Geography. If I design poorly, I’ll forever need to go back to IT resources to change “Region” to “District”, “Big Geography”, “Nation”, etc.