Discovering Your Client
Good Questions
Two people recently asked questions about their new clients in the Salesforce Business Analyst Community. They wanted to know what client information they should gather to prepare for onboarding their clients. One asked about an org chart, workflows, and a glossary, among other things. The other person had already met with stakeholders and created a diagram for their current process. She also captured pain points and some new process requirements.
Both people asked what else they needed to know. Stuart Edeal, a business analyst with over 22 years of experience, replied with some good questions to ask the clients. He suggested first looking at the client’s business aspects. Here’s a sample of Stuart’s key questions:
What business need is Salesforce delivering?
Is there a vision statement or mission statement around CRM at the company and its goals?
Who does it provide that for? I would like to meet with those people and discuss their roles and business practices.
Tell me more about your business domain [and] all the business processes you have. Is that documented?
Why should business analysts or architects concern themselves with the client’s vision or mission statement, business practices, and processes? They connect the business analyst to the client’s values. With a thorough understanding of what a client values and how they create value, a business analyst has a clearer view of what the client needs and how to fill those needs.
I have found that connecting stakeholders to business value motivates them with a larger perspective of their value. For example, I showed a development team how their app improved user productivity and the impact that had on the client’s business. They realized they were making a much bigger difference than just writing code to specifications.
Business Analyst or Architect? Both!
After Stuart Edeal posted his business questions in the Salesforce Business Analyst community, he thought about them and wanted to make them more complete. He published BAs & CTAs – How to Begin?, where he starts with a key point from the Business Analysis Body of Knowledge (BABOK). A business analyst is a change agent, leading stakeholders through a process that changes the client’s business. This process starts with strategy analysis, which Stuart covers in detail in the article. A business analyst expecting “just” to gather requirements and deliver what the stakeholders ask for would find strategy analysis daunting. A business analyst with a thorough understanding of their client’s business and the value they deliver would welcome the change agent role.
Stuart goes on in the article to examine the Salesforce certified technical architect (CTA) role. He quotes the CTA job description, emphasizing key words:
CTA candidates must possess broad knowledge across multiple platforms in all domains. The CTA assesses customer requirements and architecture in order to design secure, high-performance technical solutions. Candidates must design a recommended architecture solution based on clients needs and must explain and justify why and how they will build the solution.”
He compares the CTA job description to strategy analysis and arrives at an interesting conclusion.
Stuart asserts that a CTA’s best ally is the client’s resident business analyst. I wholeheartedly agree, given that the client has a business analyst. Smaller clients often don’t have a business analyst because they don’t think they need one or don’t have the budget for one. The lack of a business analyst doesn’t let stakeholders off the hook as change agents. A Salesforce architect would assume that role, as suggested in the CTA job description.
An architect analyzing and driving business change as well as designing a solution sounds like a lot, but it has a precedent. If a couple hires an architect to remodel their house, the architect asks many questions about what they want. The architect may suggest changes the client didn’t think of, based on his/her experience. Those changes could make the client a lot happier.
The architect surveys the client’s property and house to have a thorough understanding of what s/he is dealing with before s/he starts any design. Once the architect draws up plans, s/he reviews them with the client, makes appropriate changes, and guides the contractor in making the changes a reality.
A Salesforce architect is a change agent whether s/he is a CTA getting requirements from a team of business analysts or the client’s CEO. S/he thoroughly understands the client’s business, like a building architect understands their client’s property and their needs.
Deepening Client Understanding
Stuart Edeal’s article concludes with a Project Discovery Document, containing questions in the following categories:
Company Overview
Current State
Future State
Data
Visibility / Accessibility
Reporting / Tracking Needs
Answers to Company Overview questions establish the client’s value context - what do they do, what do they want to do, and who works for them and with them. Current State focuses on how their business works today. He asks specific questions about customer relationship management, Salesforce’s traditional solution area.
Stuart includes topics in Future State to determine what a client needs from a solution. Future State does not specify the solution or how it works. That comes later, after developing a thorough understanding of the client and what they need.
The Data and Visibility / Accessibility sections get down to how much data the customer has, how long they keep it, privacy policies, and who can view or update what data. Reporting / Tracking Needs asks about the reports the client has, their key performance indicators (KPIs), and what the KPIs mean to the client.
Getting accurate answers to these questions starts the business analyst or architect on the path to understanding their client and their needs. Once the business analyst or architect has confirmed that understanding with the client, they can take on the change agent role to meet the client’s needs to make their business more valuable.
The best business analysts and architects dedicate themselves to understand their clients’ business, more than showing how much they know about their solutions.