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[et_pb_section fb_built=”1″ _builder_version=”4.9.4″ _module_preset=”default” da_disable_devices=”off|off|off” da_is_popup=”off” da_exit_intent=”off” da_has_close=”on” da_alt_close=”off” da_dark_close=”off” da_not_modal=”on” da_is_singular=”off” da_with_loader=”off” da_has_shadow=”on”][et_pb_row _builder_version=”4.9.4″ _module_preset=”default”][et_pb_column type=”4_4″ _builder_version=”4.9.4″ _module_preset=”default”][et_pb_text _builder_version=”4.9.4″ _module_preset=”default”]

When you start a project, the first question needs to be about scope.  Analysis helps facilitate discussions, using visual analysis techniques, to clarify the scope of the product or solution. Because scope management is critical to project performance, you want to have proven ways in which analysis prevents scope creep.

There are many tools and techniques you can use to help define, document, and facilitate scope definition to help stakeholders envision what it is they want.  At the beginning, or when you are first assigned the project, start with defining the scope. If the scope has already been defined, confirm it.

Three Techniques to Prevent Scope Creep

  1. Context Diagram
  2. Use Case Diagram
  3. Product Backlog List
  4. The Value of Scope Analysis Technique

Scope Creep Top Analysis Tools

Here are three popular business analysis techniques for getting your stakeholders to agree on scope and stick to it!

1. Context Diagram

The context diagram is a well-established technique used to develop a clear understanding of a solution or product scope. The context diagram and its associated analysis provide a very structured approach to asking questions that help stakeholders determine the boundaries of their request.

The context diagram shows the solution or product as a circle in the center of the diagram. It does not show any detail inside the solution, because these details are not yet known. Instead, it shows the outside forces which will be important for the solution.  The idea is that if you understand everything that is outside the scope but has an impact on the scope, by definition, you have defined the scope.

Diagram 1 is an example of context diagram for a new product; (possibly a mobile app) to help home buyers complete many tasks to purchase a home. The goal of this app is to help the buyer navigate the work by providing a checklist of items to be done. The circle in the center of the diagram is the mobile app, our solution.  The boxes represent the parties, organizations, or systems with which the new app will interact, outside the scope. The arrows represent data flows showing information that will flow to and from the app. For example, the app will send information to the Buying Agent (e.g., the offer) and the Buying Agent will send information to the app (e.g., response to the offer). As you can see, this is a very simple view of the product scope which quickly reveals important information about the complexity and boundaries of the product.

Diagram 1: Context Diagram

[/et_pb_text][et_pb_image src=”https://rmcls.com/wp-content/uploads/2021/08/home_buyer_purchase_app.png” title_text=”home_buyer_purchase_app” _builder_version=”4.9.4″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.9.4″ _module_preset=”default”]

2. Use Case Diagram

A Case Diagram is a software development technique. It provides a high-level view of the scope of a solution. This approach helps you have conversations with your stakeholders about the roles of people involved in the solution and the goals. In diagram 2, the rectangle in the center represents your solution boundary /scope. The stick people are actors or parties that have a connection to the solution. The oval is the very high-level descriptions (use cases) of what the solution features and are considered goals of the actor. The lines are called association lines and they show how the actors are involved. Diagram 2: Use Case Diagram[/et_pb_text][et_pb_image src=”https://rmcls.com/learn/wp-content/uploads/2017/10/use_case_diagram.png” _builder_version=”4.9.4″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.9.4″ _module_preset=”default”]

3. Product Backlog List

The product backlog is like a wish list for stakeholders. Its’ purpose is to ask stakeholders what features and functionality they want. From the product backlog list, you can analyze and prioritization the work to determine what is in and out of scope (see diagram 3). You might consider a phased approach, releasing the top ideas in the first phase and the next priorities in a second release. It can be difficult to get stakeholders to define what are the most important things they need. It also requires a clear understand of the business value and estimated cost of each requirement.  Continue to focus on facilitating good conversations with stakeholders to define the scope. Diagram 3: Product Backlog List[/et_pb_text][et_pb_image src=”https://rmcls.com/wp-content/uploads/2021/08/backlog.png” title_text=”backlog” _builder_version=”4.9.4″ _module_preset=”default”][/et_pb_image][et_pb_text _builder_version=”4.9.4″ _module_preset=”default”]

The Value of Scope Analysis Techniques

There are several advantages to using business analysis techniques for scoping:
  1. Anyone can use them: project managers, systems analysts, or developers.
  2. Helps formulate questions for stakeholders.
  3. Facilitates discussion to identify roles and role changes
  4. Enables collaboration with stakeholders and helps ensure that everyone agrees to the scope of the solution.
  5. Shows the high-level functions included in scope.
  6. Helps get scope to a more manageable size and deliver more quickly.

RMC’s Got You Covered

RMC has several skill building courses to help you learn more about scope. There is our Managing Small Projects eLearning class where you can learn how to scope a small project. Our Business Analysis Fundamentals eLearning class covers more about these three techniques and others. Defining and Managing Project Requirements course offers high level of scoping.  Contact us for more details on our instructor-led class schedule. Finally, you can also listen to the recorded webinar Three Proven Analysis Tools to Prevent Scope Creep and earn 1 technical PDU. Sources: https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
Posted on by

Strategic Planning: Project Managers & Business Analysts

Project manager working on strategic plan with team[et_pb_section fb_built=”1″ _builder_version=”3.22″ da_is_popup=”off” da_exit_intent=”off” da_has_close=”on” da_alt_close=”off” da_dark_close=”off” da_not_modal=”on” da_is_singular=”off” da_with_loader=”off” da_has_shadow=”on” da_disable_devices=”off|off|off”][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”4.9.4″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” hover_enabled=”0″ sticky_enabled=”0″]

Project managers (PMs) and business analysts (BAs) should be actively involved in developing strategic plans. The knowledge and skills of these professionals align perfectly with the strategic planning process. Also, PMs and BAs have the necessary communication skills required to explain the plan to employees who need to carry it out. PMs and BAs are engaged with people in all areas of the organization and can effectively carry the message to everyone. Most strategic planning shares a common set of deliverables. 

Involve PMs and BAs in Strategic Planning

  1. What is Strategic Planning?
  2. Why Strategic Plans Fall Short?
  3. Why Involve PMs and BAs in Strategic Planning?

What is Strategic Planning?

The purpose of strategic planning is to set overall goals for your business and to develop a plan to achieve them. A strategic plan helps organizations connect their mission and vision to a plan to achieve the goals.

  • Mission Statement – defines your business’ purpose, its objectives, and the approach to reach those objectives.
  • Vision Statement – describes the future position of the company
  • Plan – outlines how to achieve the organization’s business and financial goals

Traditionally executives have developed strategic plans. They may spend a few hours, days or even months coming up with mission and vision statements, goals and objectives, and defining their imperatives or direction statements. Once the plan is developed, a communication goes out to the entire organization for execution and follow up. In some organizations the plan is posted on a wall in the office or an internal digital site for reference. However, a strategic plan can fail to gain traction for several reasons.

Why Strategic Plans Fall Short

There are several reasons why these strategic plans often do not result in any significant change for organizations.

  1. The plan is not very good.

When executives exclusively provide ideas, the plans that develop from them can be unrealistic, overly optimistic, or aggressive. They are often documented using “consultant-speak” – lots of big, important sounding words which have no clear meaning to most employees. Key imperatives are often pithy, feel good statements (e.g. “Our customers are number one!”) which do not provide any usable insight.

  1. The plan is not well communicated.

If a plan is communicated once, it is unlikely that any employees will really grasp it or understand how it should impact their work.A one-page strategy graphic is a good visual starting point recommended by many consultants, but if the details are not communicated, it is difficult for anyone to execute against them.

  1. The plan is not linked to day-to-day work.

Lack of Alignment to People’s Work.Employees don’t know how their day-to-day initiatives, projects and everyday work assignments to support the strategic plan. They usually keep doing the same activities, focusing only on their manager’s priorities, which may not be the same as the organizations long term goals.

Why Involve PMs and BAs in Strategic Planning?

All three problems can be decreased by involving project managers and business analysts in the strategic planning process.

  1. The plan is not very good.

PMs and BAs know their organizations very well. They work with people in all departments and at all levels of the organization. They know the culture and the ability of the firm to absorb change. They know the obstacles which will slow progress.These professionals also have the skills needed to analyze opportunities, threats, industry changes; balancing stakeholder and customer needs, and develop plans which will serve the long-term interests of the organization. The more people involved with developing the plan, the better the plan and the better the commitment to the plan.

  1. The plan is not well communicated.

Communications are the hallmark skills of PMs and BAs.PMs give direction well, explaining why tasks are needed, how they should be sequenced and how they impact other tasks. BAs listen to stakeholder concerns, analyze potential impacts and present solutions clearly. When an employee asks “Why are we doing this?” – a PM or BA can always answer the question.

  1. The plan is not linked to day-to-day work.

Employees need to know – EVERY DAY – “How is my work furthering the mission of the organization?” Not only does this knowledge advance the plan, it is also the key to driving employee engagement and motivation.Ask any HR manager and they will tell you that employees want to understand how their work contributes to the goals of the organization. They want to understand the link from strategy to their specific tasks, and they want to be rewarded for supporting the strategy. PMs and BAs can make the link from strategy to execution by clearly understanding the strategic plan and knowing how it will be advanced by their projects. They help project team members see the value of their work and see the results at a detailed and high level.

Build Your Strategic Planning Skills

Strategic thinking and planning skills are increasingly in-demand for project managers and business analysts. In fact, Strategic and Business Management is one of the three legs of PMI’s Talent Triangle, making these skills essential for maintaining your PMP and other certifications.

RMC’s Strategic and Business Management: Best Practices eLearning Course is designed to not only teach you the discipline of strategic management, but how to apply it in your organization. You’ll gain a set of added competencies that provide greater awareness and recognition for your role within the organization.

Sources:

https://www.indeed.com/hire/c/info/what-is-strategic-planning-a-definition

https://www.nibusinessinfo.co.uk/content/purpose-strategic-planning

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
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.