Munagavalasa The Salesforce Business Analyst Handbook

Proven business analysis techniques and processes for a superior user experience and adoption
1. Auflage 2024
ISBN: 978-1-80181-057-9
Verlag: De Gruyter
Format: EPUB
Kopierschutz: 0 - No protection

E-Book, Englisch, 232 Seiten

Salesforce business analysis skills are in high demand, and there are scant resources to satisfy this demand. This practical guide for business analysts contains all the tools, techniques, and processes needed to create business value and improve user adoption.

The Salesforce Business Analyst Handbook begins with the most crucial element of any business analysis activity: identifying business requirements. You'll learn how to use tacit business analysis and Salesforce system analysis skills to rank and stack all requirements as well as get buy-in from stakeholders. Once you understand the requirements, you'll work on transforming them into working software via prototyping, mockups, and wireframing. But what good is a product if the customer cannot use it? To help you achieve that, this book will discuss various testing strategies and show you how to tailor testing scenarios that align with business requirements documents. Toward the end, you'll find out how to create easy-to-use training material for your customers and focus on post-production support - one of the most critical phases. Your customers will stay with you if you support them when they need it!

By the end of this Salesforce book, you'll be able to successfully navigate every phase of a project and confidently apply your new knowledge in your own Salesforce implementations.

Autoren/Hrsg.

Munagavalasa, Srini

Fachgebiete

• Mathematik | Informatik EDV | Informatik Business Application Unternehmenssoftware
• Mathematik | Informatik EDV | Informatik Programmierung | Softwareentwicklung Software Engineering

Inhaltsverzeichnis

Table of Contents - Identifying Requirements
- Elicitation and Document Requirements
- Prioritizing Requirements
- Process Flows - "As-is" versus "To-be"
- Business Requirements Document
- Solution Design and Functional Document
- Demonstrate Functionality Using Prototypes
- Exploring Conference Room Pilots
- Technical and Quality Testing
- Requirements Traceability Matrix
- User Acceptance Testing
- Communication and Knowledge Management
- End User Training
- Post Go-Live Support / User Forums

Leseproben

1

Identifying Requirements

In this chapter, we will discuss the role of a Business Analyst and different types of software requirements. Then, we will review some important factors that will help gain project sponsors’ confidence and trust. Finally, we will explore common sources to look out for that help us spot and identify business requirements. We will also touch upon, at a high level, some business analysis lingo that you should be aware of to be able to facilitate business analysis activities. Remember, we wish to identify requirements at a very high level. We will do a deep dive into understanding requirements in more detail and from different perspectives during the elicitation phase, which will be covered in the next chapter.

In this chapter, we will cover the following topics:

• The role of business analysis in identifying requirement sources
• Securing support from the project sponsor
• Common sources where you can identify business requirements
• Real-life scenarios with examples
• Practical tips for success

By the end of this chapter, you will have a good idea of where and how to find requirements that will help you with requirements gathering. You’ll also know what you should do to understand current processes and observe the inefficiencies, roadblocks, and opportunities surrounding them.

The role of business analysis in identifying requirement sources

Before we get into details of the business analysis role, let’s quickly review what some common terms mean, which will be helpful in our upcoming discussions:

• Business analysis: Business analysis is a practice that involves understanding the current capabilities and needs of the business users, identifying gaps in the current processes, and enabling desired future capabilities to derive efficiencies, competitive advantage, and business benefits.
• Business Analyst: A Business Analyst is someone who practices business analysis while utilizing various tools, techniques, and resources. The goal is to help businesses move from their current state to a desired future state by understanding business needs, pain points, opportunities and gaps in processes, and providing robust, efficient, and effective solutions that are simple and usable.
• Customer Relationship Management (CRM): CRM is the practice of helping customers manage sales, service, and marketing processes effectively and efficiently so that they can grow their business and provide excellent customer service.
• Salesforce: Salesforce is a cloud-based CRM technology platform that helps organizations serve their customers with CRM functionality.

With this basic understanding, let’s discuss business analysis in detail.

Business analysis work starts with planning – there is no one cookie-cutter approach that works for every project. Business Analysts need to know and understand the context and characteristics of the project to ensure that the planning activities are scoped accordingly. Prior planning and spending time on identifying the user requirement sources will lead to a better understanding of the scope of business analysis work, stakeholders’ expectations, and the amount of analysis work that needs to be done in subsequent phases of the project. We need to create a well-thought-out business analysis roadmap so that the analysis process is effective and successful.

As a Business Analyst, the first and foremost task to focus on is identifying business needs. Business needs are gaps between the current state of a business and its expected goals. Business needs analysis is also referred to as gap analysis – the current “as-is” state versus the desired “to-be” state. Needs are the basic drivers of change. By understanding needs, the Business Analyst can document requirements. This activity happens during the project planning or pre-project phase. As an analyst, you will use this data as a starting point for requirement gathering and elicitation or to create a business plan and provide findings for management decision-making.

Before you get into the requirements, you need to plan and identify where you can get the business needs and requirements. What are the good quality sources and where can you find them? These can be from stakeholders, documents, existing processes, observations, interviews, and so on.

I have worked on multiple global projects where the projects started at different stages. Most of the time, the majority of the functions that are needed are on existing systems – enhancing or adding more capabilities. I got the opportunity to work on a few projects where, as a Business Analyst, it was me who would guide the business, identify requirements, tools, and systems, and provide a system that the business can benefit from and value. This is very stressful as well as rewarding when you have to guide stakeholders and help them understand their requirements and needs. I will touch upon various examples along the way that may benefit you.

There are three possible business requirement scenarios that I would like to cover:

• The system is already in use and business users would like to request enhancements. Here, you must add additional features to existing functionality. This can be your minor enhancement release or a production support item such as a defect or maintenance item.
• The system is already in use and business users would like new functionality. This can be a brand-new functionality and addressed via a project.
• You must add new capabilities to address usability and adoption issues. This can be a complex requirement where multiple stakeholders are involved.

Based on these scenarios, let’s explore our analysis process. Examples for each of these scenarios have been provided with screenshots in the section.

Project teams and IT teams most often blame the business users, stating that they do not know what they want. That is the very reason why we have Project Managers, Business Analysts, IT teams, QA teams, training teams, and so on. Business users do not need to know what they want. It is up to the project team, especially the Business Analyst, to identify the right stakeholders, pull ideas out of users, and get agreement from everyone.

Stakeholders, even though they know the problems in most cases, do not know how to articulate their needs. On the other hand, few users can articulate, anticipate, and lay out their needs, wants, and desires, and pretty much want everything their way. You need to be cognizant of both and watchful for the latter.

In reality, only a few requirements are documented in some form. Most of them reside in the heads of stakeholders, end users, and process flows that are yet to be understood and developed.

For a project to be successful, understanding and documenting requirements accurately is one of the key success factors. Failure to understand and capture requirements accurately will lead to project delays, false expectations, broken promises, blame games, and stressful situations. So, let’s focus on learning, understanding, discovering, and getting the right requirements by focusing on extracting the ideas, issues wants, and needs of the users.

Note

I will be covering real-life practical scenarios – successes as well as failures and lessons learned. We will use many existing Business Analyst tools and techniques. As needed, I will explain them at a very high level. I will not be providing definitions or procedures; instead, I will explain the scenarios with practical examples based on my experience.

Let’s delve into what it takes to identify business needs and wants. Our ultimate end goal here is to identify a set of requirements that are consistent, non-redundant, and complete. In this chapter, we shall concentrate only on the extent of learning problems and/or opportunities to sufficiently understand the situation and not perform a complete requirement analysis, which shall be explained in future chapters. Ensure that you’re not subjective and judgmental; you are here to understand business needs, not design solutions. As Business Analysts, we must make every effort to understand business needs and wants, how they align with the vision/strategy, and how this enables us to achieve our strategic end goal.

As Business Analysts, we need to get as much information as possible by exploring all possible avenues and areas. You need to know what information you must get and where to find that information. For that, we need to ask six (5Ws + 1H – Who, What, When, Where, Why, and How) questions iteratively to completely understand the full scope and intent of the business needs. When asking these questions, you should know the rationale for every question and be able to explain to stakeholders why that question is relevant.

By understanding different types of requirements, you will be able to manage the requirements process effectively at all project stages. Remind yourself that we are here to gather information to identify the real problem or opportunity and not to provide our opinions or solutions.

Types of requirements

There are four main types of requirements, as listed here:

• Business requirements: An example of this is if you are implementing a new system or...

Über Autor(innen)

Munagavalasa Srini :

Srini Munagavalasa has more than 20 years of global IT experience in Salesforce CRM and PRM, SAP CRM, and HR. He has a passion for learning about new and emerging technologies and products and prototyping and implementing solutions that result in customer satisfaction and business benefits. He has authored 10+ articles on CRM, HR, and project management with Wellesley Information Services (WIS). He has also presented at Salesforce Dreamforce and SAP Sapphire/ASUG. He is currently working as a VP of Salesforce COE at MUFG Americas. He has a bachelor's degree in metallurgical engineering and holds a post-graduate diploma in operations management. He has worked with renowned companies such as CA Tech, IBM, The Walt Disney Company, and PwC.