Knowing how to gather requirements is a key skill in any Salesforce role – especially for Business Analysts, Salesforce Admins, Architects, and Consultants. To extend your Salesforce org in a way that will serve your organization for the long term, you need to do requirements gathering for major Salesforce projects, down to minor operational updates.
It’s these stakeholder requirements, when not part of a formal project, that can often ‘slip through’, overwhelm the implementation team, and jeopardize the integrity of the org itself (eg. by generating technical debt). As tough as it may seem, sometimes pushing back, saying ‘no’, is the right answer.
Obviously, there is tact and judgment at play. By understanding 5 basic techniques, an admin can learn the art of saying ‘no’ while also building iron-clad business requirements.
The requirements gathering process is simple, right?
It should be simple, right? You sit down, sip an iced coffee, and listen to someone explain what they want for a half-hour, and go back to your desk. If the requirements gathering process is so simple then why do so many of us have such a challenging time doing it well? As cliché as it may sound, the reason is requirements gathering is a task that can be easy to do but hard to do well.
In a Salesforce role, making people happy is gratifying. Automating a process or answering a request can lead to a congratulatory email or a shout-out. This desire can cause the more junior and even the more senior, individuals to avoid pushing back.
As I mentioned, there is tact and judgment at play. End-users should view you as a partner, not a roadblock, and there is a balance to be had. Continuing to deny or push back on requests to an extreme may cause team members to go elsewhere for their solutions.
1. Test assumptions, solidify business need
While the meeting may go by quickly, briskly taking down requirements and leaving will cause more problems than it solves. Asking great questions can pressure test these assumptions and solidify the business need. This can take many forms such as: What happens to this process when an Opportunity retreats in the Sales stage? Do we need more members included than just Sales Leadership?
The goal here is not to stump end-users and deny their request but cause them to think and expand their thinking. Without saying ‘no’ verbatim you are beginning to take steps to challenge and push back in a collaborative manner. If an individual is unable to articulate their point and add clarity, this may be a sign that they need to further hone their request.
Completing this exercise adds the needed sinew and fiber to what otherwise would be hollow requirements. Once defined, consider adding these refinements into the description of your code or process automation tools to allow other admins to be aware.
2. Be transparent with the effort changes will require
Every admin has had a similar experience when gathering requirements. As the user is talking, you may already be mapping out solutions simultaneously. Eventually, that user will say something that sends your architectural build screeching to a halt. While smiling and nodding is a common reaction, sometimes being upfront with your end-user can help.
Even if it is not immediate, going back and saying something like: All of these requirements are good but of the 15 changes, this one specific configuration is going to take 10 times longer than all of the other changes combined. If that is mission-critical, happy to apply it but here are some alternative solutions. By treating your team like adults, they will begin to have a better understanding of the process which will lead to more efficient solutions.
3. Watch out for ‘edge cases’
Now that we have talked about the ‘how’ of pushing back, let us begin to discuss ‘when’ to decide to employ certain techniques.
When asking questions about a business process and the words ‘sometimes’ or ‘not always’ start creeping up, this may be time to pause and analyze potential red flags. These exceptions/edge cases can chip away at process automation or development projects and cause issues to spiral.
Doing your best to pause and push on those terms can save hours of headache down the road. Hammering out these pockets of ambiguity can lead to improved processes. The result may be adding complexity to support branches in business logic or either introducing manual steps to reduce configuration.
4. Balancing multiple stakeholder requests
Now that we are feeling good about the ‘how’ and ‘when’ components, we can explore ‘why’ a bit more.
Chances are your projects are going to involve stakeholders across multiple teams. So even if you are getting great, clear, and concise requirements from one stakeholder group, it could potentially obliterate the processes of another team. That team should be able to inform or even deny a prospective build.
An example may be a process that frees up time ten minutes for a finance stakeholder but causes hours of additional work for a sales team member.
To achieve this harmony and allow discussion, stakeholders from all teams need to be included.
Prior to a meeting, ideally, review a brief or get some general summary of what the requirements are going to entail. Try to include those stakeholders from relevant teams in the meeting or do your best to communicate post-meeting and in multiple formats afterward whether that is informal conversations, multiple emails, newsletters, etc.
Depending on the structure of your organization, there may be more formal mechanisms in place but consider operational structure. Are we defining key stakeholders from every group? Are they signing off with full knowledge of the implications? Is there workflow documentation that has been developed to inform the current process as well as the revised process? These types of communication strategies support end-users to allow everyone to leave a meeting with an equal understanding and stake in these organizational changes.
5. Is the documentation consistent?
How can we get to ‘no’ faster? The answer lies in the documentation and process.
If an admin is on a small team, they may document business needs for a build they will oversee from start to finish. If the team is larger, the requirements may be used by other analysts or developers to inform them of what to build. This could mean that you are submitting documentation along with many other admins simultaneously. If the recipients have to sift through the many personal touches of document structure, tone, terminology, etc., you are going to waste time and delay go-live for your end-users.
Ideally, the team should develop some templatized format to avoid the potential of fractured requirements gathering. Collaborating between admins, developers, architects, and individuals across operations should inform the layout and design of this intake template. The upfront work will pay off in dividends as this will allow the end-users to prepopulate some documents prior to the meeting and allow an accelerated ramp-up of more junior team members.
Summary
If an admin simply says ‘yes’ to every request, they are not completing their duties as a true Salesforce steward. For short-term gratification, they are simply enacting changes without being mindful of a strategy or vision. By tactfully including ‘no’ into your vocabulary more, an admin can balance out and better those around them by causing end-users to think and consider their business needs.
Comments: