Scope Creep’s Impact on Analysis-EN

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:

1. Communicate, Communicate, Communicate: You just can’t talk thru, draw thru, or discuss the scope too much
2. 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.

• 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 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

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:

1. 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.
2. 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
3. Performing a rough-order-magnitude (ROM) impact analysis as it relates to:
   • Scope
   • Time/schedule
   • Cost/resources
4. Evaluating the cost/benefit
5. 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.

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.

Thank you,
– Jacqueline