In the Salesforce hemisphere, there are many different roles one could hold. One of those roles is that of a Business Analyst. Though it can seem to be a confusing and vague title, it is a significant role in the successful delivery of any Salesforce project. Generally speaking, a Salesforce Business Analyst is someone who will help run a project from start to finish and will take on tasks like Project Management, design and architecture discussions, potentially some build, and of course, training and enablement as the project is handed off to its owners. To be a successful Business Analyst, here are some best practices:

On the onset of any project, there are going to be elements that are generic and that you may have seen previously in other projects or companies. However, there also will be elements that are unique to the client and the project at hand. For example, think about the Lead Process - in general, in Salesforce, we know that we have a Lead, that will eventually get converted to a Contact and an Opportunity. However, the specifics of how that Lead is handled and the rules revolving around converting it will be specific to the client.

Something that can be detrimental to the success of a project is to try to solution and design in Salesforce before truly understanding the business requirements and the business process. It is essential to understand the goals of the business and the project before jumping into the solution; otherwise, you could land yourself in the position of being too far down one design plan and having to make patchwork to cover up holes that have crept in. Now, of course, it is still possible to have to cover gaps later on, even if the requirements were initially reviewed, but skipping the review step is guaranteed to leave you in this position.

In many cases, a client will want to rush to get a project out the door and will push you, as the analyst to move the project faster. Depending on the work, this might be possible, but you have to be careful. Moving faster should not be at the risk of the project not being as complete as it should be - and the quality of the work, compromised. When a roadblock is hit, even though the client wants you to move quickly, it is still better to consider what the options are and choose the most optimal one for the overall design, solution, and of course the business requirements.

Not always a result of moving faster, but comes when pressure is put on you, is the possibility of creating technical debt. Technical debt is the concept that what is being built is not something that will sustain itself long term or will not be easily maintainable coupled with the fact that you know this information from the onset. You could have technical debt that comes from having built on top of existing builds that did not have reviews. Where there is the potential for technical debt, you have to ensure that it is brought immediately to the client, along with the explanation on why it could be technical debt and the available alternatives. Of course, the client may opt for the technical debt route still, but at least you have brought it to the surface in case of a review later.

Never, should anything be built in Production, unless you are creating reports, dashboards, or profiles. Even simple things like fields and validation rules should always be built in the sandbox before Production. The reason is simple. You never know what else is going on in the system and without this step, you create unnecessary risk to the business by working directly in Production.

Having a streamlined testing path is critical for both projects and small one-off tasks. You can check out this article on Release Methodology to learn more about how to structure your sandboxes and ensure proper testing is done before making it to Production.

Always make sure that you have users test in addition to yourself and the owners of the project. Users tend to go about things differently than the way it was planned or even the way it was taught. While this may seem tedious, it is well worth it, as you will catch bugs, errors, and alternative workflows you otherwise would not have caught before the work getting into Production.

It is crucial to have a decision log that is kept throughout a project. By keeping documentation about decisions, you will ensure that long term, when the question of why something was done a particular way, you have an easy reference to indicate why it was done and who signed off on that decision. In addition, you should document the design of the project, along with the technical elements that made up the project. Doing so will ensure that anyone, later on, could read up on what was done and take over any new work that needs to be put into play.

Often forgotten are the concepts of training, enablement, and adoption to whatever the new process is. Remembering to construct a training plan from the onset will ensure that the project rollout will be smooth and will be accepted by the users. Training and enablement can come in many different formats, so don’t be afraid to pick a few that will work best for the client. Also, you will want to ensure that you not only plan for the training of the users, but you will also need to provide training to the people who will own the project once you move on. The hand-off process will be critical in the client being able to see the project as a success.

The most significant part of the job of a Business Analyst is to listen. You need to hear what the client needs are, what their requirements are. You need to hear them when they say something doesn’t work for the business and try and find alternatives that do. You also need to listen to feedback throughout the build and testing process to ensure that the final result is going to satisfy the client and meet their needs. Overall, if you don’t listen, your projects will never succeed.