Skip to main content

The Business Analyst’s Accountability in Scope Creep and Changing Requirements

In my classes and consulting work I get the same complaints when I ask teams about the biggest roadblocks in requirements work: 

  • “My stakeholders keep adding features.”
  • “My stakeholders keep changing the requirements.”
  • “My stakeholders don’t know what they want.”

BAs, PMs, and even developers point frustrated fingers at stakeholders who constantly add or change requirements, priorities, features, and needs. They quickly cast blame on stakeholders who don’t really know what they want and can’t define and protect the boundaries of the project: the impulsive sponsor, assuming business manager, the indecisive subject matter expert, the ambiguous architect or the distracted CIO.

Who’s the worst offender? Who’s the biggest scope creep on your projects? Well, I am sad to say, it might be you!

No matter if you work on traditional or Agile projects, your role is to facilitate the discovery of requirements, with an approach that assumes your stakeholders do not know what they want or need. Your role is to help them figure that out. Scope creep and requirements changes often come from a lack of discovery and analysis of the originally stated requirements.

If your role includes requirements elicitation and requirements management, you may need to step back and take a long, hard look at your mindset when working with stakeholders. If your stakeholders seem confused, frustrated, indecisive, bored, unavailable, demanding, then you might be the root cause of the scope creep problem!

Do you expect your stakeholders to know their requirements? Do you expect them to know all the details, data, rules, processes, people, and systems impacted? Do you expect them to tell you all of this in an organized manner? Stakeholders have ideas visions, pain points, and needs. It is up to us as BAs to help them express and discover how it all comes together as part of a solution.

BAs and PMs often blame stakeholders for constant changes in scope and requirements when the true fault often lies in the quality of the requirements processes, tasks, and techniques. The quality of how well we elicit and draw out the very details and requirements, the quality of the dialogue and analysis we stimulate in stakeholders, the team, and ourselves later becomes scope creep and change if we do not draw out the requirements that creep up on us later.

In Agile projects, we elicit requirements based on value management principles and priorities rather than scope management. Value management principles are similar in that we need to constantly facilitate what features add the most value to the organization and prioritize the backlog accordingly. Scope management, when done well, also facilitates value management by ensuring we have analyzed and elicited requirements of the most value to the organization. These are often assumed and unstated requirements of our stakeholders.

We need to change our perspective and approach requirements differently. We need to approach requirements as a learning and discovery process. We need to help our teams uncover, discover and model scope. We need to develop and maintain our team’s shared understanding of scope, vision, and priorities throughout the project.

I see two types of scope creep and requirements change:

  1. Something external or internal to the project changes and it impacts the scope and requirements of the project and/or solution
  2. Requirements and scope are discovered as stakeholders and project team members evolve their thoughts and work together to uncover the details and impacts of the solution.

The first one is common to all projects, regardless if they are agile or traditional and we need to be ready for changes. The second type is where we can influence things dramatically as BAs.

How can you do your part to prevent scope creep and create shared understanding?

1. Check in with yourself on mindset: Are you approaching the requirements process expecting your stakeholders to tell you what they want? Or are you approaching it with a mindset that you are a facilitator of discovery? Don’t gather, elicit. There are always exceptions, but most scope creep and requirement changes are due to a “gathering” mentality instead of an “elicitation” mentality.

When a BA “gathers” requirements it implies a passive approach where stakeholders spoon-feed requirements to the BA. This passive approach, which does not include any analysis, leads to many missed requirements and fluctuations in scope.

When we “elicit” requirements, we iteratively extract and analyze stakeholder knowledge. We use probing and high impact questions and interactive elicitation techniques to help stakeholders discover and explore requirements. We use facilitation skills that promote meaningful dialogue and inspire active collaboration. Strategic elicitation minimizes scope creep by helping teams uncover assumptions, risks, and constraints.

2. Customize Your Approach. Do not assume you can use the same techniques for every project! This assumption will eventually lead to scope creep, erratic requirements, rework, defects and failed projects. Instead, be thoughtful in planning the requirements approach for your project. Every project is different. Every stakeholder group is different. Plan your approach based on what you know at the beginning of the project and refine the approach as you go.

Use powerful techniques to engage stakeholders and get them talking about the solution in ways that bring out more impacts, angles, and details. Techniques like collaborative games, prototyping, creative facilitation, and bringing analysis frameworks into facilitated sessions to bring out engaging dialogue.

Use techniques that create a framework for dialog that help stakeholders fill in the pieces that they would not have known to tell you. Techniques like Process Modeling, SIPOC, Business Model Canvas, Business Rules analysis, User Story Mapping, to name a few.

3. Focus on the Why and the Value. One of the best ways to start your scope management process is to help your team define WHY:

  • What problem is your team trying to solve?
  • What need are you trying to fulfill?
  • • What opportunity are you trying to exploit?
  • • Why are the stated requirements important to the stakeholder?

Once you create a shared understanding of why, then maintain it and use it to focus your stakeholders when defining the value the requirements bring.

4. Find the Gaps. There are always gaps! Why? Well, it’s the nature of project work. You just can’t know everything at the beginning—so keep your eyes open and help your team find the gaps. As a project evolves, gaps appear in many shapes and sizes, so challenge your team to find/uncover/unearth all: stakeholders, dependencies, constraints, assumptions, systems, processes, end users, personas, etc.

Warning: Don’t expect to locate all gaps in one big brainstorming effort at the beginning of the project. We need to approach requirements as a learning and discovery process. The discovery is iterative—it evolves over time. Be sure to systematically analyze, integrate and share each new piece that lands in the puzzle.

5. Draw Pictures. Visual models are often the best way to get conversations started and highlight gaps in shared understanding. Pictures prevent scope creep and missed requirements by providing context for discussions. They illuminate gaps and assumptions in ways that words/text can’t. Pictures also improve engagement and interaction by moving multitasking eyes away from other distractions and devices.

You can create pictures by gathering information from stakeholders one-on-one before a large group session or you can use facilitation techniques that help stakeholder groups create pictures for you. Just present a basic model or informal drawing and let the stakeholders react and learn and then update the model collaboratively.

6. Let people think. You can’t expect to hammer out solid, complete, stable requirements in a single session. Even if the session is a full day or a full week, you will miss requirements and/or you will miscalculate user needs if you do not give yourself and others time to step away and think.

Your team will make better decisions and will be able to more clearly define what they want if they get time to reflect in between elicitation sessions. They will be able to share information with their team, bounce ideas off others, and evaluate ideas in the context of their daily work, rather than being sequestered in a marathon, one-and-done workshop.

This iterative elicit and analyze approach also gives BAs the time they need to evaluate stakeholder input and refine the requirements approach as the project evolves:

Angela August 1

7. Expect Change. Here’s the bad news…change happens! Even teams with awesome collaboration, expertise and shared understanding will experience changes in requirements and scope. So, plan for it! Change will be less disruptive if it’s an expected and accepted part of your approach.
BAs need to accept at least partial responsibility for scope creep and requirement changes. The quality of a BA’s elicitation, facilitation, modelling and analysis skills has a significant impact on the project. BAs who strategically engage stakeholders to create meaningful collaboration and shared understanding will experience significantly less scope creep, requirements changes, defects and rework.

Comment