You’re in a project meeting; team members and stakeholders are having a great discussion when it happens…one of your key stakeholders says: “Our system is going to do live chat too, right?” You’re caught off guard. Some folks think “Sure, no problem”. Others strongly say “NO!” What do you do? (BTW, “panic” is the wrong answer…)
Your team may automatically call this scope creep. But what is scope creep?
Scope creep can mean many things depending upon context, but it is generally meant to be something that is beyond the agreed to benchmark or scope.
Scope creep and project change happens… manage it (or more importantly embrace it)! Projects are ultimately done to add value. If the change requested adds value, you need to be prepared to manage that change.
Change happens, no matter what methodology you’re using: waterfall, agile, or some hybrid variation. While specific tactics, tools, or terminology may vary based on the methodology, the principles of managing change are essentially the same.
Managing scope occurs throughout the entire project lifecycle and requires a clear, shared understanding of the initiative’s goals and objectives at all levels of detail. So remember: Managing scope is not a one-time activity – it’s an ongoing effort.
Managing Scope Creep and Change is a Team Effort
So how do you ensure that the entire team gets and stays on the same page?
This can be a tough question to address based on several different project factors, including team size and location, project complexity, the number of stakeholders, etc. If your team isn’t on the same page relative to the scope, change requests can cause chaos and friction among the team. I have found the following points can keep a team focused on the same scope:
- Communicate, Communicate, Communicate
You just can’t talk through, draw through, or discuss the scope too much - Ask… Don’t Assume
People hear things differently, interpret things differently, and describe things differently. The easiest way around that is to ask them to play it back to you. Don’t assume they “get it.”
This is not a one-time event, but rather an ongoing effort. In agile, there are retrospectives to recalibrate where the team is and where they are going. Even in Waterfall, it’s critical to get back on the same page after each change.
Through my experience, I’ve picked up some handy tools and techniques that I’ve found helpful in ensuring my team is on the same page. The key to all of these techniques is that the team members and stakeholders are doing the talking – as a business analyst, you are listening to see if they are saying the same thing!
What’s In / What’s Out
Have a discussion to walk thru each of the goals included and items excluded from the project. Ask second and third questions to make sure that the full impact of what’s included and what’s excluded is understood.
Story Telling / Future Visioning
This is a fun exercise. Start off by asking various stakeholders: “Tell me what it’s like when the project is done and working.” This will help your team think about how the workflow will operate, and some of the various scenarios that they are planning for the solution to resolve. This exercise can give you some insight into the future of what the business group is expecting.
This helps everyone get a common vision of what life looks like once the project is implemented and builds an expectation of how users will be engaging with the system.
What-If Analysis
This is a great role-playing exercise where you can help suspend fear and encourage problem-solving with imagination. Start with…
“Not saying it WILL, but, what if?”…
- “If this occurred…what could happen? And what if that …?! What would that impact mean for our project cost/time? What warning signs could we look for?”
- “If that impact happened…what would it take to recover? What contingencies might we consider?”
- “If this occurred, what could happen?” What are the potential consequences or outcomes – what ‘next’?
- “If this needs to be the outcome, what would it take to get there?” How can we work backward to figure out the steps?
This technique works over the range of best-case to worst-case scenarios and a variety of exceptions. It helps the team develop alternatives to help the project succeed “if…”.
If the team is on the same page, the change request will be less traumatic and disruptive. If the communication is addressed, the rest can be relatively simple. Get more advice on stakeholder communication in our How to Improve Your Stakeholder Engagement Quick Tip.
A Simple Approach to Manage Scope Creep and Evaluate Changes
The key, regardless of methodology in play, is learning how to quickly understand what the change represents and determine its impact on the overall initiative or project. Some requests may drive actual scope change and project re-initiation or scope reset, while others may be resolved with a re-prioritization of features/functions.
The following diagram shows a simple way to view the process to evaluate changes:
1
Reference Your Scope
In order to evaluate the impact of a change request, you must first have a clear and shared definition of scope to reference. The scope is the boundaries of control, change, a solution or a need. Ideally an initial scope is established in the beginning and should be maintained throughout. If one hasn’t been established, stop and gain that shared understanding.
As each change is initially considered, the scope document or artifacts will be a reference point. Some changes will challenge the scope. A stable scope will help the whole change management process go smoother.
You’ve heard it many times before, but it’s worth repeating: Clarity of scope is critical to project success.
Having a clearly defined and understood scope provides several benefits:
- Forms the basis for identifying changing requirements and assessing what to do about them
- Reduces conflict and misunderstandings when dealing with change
- Unifies stakeholder expectations
- Provides a common understanding for prioritization
- Simplifies solution design discussions for any changes
- Is a reference point for the negotiation and decision-making
- Helps to identify the type of analysis needed based on the level of detail the change
At the highest level (in varying levels of detail) a good scope should contain the following:
- Problem/Opportunity Statements
Clearly state the problem(s) to be solved and the proposed solution - Goals/Objectives
State the goals to be satisfied by the solution and any objectives that must be met to be considered a successful project - Assumptions/Constraints
List relevant assumptions about things like resources, technology capabilities, other project’s functionality and any constraints that impact the overall approach to the project - In-Scope Capabilities
What business processes need to be improved or developed. For small projects, a list may be sufficient. For larger projects, a visual approach such as a decomposition diagram or story map may be more useful. - Explicit “Not In Scope” List
Often more important than a generic “in scope” list is a clear “not in scope” list – it helps minimize assumptions about the solution.
To help us understand how best to manage a change request, we need to determine whether the change impacts the scope or requirements or both.
- High-level changes must be evaluated against objectives, goals, and business drivers
- Lower-level detail changes may become a feature/function prioritization issue, not a scope change
- Also, we need to understand if this impacts what we are doing now vs. what will be done later.
- We must ensure that all parties (and project teams) are seeing the change in the same perspective or context, e.g., will it be done in the program, but not in this project, etc.
Sometimes it’s quite clear that a change request is in scope and that the request is more of a feature or function change. Change requests related to in-scope features and functions require an additional level of impact analysis at the requirement level which we cover more in Step 3 below.
2
Collect Key Change Request Data
The change request must be evaluated against the scope. A change request can be formal or informal. The change can come from a stakeholder on the project. It may be a result of an external influence such as change in the business or the industry. It could be something that is identified during requirements elicitation, a revelation or discovery by the technical team, or even the result of testing.
The requester typically provides some information but additional information will likely be elicited. The intention is to get just enough to help make an educated decision.
There is certain information that is important to collect. The collection of the information will take a combination of resources who have knowledge of the variables involved in the change. Some of the information includes:
- Is the change a corrective action, an update, a preventative action, an enhancement
- Urgency of the change, impact to the business
- Technical requirements
- Risk of making the change and of not making the change
- Estimate resources and cost
- Implications to testing and quality control
- The business case and how it’s aligned to the scope
In most cases, this is enough information to proceed to the next step. In some cases, the analysis is more involved and might require a prototype, a deep dive or proof of concept. It’s also advised to do some research to see if other options and alternatives have been considered.
3
Conduct Impact Analysis
Impact analysis involves doing an assessment to quantify and qualify the effect of a proposed change on current priorities, limitations, deadline, budget, resource allocation, and priorities.
There are formal and informal ways to do the assessment. Generally, you are looking to accomplish the following:
- Compare the requested change to the current scope. The context diagram provides a high-level representation of scope and can often be used to quickly determine if something is in or out of scope. Other tools that can help with this assessment include the decomposition diagram or user story map. The results of those comparisons can set the tone for how deep into the scope the analysis may need to go.
- Perform a rough-order-magnitude (ROM) impact analysis as it relates to:
- Scope
- Time/Schedule
- Cost/Resources
- Evaluate the cost/benefit
- Obtain approval to proceed with research. A deep dive or research into a new request can take resources from the work in progress and may require approval.
To save time and effort when a deep dive or evaluation of the functionality and features is needed, ensure your requirements are organized. One way is to organize your requirements based on how your stakeholders see things and how scope changes may impact the overall initiative or project.
For example, you could organize your requirements in the following categories:
- Business requirements
- Stakeholder requirements
- Solution requirements
- Transition requirements
- Others, including domain, timing (release/phase), traceability to goal, or status
It’s important to put some upfront thought into how your requirements are organized. Scope creep can come when you least expect it. You’ll appreciate being able to find things quickly. Some changes are urgent and with that you want to move as quickly as possible to Step 4 as long as you have all of the essential data and information you need.
4
Facilitate Negotiation and Decision Making
At this point you have determined whether the change is in or out of scope, you’ve collected the necessary information, you’ve done an impact analysis and, if needed, a deep dive into the requirements to provide the right level of information so that a decision and determination can be made. Now it’s time to facilitate the decision-making process. This includes:
- The BA facilitating negotiation of the change and reaching a decision
- Agreeing upon scope, priorities, timeline, resources and execution of the change
- Establishing requirements related to the change
- Updating the appropriate documentation and reporting the changes in the scope, timeline and resources needed to execute the change
Out of scope changes will often have a great impact, as both the scoping and requirements documentation will likely need rework. This could also impact work that is already in progress. A major change in scope would result in what is called a reset.
A change that is in scope still goes through an appropriate level of scrutiny. Something can be in scope but a nice to have not a must have. In scope, items have to be weighed against the other priorities. If every new request that came through became the new number-one priority, the project would be volatile and chaotic.
In Summary
You’re in a project meeting; team members and stakeholders are having a great discussion when it happens… one of your key stakeholders says:
“Our system is going to do live chat too, right?”
This time, you’re NOT caught off guard…your scope is well-defined, documented and understood… you have a process to figure out what to do… and you begin the process…
This time, you know change is coming, sometime, and you’re ready to manage it:
- you have your scope clearly defined
- you know what information you need to collect
- you know how to go about your impact assessment and leverage the scope documentation as your base line and then
- you are ready to help facilitate a decision and from there
- you will document and communicate, communicate, communicate
Now you are comfortable and ready to embrace change. Change can be a good thing. A change that adds value in the eyes of the business is worth consideration and evaluation.
Editor’s Note: This blog post was has been previously published by B2T on our former website. Due to its popularity and relevance, Kathy has updated its content to be more comprehensive and accurate for the state of today’s environment.
