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 capabilities
  • Non-functional: Describes the characteristics
• Transition 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 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 resources
• Timely decision making
• Provide direction – define the scope, prioritize requirements, and so on
• Influence escalations, resolve conflicts, and motivate

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.

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 Opportunity record 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

Since this tool is embedded seamlessly into Salesforce Account and Contact Pages, users can access this tool without the need for a separate login. In addition to customer and contact data, sales teams will be able to get innovative analytical features:

Figure 1.6 – Example where users can search for companies and sync them to Salesforce with one click

This example helps us to see that business needs are not always obvious. In this case, the business user did not even state their needs. By analyzing the root cause of low adoption, we interacted with many key stakeholders and SMEs to understand the needs. Then, we explored internal and external tools and found the one that best fits our needs. Sometimes, the end goal will help us with eliciting and drawing forth a business need that can have a positive impact on our business users.

Now, let’s look at some practical tips that I found useful.

I would like to outline a few pointers that you can use when you do business analysis tasks. These are relatively simple tasks that helped me tremendously. The simplest and easy-to-do items are always overlooked. You can avoid common causes of missing out on understanding business needs by taking note of the following pointers:

• Understand the goals and objectives of the business analysis work that you plan to perform. You should be in a position to explain in simple terms why you are performing these activities.
• For any business analysis effort to be successful and to be able to identify needs, analysts need to gain trust from stakeholders. This is a long process and needs to be earned. I would encourage you to start it early.
• Get to know the stakeholders. You can get information from organizational charts or social profiles.
• Schedule meetings in advance. Make sure that you find the right time and location/medium and block time in advance.
• Provide an agenda. Prepare and communicate it a day or so before the meeting.
• Facilitate the meeting and make sure that you encourage everyone to contribute. Your job is to facilitate discussion and mediate any conflicts.
• Capture notes (assign one of your team members who is good at note-taking) and send out the minutes.
• Follow up as needed until you and the stakeholders understand and agree to high-level requirements.
• Do not get into designing solutions. Understand the business requirements. If you’re savvy with Salesforce and CRM technologies, if you know a requirement is not feasible because of design constraints, say so and place it in the parking lot. Being open and honest will help build trust in the long run.
• Approach with a design-thinking mindset. Look for people and their needs before feasibility and viability. This automatically maximizes usability and user experience. Your goal should be to gain a good understanding of the complete situation and not provide options or solutions.
• Ask end users and stakeholders how their needs benefit them and their business unit. If this need is not fulfilled, do they have a workaround?

With this, we have completed this chapter on how to identify sources of requirements.

In this chapter, you learned where to find the sources of business user needs. By doing so, you learned how to get the requirements at a very high level and the key sources where you can plan to elaborate by eliciting more granular details. You also understood the key terms and ways to prepare yourself for the next stage of the requirement elicitations activity by utilizing the skills you learned in this chapter.

In the next chapter, we will discuss various ways to draw out user business needs and wants from various sources that we’ve identified so far. We will cover different techniques and extract information to accurately understand users’ requirements.

1. Explain the difference between functional and non-functional requirements in one sentence.
2. Name a few non-functional requirements.

• Business Analysis Body of Knowledge (BABOK®) Guide, by IIBA, Lightning Source Inc
• The PMI Guide to Business Analysis, by Au Project Management Institute
• Trailhead, by Salesforce: https://trailhead.salesforce.com/