Different Types of Scope

I’m using the notion of “scope” as an umbrella term to cover all the things that need to be done or delivered to complete the project.

We all love projects where the scope is well defined. Everything we need to do in the project is listed in clear language that both the client and project team perfectly understand. All we need to do is break the scope down into tasks, assign them to our team, and Bob’s your uncle, we have a successful project.

However, sometimes the scope isn’t like that. Here are a few other types of scope to consider. When you encounter one of these, it might be worth noting this risk to the project.

Iceberg scope: a request/feature that looks simple and small but actually has a lot behind it.

Unrecommended scope: client (or other key stakeholder) wants something that the project team thinks is a bad idea. Maybe it’s not worth the effort. Maybe it’s a dark pattern of operating.

Discovered scope: (aka second order scope) The things that arise after the project has started.

Understated scope: As the client is describing the scope, they downplay the hard parts or leave out elements that signal how difficult it is.

Vague scope: the description of the items in the scope are poorly defined. Usually there are fewer details

Technical scope: The client doesn’t care/understand this stuff (most of the time) and they aren’t able to put a value towards it.

Drifting scope: The client wants something but it’s not tied to business value. Sometimes this is for vain reasons. Sometimes this is a pet features of a key stakeholder.

Spider-web scope: Scope that is tied to other things so when one thing moves, it means more changes to other aspects of the project