A Product Manager who increases the scope of a project while keeping the delivery date the same.

• Can mutate into: ”The Scope Wiggler” Product Manager
• Dangerous when coupled with: “The Tyrant” Project Manager
• Likelihood of fixing: None
• Danger to project: Extremely High

Problem

For as long as projects have existed in human history, the Scope Creeper Product Manager has existed. In our everyday life, scope creep is the norm for things as simple as grocery shopping to as complex as home renovations. On a software development project, the consequences of a Scope Creeper Product Manager can be dire, as increasing scope without moving the delivery date will directly result in project failure.

To be a Scope Creeper, the Product Manager must have following two characteristics:

1. They define the scope
2. They set the delivery date

The Scope Creeper is a problem because they will not give the project more time to build the additional scope they have added.

For any project, there is a overwhelming probability that scope will increase thanks to:

• Customer feature requests that, if not met, will result in lost revenue.
• Requirements that were always desired by the stakeholder were never documented by the Project Manager.
• Competitive pressure putting more demands on the product’s feature set (especially true of long-running projects).

Also, for any project, there is a overwhelming pressure to meet a delivery date thanks to:

• Keeping the faith of the stakeholders
• Keeping the project within budget
• Meeting revenue targets
• Meeting contractual obligations

The Scope Creeper Product Manager is caught between a rock and a hard place, and has made the choice that asking the project team to produce more in the same amount of time is a better option than trimming scope.

Across the software development industry, the Scope Creeper is the #1 source of misery for project team members, as there are only two ways to produce more in the same period of time:

1. Increase efficiency
2. Work more hours

If a project team is lucky, they can simply improve efficiency to absorb the additional scope. More often, however, the response is to work more hours, which has the following devastating effects on the project:

• Top talent will leave, as they can easily get jobs at companies who will not demand long work hours
• The people remaining will burn out, dramatically reducing their productivity
• Quality will go out the window at every level, as quality is first to go when long hours are demanded

This inevitably results in the project missing it’s deadlines, or meeting them with very low quality, or both resulting in the failure of the project.

Solution

To recap on the phenomenon that results in a Scope Creeper product manager:

• They have increased scope.
• The will not move delivery date.
• The result of increasing scope without moving delivery date will result in project failure.

Therefore, by definition Scope Creeper product managers will cause the project to fail. The solution lies in taking one or both of the following course of action

• Reduce scope.
• Move delivery date.

Which is far easier said than done. Indeed, if it were that easy, there would be no Scope Creeper Product Managers, and the software development industry would be far better off.

It is important to realize that an organization creates a Scope Creeper Product Manager by allowing the following tenets to remain in place:

1. Projects must deliver all requirements asked for.
2. Projects must not miss delivery dates.
3. It is acceptable to have employees work overtime to meet delivery dates.

Therefore, even if you replace the Scope Creeper Product Manager, their replacement will simply become the new Scope Creeper. As a result, the only solution is to change the organization, and organizational change can rarely be done in time to save a project.