The Salesforce Business Analyst Handbook E-Book

Srini Munagavalasa

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 357

Veröffentlichungsjahr: 2022

Beschreibung

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.

Leseprobe

The Salesforce Business Analyst Handbook

Proven business analysis techniques and processes for a superior user experience and adoption

Srini Munagavalasa

BIRMINGHAM—MUMBAI

The Salesforce Business Analyst Handbook

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Alok Dhuri

Publishing Product Manager: Akshay Dani

Senior Editor: Rohit Singh

Technical Editor: Jubit Pincy

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Sejal Dsilva

Production Designer: Shyam Sundar Korumilli

Business Development Executive: Uzma Sheerin

Marketing Coordinators: Deepak Kumar and Rayyan Khan

First published: October 2022

Production reference: 1211022

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80181-342-6

www.packt.com

Contributors

About the author

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 resulting 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 papers at Salesforce Dreamforce and SAP Sapphire/ASUG. He is currently working as a VP at 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.

I would like to thank my wife, Sunanda, and my children, Sravan and Sai, for all their support and encouragement; my Packt team, for their guidance and keeping me on track; and my reviewers, for providing valuable feedback.

Finally, thanks to my family members, friends, and all my colleagues at work, who helped me learn and grow from my experiences.

About the reviewers

Jarod McCarty has 15 years of experience in the manufacturing and construction industry, 5 years of which have involved a Salesforce business analyst role.

Jarod lives with his wife and four kids in Fort Worth, TX, where he enjoys spending time with his family, spending time outdoors, and, of course, learning more about tech and Salesforce.

Andrew Nixon is a certified Salesforce application architect with over 20 years of experience in software delivery. He has a deep appreciation of all software life cycle management aspects, having progressed through support, business analyst, and program management roles delivering tier 1 ERPs and CRMs for global organizations.

In 2016, he took the decision to focus solely on Salesforce and now heads a Salesforce Centre of Excellence managing an enterprise-wide Salesforce instance.

Andrew is passionate about learning, sharing knowledge, mentoring, and upskilling his teams. In his spare time, he also volunteers as a Salesforce administrator for non-profit organizations.

Table of Contents

Preface

Part 1: Planning and Analysis – BRD/Prioritized Product Backlog

1

Identifying Requirements

The role of business analysis in identifying requirement sources

Types of requirements

Securing support from the project sponsor

Common sources where you can identify business requirements

Document analysis

Identify key stakeholders

Navigate the organization

Current system usage

Identify the key end user

Needs decomposition

Get a system walkthrough

Active participation

Existing systems

Note-taking

Assumptions

Meeting minutes

Real-life scenarios with examples

Scenario 1

Scenario 2

Scenario 3

Practical tips for success

Summary

Questions

Further reading

2

Elicitation and Document Requirements

Elicitation planning

Elicitation tasks

Requirement elicitation techniques

Observation

Brainstorming

Surveys

Interviews / focus groups

Conference room pilots / requirements workshops

Prototyping

Process models

User stories

Requirement documentation

The art of elicitation

Practical tips for success

Summary

Questions

Further reading

3

Prioritizing Requirements

The importance of requirement prioritization

Reviewing prioritization techniques

MoSCoW analysis

Story mapping

Dependency map between requirements

Managing prioritization meetings

Practical tips for success

Simple CRM requirement prioritization and roadmap scenario

Summary

Questions

Further reading

4

Process Flows – “As-Is” versus “To-Be”

Reviewing the process flow

Process flow types

Understanding and capturing the current state “as-is”

Current state swim lane process flow diagram

Proven techniques to capture the current state

Identifying gaps and improvement/automation opportunities

Developing the future state – “to-be”

Future state swim lane process flow diagram

Benefits of creating process flows

Summary

Questions

Further reading

5

Business Requirements Document

Reviewing the need for business requirements documentation

Understanding user requirements and use cases

Exploring functional and non-functional requirements

Functional requirements

Non-functional requirements

Learning what level of detail is sufficient

Requirements matrix (prioritized product backlog)

Explaining a typical business requirement document and its key attributes

Practical tips for success

Summary

Questions

Further reading

Part 2: Design, Development, and Testing – Iterative Cycles with Prototypes and Conference Room Pilots

6

Solution Design and Functional Document

Understanding solution design

Identifying functional requirements

Identifying non-functional requirements

Reviewing data conversion requirements

Understanding the functional requirements matrix

Developing the function document

Practical tips for success

Summary

Questions

Further reading

7

Demonstrate Functionality Using Prototypes

The need for prototyping and its categories

Categories of prototype

When to do prototyping

Prototype stages

What and how do you prototype?

Tools to document prototyping

The benefits of prototyping

Practical tips for success

Summary

Questions

Further reading

8

Exploring Conference Room Pilots

Understanding what CRPs are

Exploring the timing and participants of CRPs

Scope CRP

Design CRP

Build CRP

Test CRP

Facilitating CRPs

Managing scope creep during CRPs

Reviewing the benefits of CRPs

Practical tips for success

Summary

Questions

Further reading

9

Technical and Quality Testing

Planning testing activities

Testing strategy

Testing levels

Testing methods

Testing schedule

Testing approach

Testing phases

Types of testing

Sample test script/case fields

Benefits of testing

Practical tips for success

Summary

Questions

Further reading

10

Requirements Traceability Matrix

Understanding the importance of an RTM

Learning what to capture in an RTM

Exploring types of traceability

Reviewing an RTM template sample

Benefits of an RTM

Practical tips for success

Summary

Questions

Further reading

Part 3: End User Testing, Communication, Training, and Support

11

User Acceptance Testing

Identifying the right set of UAT users

Learning how to help UAT users test effectively

Getting feedback on usability

Exploring the need for UAT

Reviewing the benefits of UAT

Practical tips for success

Summary

Questions

Further reading

12

Communication and Knowledge Management

End user communication

Different knowledge management types

Explicit knowledge

Tacit knowledge

Knowledge artifacts accessibility

Benefits of communication and knowledge management

Practical tips for success

Summary

Questions

13

End User Training

Planning for training

Preparing for training

Setting up the training environment

Reviewing types of training materials

Understanding the importance of in-person or live training

Facilitating a training session

Benefits of end user training

Practical tips for success

Summary

Questions

14

Post Go-Live Support / User Forums

Super care

Production support

User forums

Topics to cover during the user forum

Delivery cadence

Benefits of production support

Practical tips for success

Summary

Questions

Assessments

Chapter 1 - Identifying Requirements

Chapter 2 - Elicitation and Document Requirements

Chapter 3 - Prioritizing Requirements

Chapter 4 - Process Flows – “As-Is” versus “To-Be”

Chapter 5 - Business Requirements Document

Chapter 6 - Solution Design and Functional Document

Chapter 7 - Demonstrate Functionality Using Prototypes

Chapter 8 - Exploring Conference Room Pilots

Chapter 9 - Technical and Quality Testing

Chapter 10 - Requirements Traceability Matrix

Chapter 11 - User Acceptance Testing

Chapter 12 - Communication and Knowledge Management

Chapter 13 - End User Training

Chapter 14 - Post Go-Live Support / User Forums

Index

Other Books You May Enjoy

Preface

I have covered business analysis activities for every phase of many projects in my 20+ years of experience working on many successful global implementations. I have seen many project phases being negatively impacted by a lack of proper business analysis activities. It starts with understanding what your business users’ needs are, and they are not always in black and white. This book addresses what your users’ true needs are and how you, as a business analyst, can untangle and read their minds to understand the true essence of their needs and the benefits they provide to your organization. You’ll get to learn various methods, tools, and techniques to help you with the analysis process. The most critical and significant activity of any project is to be able to understand what the business needs are, and if we cannot do this, it does not matter what kind of hi-fi solution your project team provides. Your project will be another artifact sitting on the shelf, dusty.

This book will help you understand various techniques to document value-added business requirements; translate these requirements into viable and acceptable solutions; verify and validate the developed and tested solutions; help end users understand how to use the new features and functions; and be a trusted advisor in supporting your end users on their journey to achieve amazing user adoption.

For projects to be successful, you do not need magic. All you need is for your team to understand business analysis processes, tools, and techniques. The chapters in this book will help guide you through business analysis activities in all project phases.

Who this book is for

This book is for intermediate- to senior-level business analysts with a basic understanding of Salesforce CRM software or any CRM technology who want to learn proven business analysis techniques to set their business up for success.

What this book covers

Chapter 1, Identifying Requirements, discusses the role of a business analyst and different types of software requirements. You will learn how to explore common sources to look for things that help spot and identify business requirements.

Chapter 2, Elicitation and Document Requirements, discusses various methods to draw out the business needs and wants from various sources. This enables you to extract sufficient information to understand users’ expressed and unexpressed business needs and formalize and document them as detailed requirements.

Chapter 3, Prioritizing Requirements, covers the process and techniques of requirement prioritization, helping you understand the dependencies between various requirements and prioritize dependencies in the right order without creating gaps in the requirements flow.

Chapter 4, Process Flows – “As-is” versus “To-be”, helps you understand the importance of business process flows. We will discuss how to develop and understand current and future process flows. We will see how we can identify any gaps that can be addressed and opportunities to automate the functionality.

Chapter 5, Business Requirements Document, reviews different types of requirements and the level of detail to be captured for each of these types of requirements for better understanding by all team members. We will discuss and understand the importance of documenting key attributes of a business requirement document.

Chapter 6, Solution Design and Functional Document, covers different ways to identify functional and non-functional requirements using process flows. We will cover aspects that can make the designed solution flexible, maintainable, and scalable. We will also cover transitional requirements and the critical part they play in making your projects successful.

Chapter 7, Demonstrate Functionality Using Prototypes, covers ways to demonstrate functionality by translating functional specifications into a visual working model using different techniques and tools. You will learn ways to help team members see a visual of the requirement and provide an opportunity to ideate, collaborate, and obtain feedback iteratively.

Chapter 8, Exploring Conference Room Pilots, discusses ways to collaborate and showcase prototypes to a wider audience. We will see how conference room pilots can help us progress from individual requirements to proposed design solutions in the right direction. We will also discuss how various team members can benefit and add value to other project phases.

Chapter 9, Technical and Quality Testing, reviews and shows how testing helps us with exploring the system to verify, validate, and confirm that the system functionality developed works as intended. We will explore and see what tools, traits, and skills make effective testing. We will explore various testing approaches, testing phases, and testing types.

Chapter 10, Requirements Traceability Matrix, helps you understand the importance of the relationships between requirements and various project artifacts and how they help us establish traceability. We will explore how this helps us in identifying and in bridging any elusive gaps. We will also see how to link requirements to project deliverables, ensuring that we have complete test coverage.

Chapter 11, User Acceptance Testing, shows how user acceptance plays a crucial role in a successful Go-Live. We will discuss how to work with business users and help them test real-life business scenarios and get feedback on usability. We will also discuss how to plan and execute user acceptance testing in a structured way that can reduce post-production issues and save the organization’s time and resources.

Chapter 12, Communication and Knowledge Management, discusses aspects of communication and knowledge management, especially focused on end users. We will explore various options to make sure we provide timely and appropriate communication. You will learn how to tailor knowledge management artifacts related to the usage of the functions of the new systems.

Chapter 13, End User Training, discusses the important role end user training plays in the successful adoption of the system functionality by end users. We will see how to train and prepare users so that they can understand the core system functionality, integrations, and business process flows.

Chapter 14, Post-Go-Live Support / User Forums, covers details on why post-go-live support is so critical for users to adjust to the system’s new functionality. We will learn to plan and facilitate user forums with end users that help establish continued collaboration. We will see what makes you a trusted advisor to your users and help continuously improve the system and its usage.

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/WeXkm.

Conventions used

There are a number of text conventions used throughout this book.

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read The Salesforce Business Analyst Handbook, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere? Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application. 

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781801813426

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Planning and Analysis – BRD/Prioritized Product Backlog

In this part, you will learn about planning and analysis activities, starting with ways to identify the right sources of requirements and use elicitation techniques to understand business needs by engaging the right stakeholders. You will learn how to utilize tacit business analysis and Salesforce system analysis skills to rank and stack all requirements, and communicate and get buy-in from all stakeholders. Finally, you will document all your prioritized requirements in a business requirement document artifact. You will also learn how to create a roadmap to deliver a set of high-level requirements.

We will address some of the key challenges faced during this phase:

Not being able to identify the right requirements, resulting in delivering unnecessary nice-to-have features without adding any business valueDue to a lack of requirements or product backlog prioritization, projects not delivering the right solutions as requirements are accepted on a first-come, first-served basis, or the loudest voice gets prioritizedGoing all in rather than defining a clear Salesforce roadmapNot assessing the dependencies and integration impacts on concurrent Salesforce projectsNo clear understanding of what the current state process looks like or what the future proposed state process should be

The following chapters will be covered under this part:

Chapter 1, Identifying RequirementsChapter 2, Elicitation and Document RequirementsChapter 3, Prioritizing RequirementsChapter 4, Process Flows – “As-Is” versus “To-Be”Chapter 5, Business Requirements Document

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 sourcesSecuring support from the project sponsorCommon sources where you can identify business requirementsReal-life scenarios with examplesPractical 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 Real-life scenarios with examples 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 functionality. These requirements are the most complex to understand, as there are too many unknowns. These requirements describe the high-level functionality that the business needs.Stakeholder requirements: Also called user requirements, these are features and functions that the users need and specify how they interact with the system. Getting to know the stakeholders’ needs and wants is critical because, often, they may not be able to articulate them clearly. This is very critical as stakeholder requirements are later translated into system requirements. Any flaws here get amplified at later stages and result in rework.System requirements: These requirements describe the characteristics of the solution. There are two types of system requirements:Functional: Describes a specific set of capabilitiesNon-functional: Describes the characteristicsTransition requirements: These are transient requirements and are needed for a short period. Make sure that you discuss and get details around transition requirements. They are essential and critical to project success.

The most notable requirement is data migration. In the process of ETL, data may be rendered useless if data migration is not done diligently. I have seen many instances in projects, including the one I worked on a few years ago, where, after converting HR data, the team was unable to run the payroll on time. You know what’s going to happen if employees are not paid on time.

Knowing and understanding different requirement types and establishing goals and timelines for identifying requirements will help pave the foundation for the next step of our business analysis. Here, we are trying to understand the current state and the desired future state. Analyzing business needs and wants will help us provide the right solution or address the right problem during our design phase.

In the past 15 years, I have worked on multiple Salesforce implementations: Sales Cloud, Service Cloud, and Partner Relationship Management. I employed more than one method to get to know and understand business needs. It all depends on your implementation methodology, people, culture, IT team maturity, and so on, and you need to tailor and use a combination of the methods discussed in the Common sources where you can identify business requirements section, later in this chapter.

Securing support from the project sponsor

Securing support from a project sponsor is another important factor for any project to succeed. The business analysis process and the Business Analyst play a vital role in securing confidence and trust with the project sponsors. Business analysis involves defining the requirements, designing the solution, communicating, validating the solution, and training activities so that they are well positioned to access and identify project impacts. They can act as the eyes and ears of the project sponsor. The project sponsor often depends on project managers and Business Analysts for all key decision-making. Just like gaining confidence and trust from subject matter experts (SMEs), project team members, and super users, we have to gain the project sponsor’s confidence and trust too. One of the most important activities is to keep the sponsor in the loop at all times.

As a Business Analyst, you can gain project sponsors’ trust and confidence by assisting them with information and the decision-making process. This is possible through good planning and communication. Let’s outline what you should be doing to help the sponsor:

Present information accurately and concisely at the appropriate level.Issues are bound to arise, so be prepared with the information and facts to facilitate smooth decision-making.At each stage of the project, provide a summary of the business analysis work while highlighting achievements and any risks.As a key resource, be prepared and provide recommendations with pros and cons.Be truthful, transparent, and courageous to deliver unpleasant information. Be able to say “No.”

Gaining confidence and trust will help Business Analysts navigate business analysis work smoothly, efficiently, and productively. This will help the project team and you, as a Business Analyst, in areas such as the following:

Resources availability for SMEs and other project resourcesTimely decision makingProvide direction – define the scope, prioritize requirements, and so onInfluence escalations, resolve conflicts, and motivate

Common sources where you can identify business requirements

Now that we understand how to identify requirements and why it is important for a business, let’s review the various sources where we can gather these requirements.

Document analysis

Document analysis involves getting your hands on any relevant documentation: scope documents, project initiation requests, business plans, knowledge transfer artifacts, manuals, presentations, minutes of past meetings, user guides, and so on.

Identify key stakeholders

Who shall be impacted by the change directly or indirectly? You can start with a business sponsor and a program manager. Find out the scope and range of the project implementation in terms of various Business Units (BUs).

Navigate the organization

Get to know SMEs, data captains, planning team members who focus on analytics and management dashboards, and a few enthusiastic end users.

Current system usage

Find out how current systems are used to perform their job and how they are integrated into other systems in the company.

This is a great opportunity for you to observe and find opportunities to enhance and simplify the processes and save time and frustration.

An example would be users struggling to access the system due to login issues (incorrect password or system lockout due to too many incorrect password attempts). This can be easily addressed via enabling Single Sign-On (SSO), which is available out of the box for almost all cloud applications. With SSO, users need to click on one bookmarked URL to access an application.

Identify the key end user

Users who are passionate about the change and who are direct beneficiaries understand existing work practices and existing unaddressed problems. I listed them separately as they are not identified as part of the project stakeholders. They can be your level 1 support or call center representative.

Plan brainstorming sessions by facilitating the conversation and allowing key participants to openly debate and speak out. Take notes and make sure that you let the conversation flow freely; your job is to facilitate the conversation and ask questions as appropriate.

Needs decomposition

Try to get as much information from whatever source possible via decomposition, breaking down needs into smaller needs until they can no longer be decomposed. This way, we are breaking down a complex requirement into multiple small and simplified individual components of the needs.

Get a system walkthrough

Understand firsthand how end users normally use the system regularly. Be an observer and let the user navigate and walk through their process in the system end to end. This user journey helps you understand and identify missed elements and any usability requirements.

Active participation

Listen attentively and actively, acknowledge, ask questions, and rephrase what you heard and understood. This is to ensure an accurate understanding of what has been communicated is agreed by both ends. Also, avoid judging what you heard so that information flows freely. Focus on business needs and do not get into designing the solution.

Most often, the stakeholder assumes that the Business Analyst already knows or is aware of the business needs and provides high-level information only. Business Analysts need to make sure that information is provided in enough detail.

Let the participants debate and let them vent their frustration. You get facts and truth from this kind of conversation and are able to grasp stakeholders’ perspectives of business needs.

Different stakeholders may have different perspectives; it is your job to explore them and resolve any conflicts.

Make sure you keep the discussion aligned to the agenda and manage it so that it doesn’t get out of control.

Existing systems

Find ways to get access to current systems and be able to run some key reports and dashboards. This will help you identify and get reports and stats on end users who use the system.

During one of my first implementations, I was able to run a few reports and find out who the power users were. I ran stats and saw why usage dropped from quarter to quarter (or over a period). By doing this, along with the data and facts I had gathered, I was well prepared to ask the users the right questions.

Note-taking

Take notes, prepare minutes, and share them with the participants on the same day and solicit feedback. Clarify any open queries one on one with specific participants.

When taking notes, make sure that you tag the requirement type as business, stakeholder, solution, or transition. By understanding the requirement type, you can fine-tune and facilitate the conversation effectively and efficiently.

Assumptions

Avoid and eliminate all assumptions around requirements. Business needs must be verified and assumptions, if any, need to be confirmed and documented.

Meeting minutes

Prepare and share a list of simple, clear, consistent, and complete high-level requirements. This will help you provide the steps that must be taken.

Now that we have learned where and how we can identify and gather business requirements, let’s learn how to implement them with some real-world examples. These will be covered in the next section.

Real-life scenarios with examples

Business needs vary from very simple to extremely complex. With the help of three different practical scenarios, I will explain the various needs and discuss how they are addressed and implemented. A strong understanding of business needs will help us in the elicitation phase.

Scenario 1

This is a simple scenario where users know what they need. It could be an existing pain point where I am looking for improvements. This case is true when users are already using the system and they can easily point out the gaps, be it defects or enhancements to the application.

For example, in Salesforce, duplicate leads, accounts, and contact records cause multiple issues down the line. These types of requirements are very straightforward. As a Salesforce-savvy Business Analyst, I can provide a quick solution. Here, I could suggest that users use the available duplicate management functionality.

By understanding the business needs, we can fulfill this requirement quickly by using existing out-of-the-box features from Salesforce. We will be able to find a quick solution for the majority of simple requirements. The key is to understand the business needs.

This is an example where elicitation is straightforward as business needs can be articulated easily and clearly.

Note

You may have to do a one-time cleanup of existing data to implement this solution.

Duplicate management functionality on the contact record

Here, we shall implement a rule where the Salesforce system will prevent users from creating duplicate contacts if the last name and email combination match.

A duplicate rule with matching criteria can be quickly implemented. Whenever any users try to create a duplicate contact, the system should prevent the user from creating one. The following screenshot shows a duplication rule being created:

Figure 1.1 – Creating a duplicate rule

In the following screenshot, I tried to create another contact with the same last name and email address. By implementing a simple duplicate rule, the system should prevent duplicate contact records:

Figure 1.2 – Salesforce system preventing users from creating a duplicate contact

You can view the duplicate as shown. Here, users will be able to make any updates as needed to the existing contact record:

Figure 1.3 – Option to view the existing duplicate contact record

You can also propose a more robust solution using AppExchange packages such as Demand Tool, which is an excellent tool for keeping your data clean and relevant. This is a managed package and there is a subscription fee per user. There are many paid and free tools on AppExchange. Do your research and try them in a sandbox before deciding to use them in your production environment.

Scenario 2

Users want field attributes defaulted by the system so that they can avoid re-keying the same data again for a specific BU.

For example, the billing address that’s available on the account record shall default when creating contact records for specific country users.

To illustrate this, we will look at another simple example where users can update their billing address with a company billing address. By automating this, the data quality stays accurate, current, and relevant. In Salesforce, this can be achieved via Process Builder. You can do the same with Flow Builder too. Process Builder will replace Flow Builder going forward, so it is advisable to start flows for automation:

Figure 1.4 – Using Process Builder to automate address updates on the contact record

Let’s look at another example. In Salesforce, the Sales team would like to see certain fields from the User record and Account record defaulted on the Opportunity record page. This requirement requires some level of analysis.

To simplify this, let’s look at a simplified requirement. A specific BU user would like to default certain field attributes from the User record (such as Region, Country, Division, and Department) and Account record (such as Account Owner, Industry, Account Type, and Rating). The rationale for this requirement is to have information available on the same Opportunity record and also be able to create list views from the Opportunities tab. To simplify further, let’s assume you, as a Business Analyst, socialized this with other BU stakeholders and got confirmation that they would like to have the same functionality extended to all.

You can have multiple solutions in Salesforce. Here, you can go with flows, but the simplest and easiest solution is to create a formula field. In our case, this is the preferred solution as users need data with view access; any updates that are made to user or account attributes are immediately reflected on the Opportunityrecord page.

This example helps you elicit unexpressed business needs. By observing or analyzing the ways to improve data quality, you, as a Business Analyst, shall be able to suggest the needs to business users and implement the same. Implementing these unexpressed needs helps in maintaining quality data and also reduces the time it will take the user to create data.

Scenario 3

This scenario is more complex than the others. These are instances where, in one of my previous projects when we did Partner Relationship Management (PRM) in Salesforce, the business users needed systems and functions but they did not exactly know how to explain or articulate the requirement. At a high level, the requirement was to have the PRM system migrated from an in-house custom build system to a sales cloud for partner with Account, Contact, Opportunity, Case, Campaign, Quote, and Lead Management, plus Partner Locator, Partner Onboarding, and User Onboarding. This was a hugely complex project that was delivered successfully over 3 years incrementally using agile methodology.

As an example, let me explain a relatively simple scenario. We have low adoption due to duplicate accounts and contacts in the system. Before they approached our project team, data stewards from the planning team tried multiple times to clean the data manually. But within a few months, data quality suffered again. Business users want these recurring dupe issues to be fixed as soon as possible as users may stop using the system.

After analyzing and researching internally and externally, we can identify the right product for our business. This not only enables us to capture good quality data but also enriches the data records by synchronizing the right data at a specific set frequency. This saves a lot of time, and our business can have accurate, complete, and meaningful data. We used a popular tool that is completely integrated with Salesforce. As Business Analysts, we need to be open-minded, understand business needs, and find the right solutions. In this case, rather than developing the Salesforce platform in-house, we found external tools to get the job done with minimal resources. The tool we used was an AppExchange product called D&B Hoover. This has a paid subscription managed package that is seamlessly integrated with Salesforce. Once synced up, the tool updates more than 100 account and contact attributes and adds a D&B identifier:

Figure 1.5 – D&B tool integrated with Salesforce on the Account Management page’s layout