Four Business Analyst Misconceptions

Blazing a New Trail for Business Analysts

Salesforce Trailhead has a trail for business analysts, Get Started as a Salesforce Business Analyst. It introduces business analysis concepts in a Salesforce context.

The first module, Salesforce Business Analyst: Quick Look > Learn About the Salesforce Business Analyst Role, has a section titled Common Misconceptions. It explains four misconceptions about Salesforce business analysts. I’d like to offer the Purposeful Architect perspective on each of these misconceptions.

Misconception #1
“Salesforce business analysts need to be super technical.” 

What does this misconception mean by “super technical?” Let’s  say software developers and architects have “super technical” skills relative to other stakeholders. The developer implements a solution from detailed specifications provided by an architect or someone in that role.

In some cases, an architect takes on the business analysis role. A stakeholder seeing a “super technical” architect in the business analyst role could conclude that business analysts need to be super technical.

Good business analysts need to be super clear when communicating with technical people, such as developers. They need to specify exactly what the business needs from the solution in a technical context and understand what a developer means when offering alternative approaches to building a solution.

Misconception #2
“Salesforce business analysts shouldn’t do configuration on the platform.”

I completely agree - IF the business analyst doesn't understand the impact of the configuration change. 

Good business analysts know how a solution fits together from participating in the development process. The best business analysts check the impact a change would have on the platform before committing the change. If they have any doubt, they either determine the exact dependencies of the change or hold off making the change.

If a business analyst changes an org configuration on behalf of a system administrator, they should document exactly what they changed for the administrator.

Either way, the best business analysts communicate clearly with an architect or developer to determine the risk of an org change. They clearly document the change.

Misconception #3
“Salesforce business analysts are only needed after a project kicks off.” 

Who believes this? I asked long-time Salesforce business analyst Stuart Edeal if he was ever called in after a project started. He replied he had “been brought in AFTER a project started many many times.” His client told him to gather “the stakeholders together to get their needs and build out the scope of the work we need to do.” 

I agree with Stuart’s conclusion that bringing a business analyst into a project after it starts puts “the cart WAY before the horse.” It’s like tying the horse to the cart with a rope and expecting the horse to push it.

A solution initiative needs business analysis before its project kicks off. The first step in solution development determines what the business needs. The business analyst leads that discovery process. He or she should already know the stakeholders and started forming professional relationships with them.

If a business analyst doesn’t lead the discovery of business needs, who does?

Misconception #4
“Salesforce business analysts are only focused on requirements.”

Business analysts focus primarily on requirements when eliciting them from stakeholders. The requirements are a means to an end - delivering a solution to the business that meets or exceeds their needs. Taking a broader perspective, the solution improves the business, whether it offers a new service, saves costs, or meets a regulatory requirement.

A developer may believe a business analyst only elicits requirements and turns them into user stories. A good business analyst would reply that he or she ensures the developer's work provides value to the business, before and after the developer builds it.

Clarifying the Business Analyst Misconceptions

The first two misconceptions seem at odds with each other. The first claims a business analyst should be super technical, while the second asserts that a business analyst should not change an organization’s configuration. Even a business analyst with super technical talent should not change an organization’s configuration without fully understanding the impact of the change.  

Business analysts should participate in the early stages of solution development before the project kicks off. They need time to get to know the stakeholders and determine the current state of the organization.

Business analysts focus on requirements because they take responsibility for them. They also understand the context of the requirements - where the business is and where it wants to go. They ensure that the requirements focus on the business goals, and the solution will ultimately deliver value to the business.

Good business analysts understand, clarify and improve business requirements, keeping them connected to business value from discovery to deployment.