Category: Business Analysis

Posted on by

Three proven ways analysis prevents scope creep

Close up of two colleague at computer working on proven ways analysis prevents scope screep

Scope creep is one of the most persistent challenges in project management. One minute your project is aligned and under control, and the next, you’re fielding new feature requests, “quick” changes, and sudden stakeholder expectations that weren’t in the original plan.

But while scope creep is often blamed on stakeholders or shifting priorities, it usually starts earlier—with incomplete or unclear analysis. When business analysis is rigorous, scope creep doesn’t just get managed; it gets prevented.

Here are three proven ways analysis plays a frontline role in controlling scope and delivering successful projects.

1. Clear Requirements Prevent Ambiguity from Taking Root

At the heart of most scope creep stories is a set of vague or misunderstood requirements. That’s where strong business analysis changes the game.

What good analysis looks like:

  • Collaborating with stakeholders to elicit detailed needs, not just top-level desires
  • Documenting both functional and non-functional requirements
  • Using techniques like user stories, process models, and acceptance criteria to remove ambiguity

Why it works: When requirements are clear and complete, there’s less room for interpretation. This reduces the risk of stakeholders later saying, “Oh, I thought it would also do X.”

PM application: As a project manager, you can use business analysis outputs (e.g., validated requirements documents or signed-off user stories) as your baseline. It gives you a strong foundation to say, “That request is out of scope—let’s assess it through change control.”

2. Stakeholder Analysis Uncovers Hidden Needs Early

Scope creep often arises not from bad intent, but from stakeholders who weren’t properly engaged early on. Business analysts are experts at identifying and analyzing the full stakeholder ecosystem.

What good analysis looks like:

  • Conducting stakeholder mapping and influence analysis
  • Holding structured discovery workshops across roles and departments
  • Asking probing questions that uncover competing priorities

Why it works: When all key voices are heard early, you get a more complete picture of what success looks like. Late-breaking requirements from overlooked stakeholders are a major cause of scope creep—one that can be avoided with strong initial analysis.

PM application: Use the stakeholder register and communication plan developed by or with your BA to ensure engagement is active, not reactive. When new requests arise, it’s easier to trace them back to the stakeholder strategy and handle them methodically.

3. Impact Analysis Creates a Culture of Change Discipline

Not all change is bad. Sometimes mid-project shifts are necessary. The danger lies in treating every new idea as easy or free. That’s where impact analysis—a core business analysis discipline—comes in.

What good analysis looks like:

  • Assessing the ripple effect of proposed changes on time, cost, risk, and quality
  • Identifying affected systems, dependencies, and stakeholder groups
  • Providing decision-makers with clear data to evaluate trade-offs

Why it works: When you introduce discipline around change, teams become more thoughtful. Stakeholders understand that every change comes with consequences, which encourages more careful prioritization.

PM application: Use the BA’s impact analysis to support your change control process. It arms you with evidence to support hard conversations and reinforces a professional standard: we can make changes, but we won’t do it blindly.

Final Thought: Analysis Is Prevention, Not Just Documentation

The best time to fight scope creep isn’t when it shows up—it’s before the project starts. Strong business analysis brings clarity, alignment, and discipline to the table. And as a project manager, partnering closely with your BA (or stepping into that role when needed) helps you lead with confidence and control.

When analysis is proactive, scope stays in check. And when scope stays in check, projects stay on track.

Key Takeaways:

  • Clear, validated requirements prevent ambiguous additions later
  • Early stakeholder analysis ensures no critical voices are missed
  • Impact analysis gives teams the tools to assess and manage change constructively

Scope creep will always be a threat. But with strong analysis, it doesn’t have to be inevitable.

Posted on by

Strategic Planning: Project Managers & Business Analysts

Project manager working on strategic plan with team

Strategic planning isn’t just for the C-suite. For project managers (PMs) and business analysts (BAs), it’s a shared mindset—and when done well, a powerful collaborative edge. It’s what separates reactive task-jugglers from proactive leaders who shape business outcomes.

Too often, strategic planning is treated like a once-a-year offsite agenda item. But in project environments, it’s a daily discipline. Project managers and business analysts bring complementary strengths to the table—and when they plan strategically together, the results ripple across the organization.

Let’s explore how PMs and BAs can lean into strategy, together.

Where Strategy Starts: Shared Understanding

Strategic planning begins with clarity: What are we solving? Who are we solving it for? Why does it matter?

  • BAs shine here. They dig into business needs, ask the right questions, and define the problem space.
  • PMs turn that understanding into structure—schedules, budgets, risk assessments, and delivery plans.

When this early collaboration happens, it prevents teams from building elegant solutions to the wrong problems.

Tip: Start planning sessions with shared ownership of goals. Don’t just delegate requirements to the BA or logistics to the PM. Map the business case together.

Aligning Tactics to Strategy

Strategic planning isn’t abstract. It’s about making smart decisions with finite resources. PMs and BAs each bring a lens to these decisions:

  • PMs focus on feasibility and execution: Can we realistically deliver this on time and on budget?
  • BAs focus on value: Is this the right thing to deliver?

Both are essential. Without feasibility, strategy fails. Without value, delivery is irrelevant.

Think of the PM as managing the “how” and the BA as refining the “what.” Planning together ensures both are right.

Strategic Planning Throughout the Project

Planning isn’t a single moment; it’s an ongoing process.

During Initiation:

  • BAs clarify the problem, analyze stakeholders, and shape the vision.
  • PMs define scope, build timelines, and start risk assessments.

Together, they align on what success looks like.

During Execution:

  • PMs adjust plans based on progress, blockers, and change requests.
  • BAs validate that the solution still meets evolving business needs.

Together, they pivot smartly—without losing sight of strategy.

During Closure:

  • PMs capture lessons learned and close out deliverables.
  • BAs assess business value and post-launch outcomes.

Together, they inform future strategic decisions.

Strategic Tools for PM & BA Collaboration

Some tools that support strategic co-planning:

  • Business Case Canvas: Aligns goals, metrics, and solution fit
  • RACI Matrix: Clarifies who does what in strategy and planning
  • Product Roadmaps: Connect features to business priorities
  • SWOT or PESTLE Analysis: Contextualizes planning in wider trends
  • Backlog Prioritization: Ensures tactical choices reflect strategic needs

Use these together—not in silos. Strategy is a team sport.

The Human Side of Strategic Planning

This isn’t just about frameworks. It’s about relationship. The best project managers and business analysts:

  • Respect each other’s expertise
  • Share accountability, not blame
  • Stay curious and challenge assumptions

PMs can lean on BAs to deepen stakeholder insight and spot unseen dependencies. BAs can lean on PMs to translate vision into action and keep momentum focused.

One powerful habit: Do joint stakeholder walkthroughs. Hearing the same thing together often reveals misalignment faster than emails or handoffs.

Final Thought: Strategy Is a Shared Language

Project managers and business analysts are most powerful when they plan strategically together—not in parallel, but in partnership. In today’s pace of change, strategy isn’t static. It’s iterative, evolving, and rooted in insight. By combining delivery discipline with analytical clarity, PMs and BAs make strategy real. That’s not just good planning. That’s good business.

Key Takeaways:

  • Strategic planning is ongoing and collaborative
  • PMs and BAs bring different but complementary strengths
  • Aligning early prevents rework and delivers higher value
  • Shared tools and shared mindset create alignment
  • The strongest strategies come from shared understanding and trust

Let strategy be more than a slide deck. Let it be how you work, together.

Posted on by

White Paper on PMI-PBA® Certification Now Available

Woman looking at her computer reading PMI-PBA paper

Business analysis skills are no longer optional for a project team. Surveys continue to show that poor requirements management is the number one reason for project failures. Project managers either have to enhance their own business analysis skills or bring a business analyst onto their teams as a professional partner from the initiation of a project through closing.  Business analysis skills include critical thinking, elicitation, and requirements modeling. These skills and many more are now recognized with the PMI-PBA® Certification program, the PMI Professional in Business Analysis. Continue reading White Paper on PMI-PBA® Certification Now Available

Posted on by

Business Analysis: The Best Way to Start a Project

Team working on a project using business analysis

How do projects get started in your organization? A strong business analysis knowledge can save your organization significant time and money by weeding out low-value projects and prioritizing valuable ones based on business need and realistic, expected benefits. If you’re thinking, “well, it depends,” you are not alone. Few organizations have a well-defined, consistent way of deciding when work becomes a project.  Let’s dig in.

Six Step Process to Start a Project

  1. Receive Request for Work
  2. Analyze the Request
  3. Develop a Solution Approach and a Business Case
  4. Prioritize Against Other Projects
  5. Get Approval and Funding
  6. Assign a Project Manager and Start Planning

Evaluating Stakeholder Requests

Having a consistent process assures stakeholders that every request will be considered equally. As titles and job responsibilities vary in organizations, any professional with strong business analysis skills can manage this pre-project work. Follow these six steps to develop a structure for evaluating stakeholder requests.

Step 1: Receive Request for Work

All work starts with a request.  This of this as a potential project.  The work starts by someone inside or outside the organization asking for something to be changed, added, or removed from the organization’s processes or systems.  A request is the trigger that sets the work in motion and the requestors are the first known stakeholders.  There are generally three types of requests.

  1. A problem: The requestor or problem owner may have called the help desk or filled out a problem ticket. A problem can also be identified by a business leader from customer feedback.
  2. An opportunity: How can you improve value or increase revenue? An opportunity could help an organization more toward its goals more quickly. An opportunity may be a new product idea or a process improvement.
  3. A constraint: Constraints may be imposed on an organization by management’s internal policies or by an outside agency.

The organization must review requests to analyze importance, urgency, and priority.

Step 2: Analyze the Request

Not every request will bring the same business value to the organization.  Some requests are better than others, and some requests may not be good at all. You need to analyze the value of each request and prioritize accordingly. Project objectives should help articulate the business value. However, defining project objectives is challenging because stakeholders often have conflicting values and expected benefits.  Facilitating conversations about expected benefits, goals and objectives can help stakeholders reach agreement.

Value can be determined by worth or price, but it can also be influenced by missed opportunity costs.  That is why every project request should be evaluated for its business value. Select high-value projects by spending time upfront determining the expected business benefits and the costs.

Project requests can be added to one of three buckets to help determine if the project is worth pursuing.  A request that will resolve a serious problem impacting the organization’s ability to do business is a MUST DO.  If the request will cost more to improve that it will save in expected benefits should go into the REJECTED bucket. If a problem is less immediate, the request is placed in the LOOKS PROMISING bucket to be further analyzed and prioritized. The process of bucketing requests allows you to begin discussion the solution and build the business case.

Step 3: Develop a Solution Approach and a Business Case

When the initial analysis confirms the request is worth pursuing, the team needs to discuss solution alternatives and assess the estimated costs of each. Teams often use brainstorming techniques to generate creative, innovative ideas for solutions, then analyze each possible idea. Regardless of the method you chose, all feasible options should be considered before one is chosen.

Once the solution approach (or product vision) is agreed upon, it’s time to estimate the business value and costs involved in designing and building the solution along with the expected maintenance costs. These benefits and costs are then compared in a business case or cost/benefit analysis to determine if the request should move forward.

The business case includes the estimated net business value of the request with objective, measurable criteria.  Keep in mind that financial considerations are only one component of project selection.

Step 4: Prioritize Against Other Projects

Once a request has a business case, it can be prioritized against existing requests.  This backlog of requests should be reviewed on a regular basis, and the highest priorities should be promoted to projects.

Organizations that don’t follow this six-step process often struggle with prioritization. Sometimes the requester with the highest position in the organization gets their requests prioritized. Sometimes organizations respond first to the requests that are smallest or easiest to complete and never get to the bigger, more complicated initiatives.

Other organizations try to work on every request and wind up with overworked employees and few completed projects.  Prioritization is difficult, but it be easier if each request has a business case and a strategic plan for comparison.

Step 5: Get Approval and Funding

Just because a request is likely to add business value doesn’t mean the organization has the time or resources to complete it immediately.  Once a request has been analyzed and prioritized, someone in the organization must provide funding.

The project sponsor, as the key stakeholder, is the person or group (such as the steering committee) who provides the funding for the project. The sponsor may be the original requester the requester’s manager, or an executive.

If particular skills are needed, the sponsor could move employees off lesser-value projects or look for outside resources to fill the gaps.  If the project is requested by an outside customer, the price is established, and a proposal is presented to them.

When the value is financial, there are many formulas that can be used to evaluate and compare options.  Return on investment calculations estimate how much the organization will receive if they fund the potential project.  Other financial measure, such as the internal rate of return and net present value may be used. However, value can’t always be calculated in financial terms. In some cases, the best choice might be a project with a longer payback period with other intangible advantages such as customer satisfaction.

Step 6: Assign a Project Manager and Start Planning

Only after completion of the previous five steps does a request become a real project.  At this point, the organization assigns a project manager who begins planning the project.  When these six steps are complete, the project manager has great information with which to plan.

If a project manager struggles during project planning, it may be an indication that this pre-project analysis was not done.

Need Additional Help?

Business analysis work is not just about requirements. Deepen your Business Analysis skills and knowledge to help your organization to understand the business value and assess the importance of requests before you start a project.

Still have questions and need some extra guidance? Consider one of RMC’s popular business analysis eLearning courses including Business Analysis Fundamentals or Business Analysis: A Critical Role on Projects.

Sources:

https://rmcls.com/ask-the-why-question-it-really-works-requirements/

https://www.teamgantt.com/blog/how-to-prioritize-projects

Posted on by

BA or BSA: What’s the Difference?

A BA using a white board for project

In project management, few roles cause as much confusion—and occasional overlap—as the Business Analyst (BA) and the Business Systems Analyst (BSA). On the surface, the titles sound interchangeable. Both are embedded in the requirements-gathering process. Both spend their days translating ideas into actionable plans. But scratch beneath that surface, and the differences are not only meaningful—they’re crucial to delivering successful projects.

Whether you’re managing a new software rollout, overseeing a transformation program, or running a lean Agile team, understanding how BAs and BSAs function (and how they differ) helps you structure your project team more strategically. Let’s dig into what sets them apart, where they overlap, and how you as a PM can make the most of their skills.

What is a Business Analyst (BA)?

The Business Analyst is your go-to person for understanding what the business needs and why. They:

  • Investigate business processes
  • Engage with stakeholders to uncover pain points
  • Document requirements and workflows
  • Define the value behind proposed changes

Think of BAs as fluent in “business speak.” They’re the bridge between business users and the technical team, constantly asking: “Does this solve the right problem?” and “Is this what the business really needs?”

BAs typically:

  • Conduct stakeholder interviews and workshops
  • Write functional requirements and user stories
  • Map current vs. future state processes
  • Support solution validation (e.g., during UAT)

Their sweet spot is strategy-meets-execution: understanding the wider business impact of projects and aligning proposed solutions to company goals.

What is a Business Systems Analyst (BSA)?

The Business Systems Analyst shares some DNA with the BA but skews more technical. They dive deeper into how solutions will work within existing systems. BSAs:

  • Analyze how proposed changes affect system architecture
  • Translate business requirements into technical specs
  • Collaborate closely with developers, architects, and IT teams

They often:

  • Document data flows and interface requirements
  • Write system use cases and technical requirement specs
  • Review API documentation and system integration needs
  • Assist in solution design and data modeling

If the BA asks “what do we need to solve?”, the BSA asks “how will it actually work in our tech stack?”

BSAs usually come with more technical training, sometimes having backgrounds in software development, systems engineering, or database management.

Key Differences at a Glance

Aspect Business Analyst (BA) Business Systems Analyst (BSA)
Focus Business processes and stakeholder needs System requirements and technical feasibility
Primary Stakeholders Business users, sponsors, product owners Developers, architects, IT teams
Deliverables Functional specs, process models, user stories Technical specs, system flow diagrams, data mappings
Tools & Techniques SWOT, BPMN, wireframes, user story mapping ER diagrams, SQL, interface specs, system modeling
Typical Background Business, operations, product IT, systems engineering, development

Where They Overlap

It’s not a tug-of-war between BA and BSA. In many cases, their roles complement each other beautifully. On large-scale or complex projects, you might find both on the team:

  • The BA leads stakeholder discovery sessions and defines high-level business needs.
  • The BSA translates those needs into system-level requirements and ensures they fit within technical constraints.

On smaller projects, one person may wear both hats—requiring them to be equally fluent in business analysis and systems design. As a PM, this matters. Understanding which skill set your project needs (or lacks) is key to avoiding requirement gaps or scope creep.

Relevance to Project Managers: Why You Should Care

As a project manager, your job is to coordinate, align, and deliver. Misunderstanding the BA vs. BSA dynamic can lead to:

  • Ambiguity in requirements: You get a beautiful user story, but no system spec to build it.
  • Misaligned expectations: Business thinks they’re getting X, tech delivers Y.
  • Missed timelines: Because no one mapped how the new feature integrates with existing systems.

The right analyst structure reduces friction across teams, increases stakeholder satisfaction, and minimizes rework.

Here’s what you can do:

  1. Assess the complexity of the project: If it’s high on integration or backend dependencies, consider bringing in a BSA.
  2. Clarify roles early: Don’t let BA and BSA responsibilities blur. Define handoffs.
  3. Include both perspectives in planning sessions: Business needs + system feasibility = realistic planning.
  4. Be their translator when needed: Encourage mutual understanding. Sometimes BAs and BSAs operate in silos.

Real-World Example

Let’s say you’re leading a CRM implementation. You have a BA gathering requirements from sales and marketing teams. They document:

  • We need custom lead scoring
  • Reports should show conversion by campaign
  • Integration with email platform is required

This is great. But how does it work?

Enter the BSA:

  • Analyzes if the CRM’s API can support real-time sync with your email platform
  • Designs the database schema to track campaign IDs and lead scores
  • Writes the system integration documentation for the dev team

Without both perspectives, you risk either:

  • A feature-rich solution that can’t be implemented technically
  • A technically sound solution that misses business needs

Titles Can Be Tricky

To complicate matters, job titles don’t always reflect these distinctions. In some organizations:

  • A BA does system analysis because there is no BSA role
  • A BSA is called a BA but spends all day writing API specs
  • A “Business Analyst” might actually be more of a product owner

Titles aside, what matters is the actual skill set and responsibilities. Clarify early. Use RACI matrices. Ask the right questions during kickoff. Don’t assume the word “analyst” means the same thing in every department.

Which Role is Evolving Faster?

Both roles are changing, but the BSA in particular is being reshaped by:

  • The rise of Agile and DevOps, where system requirements must evolve iteratively
  • Increasing demand for hybrid BA/tech skills (think: data-savvy analysts who can also model APIs)
  • Tools like low-code/no-code platforms, shifting where technical complexity lives

Meanwhile, BAs are seeing increased influence in product management, service design, and strategic transformation.

As PMs, it’s your job to see where your analysts fit into these trends and make sure your team composition supports project success.

Final Thoughts and Takeaways for PMs

In today’s fast-paced environments, the difference between a Business Analyst and a Business Systems Analyst isn’t just a matter of semantics—it’s a structural decision that impacts project outcomes. Understanding who does what helps project managers:

  • Define clearer roles
  • Identify skill gaps
  • Avoid downstream technical misfires

Key takeaways:

  • BAs focus on business needs and stakeholder alignment
  • BSAs bridge the business-to-technical gap with deep system knowledge
  • Both are crucial, but their contributions differ
  • Clear role definition upfront saves time, money, and rework
  • As a PM, empower each role to work in tandem, not in parallel silos

A well-deployed BA and BSA can mean the difference between building the right thing—and building the thing right.

Know the difference. Use it to your advantage. Deliver better projects.

Posted on by

PM and BA???

Female PM working at with person at computer[et_pb_section][et_pb_row][et_pb_column type=”4_4″][et_pb_text]I have been talking about the importance of having a PM and a BA on a project for 10 years. Although I still would prefer this arrangement I recognize that few teams have the luxury of pure roles. So everyone needs to have a basic knowledge of project management and business analysis. Even if you have clear roles, it helps when you understand something about what your co-worker is doing. This multi-disciplinary approach really helps if you are moving to a more agile style work also.[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
Posted on by

Business Analysis Tools and Techniques

Business woman in thought resting chin on hand

The first time you became aware of the number of business analysis techniques, what was your reaction? Was it shock and awe, or a feeling that you would never be able to master all of them? Or were you familiar with many of the techniques, but not sure if you were using the most suitable ones in your business analysis work?

Establish and Add to Your Analysis Toolkit

Business analysts need a toolkit with a range of options that will enable them to perform tasks effectively and consistently. Challenges both inside and outside of project work—including figuring out how you can best elicit, document, manage, and communicate requirements—require robust and flexible techniques.

The business analysis techniques outlined in the Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is widely used across industries, and provides solutions to meet these challenges. But it can be difficult to find hard data about which techniques work best, in part because these techniques are being used across a wide range of industries and projects.

In addition, when choosing a technique, you need to consider numerous factors like time, cost, usage potential, business analysis competency, stakeholder preference, user knowledge, level of documentation, project environment, and company culture, to name a few!

8 Tips for Selecting BA Techniques

Let’s look at some tips that can help you get started to pick the most appropriate techniques for your project or initiative.

1. Categorize the Business Analysis Techniques You Currently Use

Just as we categorize requirements to make them more digestible, useful, and focused, we can do so with business analysis techniques. The categories you decide on will depend on your work and industry. You can categorize by business analysis knowledge areas, or by the business analysis tasks you plan to perform to create results and outputs.

For example, you may want to create a category for eliciting requirements. You can also create categories for types of interactions you have with stakeholder groups or based on your stakeholders’ preferences. There may be techniques you use that work best with developers or clients, for example. You may want to have a category for visual diagrams and another for text-based techniques. Categorization can also be based on other constraints, such as number of stakeholders, project complexity, time, or cost.

2. Add a Few Techniques from the BABOK® Guide to Your List

Now that you have the categories for your existing techniques, look at the techniques from the BABOK® Guide and other sources and place the ones that interest you in these categories. This may require you to read up on some of them.

3. Talk to Other Business Analysts in Your Company

Find out what techniques they use and update your list. Also look for examples and templates that exist at your company. Now that you have created your own quick reference chart, let’s talk about how you can choose the most appropriate business analysis techniques for your project or initiative.

4. Target a Project and Try a New Technique

Considering your current projects, think about where you have issues such as unclear or incomplete requirements and other challenges. The techniques you are using may not be providing you with the best results. Ask yourself if the root cause of the problem could be the techniques themselves. Talk to your stakeholders; ask for their thoughts and gauge their willingness to try something new. For example: Your requirements have not been clearly defined, and you have been eliciting requirements through interviews only. You may want to try interface analysis, observations, bench marking, or a requirements workshop.

5. Try a New Technique that will Challenge You

Look at your list of new techniques and pick one that you feel would be a challenge. It could be something you have never done before. Maybe process modeling is new to you. In fact, maybe you’ve never created a diagram before. Take an existing process that has already been mapped or modeled. Try to create your own model and compare it to the existing model, you may gain a better understanding of the process. Then look for an opportunity to create a process model for an existing process that has not been modeled. You’ll be learning and adding value at the same time.

6. Ask Your Stakeholders What Techniques They Prefer to Use.  Try on a New Project

This can help you if you are having issues with stakeholder engagement or communication. The technique doesn’t have to replace an existing one; it could instead be used in conjunction with what you are doing now.

7. Consider the Risks of Using the Techniques

The BABOK® Guide has a great section at the end of each technique description that outlines usage considerations. Before proceeding with any new technique, consider the disadvantages and weigh the risks. Each technique has at least one disadvantage that imposes limitations and can create associated risk.

Selecting the most suitable technique for business analysis tasks involves a trade-off between advantages and disadvantages. For example, bench marking can identify opportunities for improvement, but it can be time-consuming, requires expertise in analysis, and does not typically result in innovative solutions. Business analysts can improve their understanding of the techniques by determining which disadvantages could become critical issues.

8. Use Decision Analysis

Select your techniques in the same way you would choose a vendor or assess a solution. You could create a decision analysis flowchart to select the techniques or score each technique using evaluation criteria.

Need More BA Techniques? RMC is Here to Help

In their search for suitable techniques, business analysts often find it difficult to obtain hard data on which techniques work best in which applications. As a result, many business analysts rely on what they know and what has been used in their organizations. But this means they may be missing out on techniques that can add value to projects and initiatives.

Having a basic knowledge of the techniques, as well as creating a personal categorization of the techniques, can help you objectively choose the most suitable technique for a specific project or initiative. Engaging stakeholders when you try out new techniques may provide additional unanticipated rewards as you grow your skill set as a business analyst.