CRM Requirements Gathering Saves Time, Reduces Costs, and Delivers Smarter Enhancements

Requirements gathering is essential when it comes to managing enhancement requests for your organization’s Salesforce CRM. If you’ve ever spent time and effort to build out a field or automation only to find out it wasn’t actually what the user needed, you already know some of the risks of skipping this important step. A focus on gaining a clear understanding of a user’s request before solutioning avoids common pitfalls, including: doing duplicate work, releasing a solution that only partially addresses user needs, and burdening the system with unnecessary technical debt.

If you’re a Salesforce Administrator or Manager in the position of fielding user requests and making updates to your organization’s Salesforce database, having a requirements gathering process in place upfront will save you time while also ensuring users get the best solution to meet their need.

Assumptions Cost Time, Money and Confidence

It’s a wonderful thing when a user says they need help or a team says they need some new feature to support their work. After all, this is the first step to making the system more valuable for the organization. Many times the request comes in looking fully baked and ready to implement such as:

• “We need a new field for ……”
• “We’d like automation that ….”
• “We want to integrate with….”
• “Please update this page to show …..”
• “We need a dashboard of…..”

It’s at these moments it pays to remember, the job is to make the system more valuable for users, teams and the organization…., not to do as they say. Users often don’t have the right language or technical understanding to communicate what they need, so instead of simply acting on these requests with a technical solution, the real challenge is to first figure out what IS the actual issue or goal they have, and how best to address it.

A diligent and consistent requirements gathering process will reduce assumptions and increase clarity around how best to fulfill user requests.

Gathering and Documenting Requirements

Requirements gathering should be the first step in your process after a user makes ANY request for changes to the system. Even “small” enhancements will benefit from following the requirements gathering process, as system changes tend to have ripple effects that we can’t always see in the moment.

Why: Business Challenge

The basic process for gathering requirements starts with asking the question ‘Why?’ The goal is to understand what is at the core of the request; what is the business challenge or goal the team has that led to this request? “What’s this for? What process does this support?”

Until it’s clear how the team is functionally working and the business process they are trying to support by this change, it won’t be clear what change will best support them. Simple requests of “We need a new field” can hide more grand changes happening of “We have a new goal/process/requirement to….” Adding a single field might end up being the leading edge of a series of requests that if handled alone create a disjointed, incongruent solution.

Value: Who Will this Benefit?

Ask questions that are meant to shed light on the value of the change and the reasoning behind it. These could include:

• “Who will this change help?”
• “How will this change help?”
• “What is the cost of not having this change?”

Changes that benefit the whole team or are related to a core purpose of the CRM are more important than changes where only a single user will benefit. Worse, some changes, particularly those that are outside the purpose of the system, can actually degrade the value of the system, introducing complexity for everyone while lightly benefiting just one person.

Current State: How is it Being Done Today and What are the Pain Points?

Seeing the current process is important to understand the scope of the change being requested and hear about the issue being addressed in the context of a staff member’s actual work process. Helpful questions to ask could include:

• “How is this being done today?”
• “What is the issue with the current process?”
• “Can you demonstrate your current process and identify pain points?”

At this point in the process we often suggest screenshares to have users show their current use of the system and point specifically to the change they are requesting. Sometimes requests for ‘new features’ are solved by additional training; the ability was already there, but the user was unaware (or had forgotten) it existed.

Future State: What Does Success Look Like?

Questions like, “How do you want to work moving forward?” and “What would change for you when this challenge is no longer an issue?” start the process of solutioning without actually asking a user ‘what’s the solution?’

Most of the time, users do not have the technical understanding or the language to perfectly request the right solution (nor do you really want them to be dictating system changes) so this is a bit of a fine line to walk. You want to understand how they will judge that you’ve solved their problem while not actually requesting ‘what is the technical change I should do.’

We’ve seen big requests that would cost lots to set up and maintain, such as ‘Integrate with (insert Accounting System here)” turn into simple notifications of “let me know when an invoice is paid.” The simpler solution is generally the better solution to keep costs and complexity in check.

How Requirements Gathering Changes for Larger Enhancements

For bigger initiatives like new products, system overhauls, or multi-team processes, requirements gathering becomes a bit more formal. Because so many more people will be affected by the proposed changes, it can be helpful to implement workshops or structured discovery sessions and cross-departmental interviews.

These meetings will help ensure that you’re gathering and thoroughly documenting both the high-level and detailed requirements. Bigger initiatives will also take more time to complete due to their complexity, and usually require multiple rounds of validation and testing before the changes are ready to launch.

What to Do with the Requirements Once You Have Them?

When requirements gathering is done well, you’ll understand why a request is needed, who the users are, and how they will be impacted by the system changes.

This includes more granular details like reporting needs, automation, and the look, feel and layout preferences for the desired changes. Only when all those details are clear should you move forward with the actual system changes. There’s a couple caveats before you start building though.

Write Up the Requirements

Good documentation is critical to the next steps. At North Peak we like to use a format of User Stories to capture the critical needs to be met by any enhancement. The key piece here is a clear description of each user process the team is asking for. Examples being:

• Development staff reference (new field) on the Account record when reviewing donor status prior to phone calls
• Development staff have access to a report they run monthly on donors from the last month that have a value greater than X in (new field).
• When Development staff use the Doc Gen button to create the Donor Profile, (new field) is included in the right column under Donor History.
• Development leadership gets an email automatically when the value in (new field) is changed to be below X.

The result is a well-written requirement that serves as a single source of truth that everyone on the team can reference.

Confirm the Requirements

The User Stories should be the embodiment of the requirements from the perspective of the team that requested them. That team should be able to look at the written processes and agree that ‘this would solve our request.’

It is important that if stakeholders do not see a complete representation of their needs, that they speak up now. Raising that they needed something else after the feature is rolled out is too late. Once you have their go-ahead, document that approval and move on.

Explore Possible Solutions

It’s at this stage you want to develop a clear concept of the solution. So, do your research, use your imagination, test a few things in a Sandbox ~ do what you need to do to get a confident perspective on what the solution could or should be, while also limiting your involvement. Don’t build a big ‘ol prototype, rather do just enough to answer the key questions that will be asked in the next stage, namely:

• “What are possible solutions?”
• “To what degree would this solve the problem/request/goals?”
• “Who else will this affect?”
• “What are the costs to implement and maintain?”

Getting clarity around these questions is  key to understanding the impact of this change. Once you know the change you’ll recommend, we suggest updating the User Stories with a new column that shows the technical change to the system that is recommended to solve for each story.

Depending on the complexity of the request you may want to circle back around to present the solution options for review and approval. And lastly, you’ll want to make sure you document the solution decision with the original request.

Approval

Most organizations do not have the resources or capacity to make every change requested to the system. And frankly, not every change requested should be made. Some simply do not make sense given the purpose of the system or the ‘weight’ of the technical debt associated with the change. It’s at this stage that the requirements you’ve gathered and documented get paired with the research done on possible solutions and are put in front of the team that makes these decisions. If approved, move forward whatever process your team has for implementing changes to the system.

Implementation

In the implementation stage the requirements gathered, documented and approved will continue to be VERY helpful. For example, the User Stories will guide the Prototype build, providing a clear statement of need and a high-level description of the solution. During Testing, a QA plan can be quickly developed from the User Stories. During Training (or re-Training), the User Stories can guide the creation of a training curriculum and whatever updates are needed to documentation.

Conclusion

Requirements gathering is one of your best tools for ensuring efficiency and clarity around CRM enhancement requests. No matter the size of the proposed enhancement, when you have asked all the right questions and are clear on user needs, you’ll be able to deliver a sensible solution in a cost-effective manner that truly solves business needs.