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? First, off don’t freak out.
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.
OK, 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 on-going 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 a 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 thru, draw thru, 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 on 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 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.
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 backwards 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 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:
Step 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 (see box below).
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
Gain a Shared Understanding of Scope
Clarifying the scope starts with knowing what type of scope we are talking about.
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. If it impacts the scope, then the first thing is to understand which type of scope is in play: Solution, Product, Project.
Here are some quick definitions of the three types of scope:
- Solution Scope: The set of capabilities a solution must deliver in order to meet the business need
- Product Scope: The features and functions that characterize a product, service, or result
- Project Scope: The work that must be performed to deliver a product, service, or result with the specified features or functions
Solution Scope vs. Project Scope
As you look at the change request, one key difference to know is if it is impacting the solution, the project, or both.
- Sometimes it is simple, the solution is your project
- Sometimes your project is one of many to address a solution
- Sometimes your project supports multiple solutions
Make sure the entire team understands the scope of the request. Also, if another project is involved, make sure both teams are in alignment about which project will provide what functionality.
Project Scope vs. Product Scope
Sometimes, the solution may be delivered via multiple products, multiple projects, or only one of either those things. Again, if the scope change crosses project boundaries, it’s critical that both projects are in sync about which project is providing what functionality.
Scope can be a very high level concept or a very low level concept.
Change requests must be aligned to the proper type of scope and timing within project:
- 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.
A good scope is made up of several components.
At the highest level (in varying levels of detail) you should at a minimum define the following for all of the scope types:
- Problem/Solution 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
- High Level Processes: a list of processes that the project is expected to include
- 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
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 Request related to Feature and Functions require an additional level of impact analysis at the requirement level which we cover more in step 3 below.
Step 2: Collect Key Change Request Data
The data from the change request information will be evaluated against the scope. A change can be a formal or informal request. 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 occurs during requirements elicitation, a revelation or discovery by the technical team or it could be a result of testing.
The requester can provide some information but additional information likely will 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 will 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.
Step 3: Conduct Impact Analysis
The impact analysis is doing an assessment to quantify and qualify the change compared to the current priorities, limitations, deadline, budget, resource allocation in relationship to the original scope and priorities prior to the change request.
There are formal and informal ways to do the assessment; generally you are looking to accomplish the following:
- Compare the change to the scope including various related documents. Of all of the models, the Context Level Diagram is a visual diagram of the scope, so it is usually the first diagram used to quickly determine if something is in or out of scope. That can then set the tone for how deep into the scope the analysis may need to go.
- Assessing if the change request resides inside the current scope or not, if it is outside the scope, it may take leadership or executive level approval
- Performing a rough-order-magnitude (ROM) impact analysis as it relates to:
- Evaluating the cost/benefit
- Approval to proceed, to do a deep dive or research a new request could take resources from the work in progress, so for some projects that requires a formal sign off.
To save time and effort when a deep dive or evaluation of the functionality and features is needed, the key is insuring 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 buckets:
- 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.
Step 4: Facilitate Negotiation and Decision Making
So 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. This typically includes:
- The BA facilitating the negotiation of the change and then based on the decision, the scope, priorities, timeline, resources and execution of the change are agreed upon
- Establishing the 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 have a great impact, both the scoping and requirements documentation will likely be 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.
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.