Day 49 — Stakeholder series 4/7: “Managing Scope”
In the project management world, sometimes we heard the acronym MEDS, which stands for Manage Expectation and Defend Scope. Why is so important to defend the scope? What causes the problem of scope management? And what tools can we use to effectively manage scope?
In this article, I’m laying out some common problems with scope management, and sharing powerful tools from my experience in the following structure:
- Scope: two sides of the coin
- Common Problems
- Counter Measures
One Scope Doc, Two Perspectives
Scope of Work, or SOW, is a common language that’s spoken between product team and sponsor/stakeholders, in order to communicate what will be done at the end of the project. According to Wikipedia, the definition of Scope is:
- Project Scope: “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.”
- Product Scope: “The features and functions that characterize a product, service, or result.”
Sounds simple enough, doesn’t it? Then why do so many teams struggle with maintaining and delivering product based on the agreed scope? Scope serves as a way for the “requestor” team and the “maker” team to discuss and align on what needs to be done. Unfortunately, sometimes one team sees the head of the Scope coin, and the other team sees the tail. A lot of times, the two different perspectives of the scope create big issues when the deadline approaches and tension becomes high.
If you have worked in a design agency or consulting space, you might be familiar with the term DDS: Define and Defend the Scope. It’s not uncommon that teams see the need of “defending” the scope, even though arguably the ownership of the scope belongs to both sides. That said, what are the common problems and what causes them?
Common Problems
Below are some problems I’ve witnessed several times that created tension, caused troubles for both product teams and stakeholders:
Ambiguity
Most of the scope problems come from the definition phase. Both sides thought they agreed on the same thing, turns out they are quite different. Without any visual aid or other alignment tools, the perception of can be easily skewed by all kinds of assumptions and biases.
Scope Creep
When the scope change is considered a uncontrolled growth, it is generally considered harmful. This can occur when the scope of a project is not properly defined, documented, or controlled. In other words, we might hear/receive requests that seem unreasonable or not feasible at the moment, but it’s up to the team to determine whether the request will go into the scope or not.
Last Minute Change Request
Even if the change request is reasonable, if it comes in at the last minute, it still becomes a burden to the team, because there might not be enough time to plan for it and implement it correctly. Also, the change request might have larger impact to the existing feature set, therefore should not be handled in a plug-and-play way.
That’s probably enough scope problems waiting for us to solve! What are some of the way to push back these change requests? Or how can we prevent these problems from happening?
Counter Measures
Vision, Value, and Outcome
Early on, if the team can define clear business/ user value and aspirational outcome, we can have an honest discussion with stakeholders when scope creep and last minute change request happen. For example, does a “built-in message” feature plays a crucial part of the vision? If not, maybe we can wait. How much does “feature A” increase the overall business/user value, for the MVP scope? How do we track the successful metrics of the aspirational outcome? Often times this discussion helps clarify what we try to achieve and get us out of the weeds.
Persona & Scenarios
Another way to resolve stakeholder’s scope change is to anchor the request with Persona & Scenarios. If you have created clear personas & scenarios, simple discuss with your stakeholders: how would “Jessica the data scientist” see the value of receiving a “like” from others on this data modeling tool? Where does it fit in her working scenario? A lot of times, these kinds of conversations help reduce unreasonable requests or last minute change request.
Go Agile
As Agile Principles indicate: “ Welcome changing requirements, even late in development.” Agile frameworks like Scrum, Lean, and Kanban have rituals and mechanism that are designed specifically to handle last minute change requests. For example Scrum teams measure their velocity and are flexible in planning stage about what user stories go in or out. In Kanban, team limits how much work can be implemented in each stage so that the work environment is sustainable in the long term. Also, the concept of user story with the elements of “as a specific role”, and “so that I can…” help indicate business value, also help team to think through if the request feature actually add value to the target users.
“ When in doubt, cut it out” — Scope Management
“ When in doubt, cut it out” — other techniques
What if you don’t have any of these framework/research work setup? What are some other tricks you can pull? There are some easy-to-pickup tools:
- Scope Freeze: Make it clear in the beginning of the project that, at certain point of time, there will be a Scope Freeze to prevent Scope Creep. Communicate the date, and when it’s close by, remind your stakeholders for “the last call”.
- Icebox: In case there are some last minute ideas come in that doesn’t fit in to the current scope, a way to gently push back is to utilize the concept of Icebox. Simply say “I like this idea, but unfortunately it’s late to implement in the current scope, therefore we’re going to put this idea into the Icebox to keep it fresh, so that we can pick it up in the next phase.”
Conclusion
- Scope problem sometime could be communication problem. Clearly defining the request is the first step to resolve unreasonable scope change.
- When dealing with scope creep, make sure the request is aligned with the value, desirable outcome, and it’s actually useful based on the persona and scenarios.
- When dealing with last minute change request, use Agile way to absorb the request, or simply use Scope Freeze or Icebox to punt it to later.
How do you deal with scope creep? Any thoughts on pushing back last minute change request? I’d like to hear from you.
ABC. Always be clappin’.
