A well-managed project starts with a well-written plan.
For project managers, the first defense against scope creep is a clear and comprehensive product requirements document, which outlines the features, objectives and criteria for a product and provides a roadmap for its development. A good PRD defines the scope of a project. A great one also articulates what is out of scope.
Aviva Schmitz, a technical product manager at Los Angeles-based customer acquisition platform System1, explains that including a list of features and functionalities that are beyond the scope of a project helps prevent delays and disappointments down the line.
“With this list, I’m much better prepared to engage in a dialogue with a stakeholder who approaches with a request during the development phase,” she told Built In Los Angeles. “The request, or one like it, is probably already on my list, so I have evidence that the decision to descope it was not an oversight but rather a logical and intentional choice that was carefully considered by everyone who reviewed the PRD.”
If all stakeholders sign off in advance, everyone has an idea of what to expect and there’s less risk of a project getting sidelined by added deliverables.
Below, Schmitz shares insights on evaluating the complexity of a project, differentiating between acceptance criteria and success criteria and keeping scope creep at bay.
System1 uses data science and machine learning to help businesses optimize their marketing and advertising strategies.
How do you monitor and evaluate the scope of projects?
When assessing the scope of a project, many product managers rely on story points or ticket count. But without context, these metrics provide an incomplete picture of the true scope.
Consider two projects, each comprising 50 tickets worth a total of 100 points. One project’s tickets are assigned to engineers from five teams. There are clear dependencies among the tickets such that a high level of coordination is required. One team can complete the second project’s tickets. Most of us know intuitively that the first project will take much longer and is much broader in scope, yet they look identical when examined on the basis of story points and ticket count.
This is why I like to present these metrics alongside the context that makes them more meaningful. If the project includes multiple deliverables, categorizing tickets by the deliverable they support makes it easy to assess how close each deliverable is to completion and how complex it is in comparison to the others.
This strategy also helps prevent scope creep. If a ticket doesn’t fit under one of the deliverables, chances are it falls outside the scope of the project and should be relegated to the backlog.
When you notice scope creep, what do you do to manage it? What steps do you take to keep the project on track?
As a product manager, I think it is important to anticipate scope creep and mitigate it before it arises. When writing a product requirements document, I include a list of features that are not in scope for the project and add to it as I gather requirements. Ideas for new functionalities that are not directly in service of the stated goal of the project go on that list. If a stakeholder raises a problem or pain point, I also put it on the list, unless solving it would result in significant progress toward the project’s goal.
I also ask the reviewers to officially sign off, in writing, on the PRD before any development work begins. These signatures, which can be included as an addendum to the PRD, powerfully demonstrate that the project’s scope was defined thoughtfully and should be respected.
What mistakes do you see other product managers make when it comes to scope creep? What advice would you offer to those PMs?
Scope creep can result from conflating acceptance and success criteria. Acceptance criteria describe the specific and measurable conditions that must be met to satisfy stakeholder requirements, whereas success criteria provide a way to evaluate the project’s overall impact. When acceptance criteria are fulfilled, the project is finished, even if success criteria remain unmet.
Scope creep can result from conflating acceptance and success criteria.
Consider a project to solve the customer pain point of slow shipping by moving logistics in-house. “At least 50 percent of orders delivered within 10 days” is a possible acceptance criterion, while success criteria could include “a 25 percent increase in repeat orders.” It’s entirely possible to meet acceptance criteria but miss success criteria. If moving logistics in-house reduces shipping time but increases costs that the company passes on to customers, repeat orders could decrease.
In this scenario, many product managers may introduce new requirements to cut costs. But good ones will not allow scope creep to prolong a flawed project. They will recognize that the project is over because the acceptance criteria have been satisfied, then take what they’ve learned and apply it to the next project to make sure it succeeds.
