Welcome to Business Analysis: Get Solutions Right the First Time
What is business analysis?
What makes a solution “right?”
How can business analysis lead to the right solution?
This e-booklet answers those questions and more.
Scroll down to see the online version (best for mobile devices).
Business Analysis: Get Solutions Right the First Time
About the Author
Richard Cunningham started building apps on the Salesforce platform in 2006, shortly after Salesforce introduced the Appexchange. He developed an event registration app that enjoyed early success on the Appexchange. Later, Coca-Cola engaged Richard's company, Blendery, to design and develop an app suite for its Global Hospitality group. They used the suite to manage guest registration, ticketing, and housing for the company's globally sponsored sporting events such as the Olympics and FIFA World Cup. The app suite was so successful, Coca-Cola Global Hospitality used it for more events than any previous solution.
Richard started the Purposeful Architect blog in 2020 to educate "accidental admins'' and others in the Salesforce community about the beginning stages of software development - business analysis and solution architecture. Purposeful Architect helps admins, architects, and others responsible for Salesforce determine what an organization needs from a solution to grow with changing needs. Purposeful Architect made SalesforceBen’s list of the top 20 most popular blogs in 2021.
Copyright Notice
Copyright © 2021 Richard Cunningham
All rights reserved.
No part of this book may be reproduced or used in any manner without the prior written permission of the copyright owner, except for the use of brief quotations in a book review.
“Our Org was taken over by keen developers who automated everything, and now we have the world’s best self-driving car … with no wheels.”
Have you seen a software project fail because of incomplete or incorrect requirements? Do you wish you knew what users needed in the first place? Do you suspect there must be a better way?
If you answered yes to any of these questions, this book and business analysis are for you.
Business analysis leads to meaningful solutions - those that meet an organization's needs. It discovers these needs among pain points, wish lists, and special interests. Business analysis curates an organization’s needs into requirements that get a solution right the first time.
Perhaps you think only large organizations with big development projects need business analysis. You may be surprised to realize that you are already in a business analyst role if you manage user change requests. Investing in your business analysis skills pays off with better solutions, reduced reworks, and rebuilds. It can also broaden your vision of the organization, opening up new career opportunities.
In this book, you’ll learn:
What business analysis is and why it’s important
Common business analysis pitfalls and how to avoid them
Keys to business analysis success
Techniques to get business analysis right the first time
With business analysis, you can develop the right solution for your business needs the first time instead of building an elegant self-driving car that goes nowhere.
Succeeding with Business Analysis
Organizations set goals to improve their offerings to earn and keep customers. Reaching these goals often relies on software solutions. While an organization may have a clear vision of a goal it wants to achieve, it may not know everything it needs from a solution to reach the goal.
Business analysis enables organizational improvement by defining needs and recommending or developing solutions that deliver value to the organization.
Business analysis revolves around discovering what an organization needs from a solution with the stakeholders who will use, manage or support it.
Business analysis basic concepts
The concept map below shows the relationship between an organization, a solution, and its stakeholders:
Brief definitions
A solution enables or supports the improvement of an organization’s products or services. It can also improve the organization’s quality, such as streamlining internal operations or complying with regulations.
Stakeholders are people who affect or represent those affected by a solution. They include users, management, information technology staff, and third-party solution representatives.
A business analyst leads stakeholders to discover and define what they need from a solution to achieve a business goal. Then, they curate the needs into requirements.
Requirements are specific business outcomes expected from a solution.
Why Business Analysis?
Business analysis intends to get a solution right the first time by defining the organization’s true needs it should fulfill.
Business analysis is like software quality assurance (QA). Solution development does not require business analysis or QA, but both are essential to meet the organization’s needs. Business analysis ensures the solution works as needed and expected by the organization. QA confirms that the solution works reliably.
Both business and QA share the notion of coverage. Business analysis covers what the organization needs from a solution within a specified scope. Insufficient coverage results in an inadequate or unusable solution. QA testing covers the solution’s functions to find bugs and have them fixed. Users may tolerate a few bugs in a solution that increases productivity but will not use a bug-free solution that impedes productivity.
To illustrate the importance of coverage, Salesforce requires Apex code to include tests that cover 75% of the code before deploying it to production. The arrow below shows the gap in the development process when developers overlook the required tests.
If the code does not have enough test coverage, the developers need to create and pass tests classes to cover the code. While it delays solution deployment, only the developers need to fix inadequate test coverage. Completing the coverage does not affect how the solution works.
If business analysis does not cover minimum solution requirements, it can take substantial rework to fulfill them. To illustrate, the arrow below shows how omitted needs affect a broad range of the development process.
Filling the gap requires:
Finding and communicating with stakeholders to discover the capability gap(s).
Analyzing the impact of gap-filling on the rest of the solution.
Rescheduling the development team to fill the gaps.
When a solution does not cover essential needs, stakeholders could become concerned about other functional gaps. On the other hand, good business analysis prevents coverage gaps from happening in the first place.
If a business analyst came into a project with functional gaps, they would ask why the gaps came about. For instance, a project team skipped business analysis, and developers built user-requested features without fully defining the problems they attempted to solve. But why would a project skip business analysis? The next section offers some answers.
An Analysis of Business Analysis
Why don’t organizations analyze their needs?
If business analysis is so crucial, why do organizations overlook it or risk inadequate requirements coverage? An organization developing or customizing a solution for the first time might not know about business analysis. So they dive in, trying to solve problems before defining them. They may get lucky by guessing what users need, but the “fire, ready, aim” approach often leads to wasted effort and frustration from reworking the solution.
An organization’s management may know about business analysis but not understand or appreciate its value. For example, they feel like they know what they want and don’t invest time and energy to clarify their organization’s needs. In that case, managers give the development team a high-level description of what they want, perhaps a wish list. Then the team makes incorrect assumptions about what the organization needs and management ends up disappointed with the solution. The stakeholders end up scrambling to fill the gaps.
An organization may have tried business analysis that turned out poorly executed. Perhaps the business analyst didn’t understand the business or took what users asked for at face value. The analyst did not explore what could go wrong with processes or overlooked requirements met by the incumbent solution. As a result, the organization got a solution with too many functional gaps and gave up on business analysis.
Why does business analysis fail?
Business analysis relies primarily on human communication, leaving it vulnerable to several pitfalls:
Undiscovered needs
Misunderstood needs
Scope mismanagement
Overlooking critical details
Most undiscovered or misunderstood needs result from the business analyst overlooking specific aspects of the needs. The worst question a business analyst can ask stakeholders is, “What do you want?” Instead, the business analyst should ask more specific questions, such as “What do you need from Sales Cloud to increase your lead conversion rate?” This question connects to a business goal - increasing the lead conversion rate.
A real-life example of undiscovered needs comes from an anonymous Salesforce administrator:
“Had to rewrite a bunch of stories because the person who created them didn’t capture all of the requirements and actually left a bunch of open questions before they were assigned out.”
OrgConfessions #578
The “bunch of stories” refer to user stories, brief descriptions of user-solution interaction. In this case, the stories did not cover enough of the business needs. When the admin reviewed the stories with stakeholders, the admin presumably asked a lot of critical questions. Then, the stakeholders went back to discover the real business needs and rewrote or created new user stories that covered the solution’s scope.
Scope mismanagement happens when analysis does not focus on determining requirements for a solution’s current version. Instead, a business analyst should focus on discovering business needs only within the current version’s scope. They should capture, acknowledge, and defer any other needs. Otherwise, the discovery process has no definition of “done” and can continue indefinitely.
Some business analysts mistakenly believe they have a “high-level” job, gathering requirements from stakeholders, taking them at face value, and leaving details such as exceptions for the development team to figure out. However, a good development team would come back with many detailed questions, and the analyst would have to return to stakeholders for answers. Even in that case, the solution could have functional gaps where the analyst did not discover enough of the organization’s needs or made incorrect assumptions.
Successful business analysis avoids the problems outlined above, producing complete, well-defined requirements based on the organization’s needs within the current scope. The next section outlines the keys for getting business analysis right the first time.
Keys to Business Analysis Success
Successful business analysis requires:
Management buy-in
Business goal alignment
Full stakeholder engagement
Clear communication
Thoroughness
Motivation
Management buy-in
Successful business analysis depends on the organization’s senior management understanding and appreciating its value. For instance, managers who have suffered from misfit solutions resulting from little or no business analysis can appreciate its potential.
Managers unfamiliar with business analysis can think of it as getting the solution right as soon as possible. It defines business needs well enough for the development team to fit a solution to the needs.
As an analogy, before an organization moves into new office space, executives and managers typically spend hours with the architect and contractor to ensure the space meets the organization’s and employees’ needs. Each director scrutinizes the details of the space to ensure it works for their department. The same scrutiny and attention to detail apply to what the organization needs from software solutions.
Business goal alignment
All stakeholders should have a clear understanding of the solution’s business goal. They should set aside their interests in other solutions or goals to focus on achieving the solution’s goal.
Full stakeholder engagement
Successful business analysis also requires stakeholders representing everyone affected by the solution. Also, stakeholders should make themselves available when needed to discover and verify the organization’s needs.
Clear communication
Business analysis success depends on clear communication. For instance, stakeholders often include subject matter experts who introduce domain-specific words or phrases into the analysis process. The business analyst should capture the terms and their definitions into a glossary for the stakeholders. They should agree on each definition to avoid confusion.
If discovery reveals many different terms, the business analyst can create a concept map to show the terms and their relationships. The Business analysis basic concepts section of this book provides an example of a concept map for business analysis.
Thoroughness
Discovering business needs often starts with stakeholders offering their pain points and wishes for solution features. However, they can easily overlook how a solution would affect processes already in place. Therefore, a business analyst should discover everything stakeholders expect from a solution based on their current practices, even processes they take for granted.
If the proposed solution replaces an older one, the business analyst should understand everything the older solution does, including integrations and automated processes not visible to users.
Once management has bought into business analysis and stakeholders have aligned to the solution’s business goal, they are ready to discover business needs. Next, the business analyst needs the motivation to lead discovery.
Business analysis motivators
Business analysts seek to improve business processes with solutions. They start by discovering what the organization needs from a solution.
Thorough business analysis goes beyond asking business stakeholders what they need from a solution to achieve their goal. Discovering needs requires curiosity, the primary business analysis motivator. Curious business analysts start by learning about an organization’s industry, values, and goals. Then, they focus their curiosity on a solution’s goal, discovering processes, alternative paths, business rules, and exceptions to the rules.
While discovering business needs, business analysts maintain clear communication by paying close attention to what stakeholders say. In addition, they invest attention in learning the organization, its values, and how it works, creating a context for discovering its needs.
Business analysts treat all stakeholders with respect, from an intern to the chief executive officer. Analysts earn stakeholder respect by paying close attention to what they say, acknowledging and clarifying business needs. In addition, the analyst respects a stakeholder’s time, realizing that discovering business needs takes time and energy in addition to their day-to-day responsibilities. Business analysts ultimately earn stakeholder respect by understanding what the organization requires from a solution.
Business analysts appreciate the value each stakeholder brings to the discovery and development process. They share this appreciation for stakeholder contributions, encouraging further participation by all stakeholders.
While working as a team, most stakeholders develop trust for one another. Business analysts start by giving stakeholders the benefit of the doubt. Then, they do what they say they will do, earning the other stakeholders’ trust. As Steven Covey said:
When the trust account is high, communication is easy, instant, and effective.
Once motivated business analysts have the keys to success, how do they get business analysis right the first time? The next section offers some answers.
Successful business analysis executes the steps shown in the process diagram below.
Those new to business analysis often skip the “Prepare for analysis” step, anxious to discover what the organization needs from a solution. However, investing time and energy in preparation pays off by saving and respecting stakeholders’ time.
Prepare for Analysis
The process diagram below shows the steps to prepare for analysis:
Understand the business goal
Prepared business analysis starts with understanding the organization, its industry, values, and goals.
What differentiates the organization from others in its industry?
What are its key values?
How do its goals fulfill those values?
The answers to the questions provide a context for discovering business needs and what’s most important when dealing with the details from the discovery process.
The organization needs a solution to help it meet a goal. The stakeholders start by agreeing on a scope containing only the organization’s needs to reach the goal. Then, the business analyst continues negotiations to establish a version scope focusing on urgent and important needs.
Form management alliances
Business analysts need management allies to deal with issues throughout the discovery and development processes. Each alliance should help them overcome obstacles and conflicts, keeping the discovery process moving forward.
A director or manager most impacted by a solution, such as a project sponsor, makes an excellent internal ally for business analysts or architects. Management allies provide insight into the solution's impact on the organization. Also, they should have the necessary understanding and authority to resolve client stakeholder conflicts. Finally, management allies can help negotiate the solution and version scope by ranking solution needs.
When discovering needs, business analysts and architects often work with specialists known as subject matter experts. Business analysts and architects often have questions about each subject matter expert's processes. If documentation exists for the processes, it may assume domain expertise a business analyst or architect doesn't have. An alliance with the subject matter expert helps fill those gaps.
In some cases, a department can "go rogue," hiring an outside firm to develop a solution without involving its Information Technology (IT) Department. The department manager usually justifies this by saying IT is not responsive or too slow (backlogged). In this case, good business analysts and architects create an alliance between the department and IT by acting as a liaison.
Develop a business needs mindset
System administrators or architects taking on a business analyst role often find it challenging to set solution implementation aside and focus on business needs. For example, they start solving a problem as soon as they hear about it, rather than first discovering all the problems a solution should solve.
Once a solution project has been approved, pressure mounts to deliver the solution. Developers want to start coding, users want the solution’s benefits, and management wants to see its results. A business analyst advocates completely defining the problems before proceeding with implementation. A management ally can help by outlining a complete picture of what the organization needs.
Attention to detail applies to discovering business needs as much as it does in developing a solution. Good architects and developers resist the temptation to cut corners in design and development. Good business analysts pursue all of the business needs a solution will fulfill, realizing that cutting corners can result in an unusable solution from overlooked needs.
Once a business analyst understands a solution’s goal, has a management ally, and has a thorough discovery mindset, they are ready to lead the stakeholders to discover what the organization needs.
Discover Organization Needs
A business analyst leads stakeholders through the discovery of the organization’s needs to reach a goal. First, the stakeholders, including the analyst, define the scope to keep the discovery focused. Next, the analyst captures and acknowledges each need, asking follow-up questions to define it completely. Finally, having captured all the needs, they curate them into well-understood requirements and confirm their understanding with the stakeholders.
The process diagram below illustrates the discovery steps:
Define the solution scope
Discovery should focus on a solution’s purpose - delivering value to the organization by achieving a specific business goal. The stakeholders agree to consider only the business needs to achieve the goal. These needs fall within the version scope. If out-of-scope needs arise, the analyst captures and defers them. Discovery concludes when all needs are well-defined within the scope.
Capture organization needs
A business analyst captures business needs from stakeholders in the context of the solution fulfilling its goal. The stakeholders may already have some needs in mind, but it doesn’t stop there. The analyst drills down to a level of detail that completely defines the needs.
For example, a business aims to improve sales efficiency, with a specific objective to increase its lead conversion rate. The analyst asks several questions:
Where do leads come from?
On what basis are leads assigned to sales reps?
What happens to unassigned leads?
What qualifies a lead to become a contact?
What’s the next step for a new contact?
What happens to leads not converted into contacts?
The business stakeholders may not have immediate answers to questions like these. In that case, they work out how they want the process to work with the new solution. Once they do, the analyst asks follow-up questions to clarify the stakeholders’ expectations.
When analysts capture and record a business need, they acknowledge it to the requesting stakeholder(s). However, the acknowledgment only confirms the analyst captured the need correctly. It is not a commitment to fulfill it in the current solution version.
Stakeholders may introduce solution ideas during discovery. If the idea falls within the version scope, but the business need isn’t clear, the analyst asks the stakeholder what problem the idea would solve. If the idea falls out of scope, the analyst records it, defers it, and acknowledges the deferral to the requesting stakeholder(s).
Curate needs into requirements
Pain points, solution ideas, and wish lists emerge from discovery along with business needs. Business analysts determine the needs that fully cover the scope and curate them into requirements. A requirement specifies a business outcome, focusing on understanding the value its fulfillment delivers.
For example, a business needs to improve its lead conversion rate. After learning more about the need, a business analyst curates it into three requirements:
Optimized lead assignment
Improved lead qualification
Streamlined lead conversion
The business analyst focuses on understanding these requirements, including the details of how they’ll deliver value.
Understand requirements
Successful solution development depends on the business analyst and architect’s understanding of all requirements. The diagram below shows the balance between requirements understanding and thoroughness.
A business analyst or architect who does not understand the requirements puts the solution project on a course to failure, shown in the lower half of the diagram. On the other hand, when they understand the requirements, they set their projects on a trajectory to success. They can even recover incomplete requirements with enough understanding.
Confirm requirements understanding
Complex processes often emerge from an organization’s needs. Breaking these processes down into simpler steps has the following benefits:
Stakeholders review and understand a process more easily as a sequence of steps.
Reviewing the steps can reveal gaps in the process.
Filling gaps between the steps makes understanding the process more complete.
A process diagram shows steps as boxes connected with arrows. Universal Process Notation (UPN) provides a simple yet powerful way to create and understand process diagrams. It connects activity boxes with arrows labeled to show activities’ inputs and outputs, as shown here:
This section of this book uses process diagrams to illustrate the analysis process.
Any activity in a UPN process diagram can drill down to another diagram showing the activity’s steps in detail. The drill-downs organize the diagrams into a hierarchy, which forms a process map. A process map can have as many drill-down levels as needed to clarify ambiguity.
Suppose any stakeholders, including the business analyst, are unfamiliar with words, phrases, or concepts introduced by other stakeholders. In that case, the business analyst should add these terms to the glossary.
If a need arises to review organization-specific terms, a business analyst can create a concept map. It shows the terms in boxes connected by arrows, like a process diagram. In a concept map, the arrow labels show the relationships between concepts, and each arrow shows the order to read the concepts.
Ensure the Solution Meets Needs
Business analysts ensure a solution meets the organization’s needs with these steps:
Educate the development team about requirements
Once a business analyst or architect understands the requirements, they share that understanding with the development team. The more a team member works with business stakeholders, the better they should understand the requirements.
Answer development team questions about requirements
Requirements include user stories for agile development or functional requirements specifying how users expect a solution to work. A business analyst should anticipate development team questions about the stories or specifications. Then, an analyst or architect takes the team questions they cannot answer and follows up with the business stakeholders for clarification.
Verify solution meets organization needs
A development team typically starts by developing a prototype solution with only mandatory features for stakeholders to evaluate. Next, a business analyst or architect demonstrates the prototype to stakeholders, eliciting their feedback. Eventually, stakeholders can try the prototype themselves to provide more detailed feedback.
Business analysts should validate a solution before releasing it for user acceptance testing. They start by checking the solution against user stories or functional requirements, ensuring it fulfills the organization’s needs within the version scope. If an analyst finds gaps between the requirements and the solution, they record the gaps. Then, they negotiate with the development team on closing the gaps.
Conduct user acceptance testing
Once business analysts have validated the solution, they lead user acceptance testing. At a minimum, users ensure the solution works the way they expect, covering all the requirements. Ideally, the testing users will try cases that stress solution functions. For example, a user tests converting a lead to a contact, but converts the wrong lead. How would the user undo the conversion?
If user acceptance testing uncovers gaps between the organization’s needs and the solution, a business analyst captures all of the gaps. Then, they negotiate which gaps the development team must close for user acceptance. Finally, the team closes those gaps at a minimum.
Well-managed user acceptance testing provides the ultimate metric for business analysis success. If gaps emerge in the testing, a business analyst determines where communications broke down to create the gap. For instance, a discovery oversight provides an opportunity for the analyst to improve future discoveries. Likewise, if the development team overlooked a requirement, the analyst takes the opportunity to improve team communications to prevent future gaps.
Discovering and closing solution-requirement gaps informs improvement of the next business analysis cycle.
Key Points
Business analysis ensures a solution meets an organization’s needs by discovering and defining those needs.
Successful business analysis requires:
Management buy-in and alliances
Stakeholders fully engaged and aligned to a business goal
Clear communication among all stakeholders
Attention to the right details
Develop a business needs mindset, postponing solution implementation details
Focus on the current version’s scope
Curate the organization’s needs into requirements that achieve the business goal
Understand the requirements thoroughly
Show stakeholders process and concept maps to confirm understanding
Share requirements understanding with the development team
Lead user acceptance testing to:
Confirm the solution meets its requirements
Discover gaps between the solution and its requirements
Learn how to avoid future gaps
Business Analysis Knowledge Resources
The Business Analysis Knowledge page in this book goes into more depth about the business analysis concepts in this book.
The Concept Index lists all the concepts, grouped into categories.
Congratulations!
You made it to the end. Now, you can apply the ideas and tools you've learned at work. If someone asks, “what do we need business analysis for?” you can show how it enables your organization to develop solutions right the first time.
If you’d like ongoing insights on business analysis, follow my blog on Purposeful Architect.
I hope you enjoyed the book and would love to hear how you use these concepts in your professional life. Feel free to email me at richardc@bendery.com.
Discovery & Design for Salesforce Solutions
Acknowledgments
Thanks to Gina Danford for editing this book.
Process and concept maps created using Elements.cloud.