Straight Dope on Scope
Changes to scope are inevitable, but they aren’t created equal. Good scope changes occur as you discover requirements that serve project goals and align to product vision. Here are three tips for systematically managing product scope with an understanding of business, customer and technical value considerations.
For years, project managers were taught to resist any changes to the scope of a product during development. Scope creep, we were told, would doom our projects. The problem? Scope happens. Resist them as you might, changes to the scope of your product are inevitable.
But not all changes are created equal. “Bad” scope changes occur late in delivery, when time, money and stakeholder goodwill are heavily invested in the status quo. In contrast, if your team’s goal is also learning, exploring and deciding, “good” scope changes occur, and are expected, as you discover your product needs (requirements) that serve the overall project goals and align to the product vision — assuming your team has a systematic plan for accommodating change. Let’s take a look.
Tip 1: Understand Product Versus Project Scope
It’s critical to distinguish the scope of your project from the scope of your product — the software application, system or device containing software. It’s a matter of knowing the difference between
Please log in or sign up below to read the rest of the article.