Being a business analyst always seems like one of those jobs that could mean anything within the tech industry especially with what I have heard from people who are actual business analysts. From someone managing a project board, someone who prepares meetings and high-level understanding of the architecture, or in some cases someone who documents processes and meetings. I decided to deep dive into what is a Salesforce Business Analyst and fully understand what can sometimes be a vague and all over the place role within the Salesforce World. So, I picked up the book on it.

What I Took from It

The important part of being a QA is planning, understanding, executing plans, STRONG documentation and a well thought out process can help the team with items that come down the road. I would say probably one of the biggest key takeaways I took was the entire QA process and how much more seriously that needs to be taken within the tech world. QA and UAT testing are some things that need to be planned and communicated with precision. The testers need to know what they are testing and all this needs to be communicated with the BA leads. It isn’t just about QA doing the testing, but everyone involved in the build effort to understand how it will be tested and what the outcomes will be. It isn’t about how you think it will be used as a dev, but how it will be used according to the use cases.

Another important thing I took from it is that a lot of ideas predicate on the malice of an assumption, we assume the data is clean, we assume the automation flows has been checked, we assume the team understands the functional and non functional requirements, and finally we assume everything has been documented clearly. Nothing should ever be assumed; decisions and requirements should be based on all possible outcomes that are backed by the evidence and for a BA to idealize this is definitely an undertaking. Also don’t be afraid to point out scope creep and technical debt that could arise because it always comes back around. Sticking to your guns and drawing a line in the sand can help to temper disappointment when things are overpromised and undeliverability happens. Now I know this is an easy idea in writing, because I am sure if you are reading this you have been on a project where a date gets pushed up, or the client comes in and pulls an office space and tries to push the team to work a weekend but in theory, if that happens it will be up to the team to say no and stick to the timeline laid out. It’s not always about being first but being the first to get it right.

It also occurred to me that with this book, there is a massive misunderstanding in knowledge transfer, I didn’t know there was a difference in how it should be approached. In the past I have seen knowledge transfer just be a walkthrough of how the system is built but going into more detail of the why it was built and the process of the way it was built this way can help to push the new training and knowledge transfer for the better. Also having more than just the training document and or video, confluence and past story creation and scrum ticket updates mean that the team can view the history of the systems creation and the process it took on during creation. Going into ticket history and showing how the project has evolved can help with understanding direction of the goals. Which does bring me to my next point, documentation is key to it, I have been told from many different people over the years, the documentation process is just a massive cloud drive full of everything just being thrown in, and pages and processes are scattered everywhere. Organization, planning, and upkeep can help mend any organizations documentation.

Who Is This Book For

I would say this book is for anyone within the Salesforce career track or CRM track in general. If you are a dev, app builder, admin, Marketer, or even sales, I would recommend you read this book. Understanding what exactly a Business Analyst does and the entire lifecycle goal from a top-level view to even the more micro level view can sometimes clear the confusion over the goals of the project and what the business analyst’s role actually is.

In Conclusion

I took away quite a lot from this Business Analyst handbook and with it diving into the entire salesforce project lifecycle as a BA can give better insight into how we ourselves fit into the project and process. I know a lot of times team members can become so hyper focused on their role and lose sight of the overall project and maybe reading this book can help people be more mindful of that cause the idea of the project can very much change as it is built out and its up to the team of BA’s and the team members to stay aligned and hopefully this book helps with that.