Business Analyst Interview Question: Suppose you are working with a difficult business stakeholder who keeps expanding what she wants your project to deliver. How do you handle scope creep?
Before addressing how to manage scope creep, it’s important to define what scope actually means. It’s also important to know why scope creep is a problem.
The Business Analysis Body of Knowledge (BABOK), version 3, defines scope as the boundaries of control, change, a solution, or a need. A business analysis project reflects a business need and creating a solution to meet that need. Requirements that are considered part of the project are within its boundaries and are in scope. Other requirements may be related to the project but the BA or the business may decide they are out of scope.
If scope means boundaries, then scope creep happens when the boundaries suddenly change. This often occurs when a business stakeholder or product owner decides that the current project cannot or should not proceed without some new, additional requirements. Often the stakeholder wants to add a new feature. The project starts to get bigger and bigger, especially when the scope creep continues.
The problem with this is that projects are tightly regulated things. Businesses create cost and time estimates for their projects so they can plan appropriately. When the business adds a new requirement, it can impact the cost, time, or staff needed to analyze the impact and complete the project. The business may have allocated the extra money and staff required to another project already. It may also lack time to complete the project with the new requirements.
Timing is also critical. If scope creep happens early in the planning stages of a project, the analyst may address it relatively easily. But scope creep that happens when the project is deep in software development can derail the project entirely.
Here are the strategies for dealing with scope creep.
Strategy #1: Explain the consequences
You can inform the stakeholder of the consequences of the scope creep. The new requirements will probably add additional expense and delay. The scope creep may add complexity to the project that makes it more difficult to test in the time remaining. It may endanger other projects. Or the project could fail entirely.
Whatever the situation is, make sure that your stakeholder fully appreciates the consequences and risks of changing the project scope right now. The stakeholder may be accountable for the success of the project, so he will have an incentive to work with you to resolve the problem.
If you can’t convince him to eliminate the additional scope entirely, then the other strategies can help with that.
Strategy #2: Re-schedule the additional scope
Perhaps the most popular way to address scope creep is to push the new requirements into the future. You may be able to work with a project manager to create a new “phase” of the project to accommodate the additional requirements. This phase would then get its own plan and budget, just like any other project.
If you are working in an Agile software development environment, then you can add the new requirements to the Scrum product backlog. They can later become user stories and a set of features that agile developers implement in a future “sprint.”
The downside of this approach is that it may just not be possible. The business stakeholder may lack the time or money to schedule future work.
Strategy #3: Take something out of the project
The third approach is to require your stakeholder to make some tough choices. If the new scope is so important, then perhaps the stakeholder will agree to remove requirements and proposed features that are part of the current project. Once you remove those requirements, you create “capacity” to accommodate the new requirements. The removed requirements can go away permanently or you might be able to move them to a future project as per strategy #2.
The downside of this approach is that it may just not be feasible to rip out part of the current project. That depends on where the project is in the software development life cycle. Removing requirements may work early on in the planning phase. But once the thing is half built you’re going to have a really hard time removing features.
Strategy #4: Escalate
Sometimes you just can’t get your stakeholder on the same page. None of the strategies work, and he keeps insisting you accept the scope creep. When that happens, it’s time to appeal to a higher power as a last resort. Escalate the problem up the chain of command so that someone with the appropriate authority can arbitrate a final decision.
How would you answer a Business Analyst interview question about managing scope creep? Leave your thoughts in the comments!