Recently, one of our Account Executives invited me to a sales call to discuss our Continuous Innovation program for Salesforce with a prospect. While discussing our processes, the prospective customer asked what we do when a client gives us the solution to build, instead of a problem to solve. I explained that without understanding the business need, I can’t build a solution. I have to analyze the use case and requirements in order to properly analyze their solution.
My job, as an analyst, is to understand the customer’s needs, review their current business processes, and design a solution on the Salesforce1 Platform that aligns their requirements with best practices.
Everyone on my team has heard (had to listen to) my paper bag analogy. The client asks you to make them a paper bag, 12” x 6” x 14”. You confirm that is L x W x H, discuss handle quality, paper quality and then build a beautiful paper bag. They call you a week later to complain that the bag fell apart and they want their money back. “How could the bag break? I used superglue on the seams. What did you put in it?” “Water.” It is the analyst’s job to discover they want to hold water in the paper bag, and it is the analyst’s job to insist upon a better solution.
Analysts have to ask a lot of questions. What are you trying to do? Why do you want to/need to do this? How will you use this information? Who is going to enter the data? Who needs the data? Sometimes I ask these questions multiple times, to the same person or different stakeholders, until the use case is clear. I want to challenge the client’s thinking; have them examine the process from a new perspective.
You cannot design the correct solution unless you have identified all of the requirements. Requirements aren’t always easy to pinpoint. Merging best practices with the best technology available is only part of the process. It’s important to take the end users into consideration. Who is using the solution? How does this process interact with the rest of the users’ responsibilities? I constantly review a process I’m designing to confirm that I am automating and/or simplifying work for the user. During the User Acceptance Testing phase, I remind the clients that they need to get really picky. Tell me if the page layout requires too much scrolling, if field labels make sense, if the help text is actually helpful. If there aren’t at least minor changes requested during User Acceptance Testing, chances are the testing wasn’t thorough enough.
I make sure to empathize with every role. Is the data entry process too much for me as the customer service agent? Can I accurately measure my sales team’s results with the reports I’ve created? Do the KPI’s on my Executive Dashboard accurately depict my company’s performance? Do I have trouble reviewing the status of my records?
In order to build something that wows the client, I need adoption from their entire team. Thorough analysis is a key component to the successful deployment of every solution.