Scope Change vs Scope Creep…. Predictive vs Adaptive

Several posts recently on LinkedIn have made some interesting, and incorrect, claims regarding ‘scope’ in project management.

A few of these have suggested that project mgmt views *all* changes to scope as bad (scope ‘creep’), and that this is why ‘adaptive’ approaches were necessary – to accept that scope *will* change and be open to it.

So let’s start with the basics – Scope CHANGE ≠ Scope CREEP. 

ALL projects experience scope CHANGE. Whether you’re building a doghouse or a spaceship, your scope WILL change at some point. 

The difference between scope CHANGE and CREEP is how those changes are handled. 

Scope CREEP occurs when the proposed changes are added to the scope of the project *without* any review or assessment, understanding of the impacts, or approval by whoever is in charge of the project/initiative. Scope Creep is UNCONTROLLED change.

Scope CHANGE is when the proposed changes *have* been reviewed and assessed, the impacts are understood, and they have ben accepted by the Owner of the project. Scope Change is CONTROLLED change. (rejected changes are not due to ‘resistance to change’, but to ‘that particular’ change)

Now, is there a difference between how a more predictive approach addresses proposed changes vs an adaptive approach?

No.

And this is where I think so many get confused. The process for controlling change in both predictive and adaptive approaches is virtually the same. 

In a predictive approach the proposed change is first evaluated. What is this, why is it being proposed, does it affect the cost or schedule, how will adding this to the current scope impact the work done, in progress, or planned (the impact), etc.? Once these questions are answered, the proposed change (and impacts) is presented to the project Owner and they make the decision whether to accept the change or not. 

This is called Change Control and leads to Scope Change.

When the proposed change *does not* go through this process it’s called ‘uncontrolled change’, and is considered Scope Creep.

So what happens in an adaptive approach? Is the proposed change automatically accepted because “we welcome change”? No.

The proposed change is added to the backlog, where it is then reviewed and assessed by the Product Owner and team, to answer the questions of what is this, why is it being proposed, how will adding this to the current scope impact the work done, in progress, or planned (the impact). Note here that cost and schedule impact are less an issue not because the approach is ‘adaptive’, but because in the iterative approach cost and schedule are more ‘consistent’.

But the proposed change is only accepted and eventually worked on if the Product Owner approves it. Finding a proposed change and adding it to the backlog doesn’t mean it’s ‘approved’. 

See the difference? No? Because there isn’t one.

Both approaches follow the same process – recognize that a change is necessary or desired, evaluate the change and what accepting the change means to the rest of the work or the project, Project/Product Owner makes a decision whether to accept or reject the change. Neither is allowing ‘uncontrolled’ change to take place. 

Both are versions of ‘change control’. 

There are only two real differences between the two approaches. 

1. Predictive approaches rarely have a backlog/parking lot where proposed changes go first before they’re evaluated. The review/evaluation usually happens as they come up. 

2. The backlog and iterative approach likely helps make ‘enforcement’ of the change control process easier as it’s central to the process. But, that’s not the result of ‘predictive’, but more the lack of rigor of how change control is implemented. 

*I’ll note here as well that some like to refer the Change Control Board as an impediment to change approval, but there’s nothing in an adaptive approach that says a Product Owner isn’t also answering to a higher group about ‘priorities’, so I think that’s a red herring. 

*originally published on LinkedIn