This blog is an update to a previous blog entitled “Simplify Salesforce Requirement Gathering With Use Cases.” You can find the original blog here.
Cloud for Good has long used our proven iterative methodology to implement Salesforce solutions for nonprofits and higher education clients to ensure project success and incorporate best practices. Following this approach, we begin with a Discovery phase, which includes sessions and workshops facilitated by our team members for your stakeholders as well as the development of important documentation to help us understand and define your requirements. This blog will outline why we stand so firmly by this approach – and some ways in which we put it into action.
Building a Foundation of Communication
Ensuring that the stakeholders who will be impacted by the project have had an opportunity to clearly communicate their needs is critical to ensuring: a) that they will eventually be motivated to adopt the solution, and b) that the solution being built along the way is aligned with their actual vision and goals. During Discovery, we ask stakeholders to share with us not only how they are doing things today, and what could be improved in those processes, but also how they’d like things to be in the future.
What could be streamlined?
How could things be more efficient?
What metrics would they love to report on if the data were available?
These questions help us to be certain that important stakeholder needs won’t be missed as we develop our solution.
Requirements Gathering
Gathering specific stakeholder requirements is also important because every organization is different once we dig into the nuances. We’ve partnered with nonprofits and education institutions for long enough and have enough experience amongst our team to be able to make some good initial assumptions about new client needs.
For example, we can generally assume that fundraisers will want to track multiple payments for a single pledge, or that student advisors will want to be notified if one of their advisees has missed an important deadline such as class registration. However, as we are designing the architecture for each organization’s Salesforce instance and developing specific solutions, we want to know more.
What are the key data points that are tracked related to a payment versus a pledge?
What is the process today for a fundraiser to relate a payment to a pledge?
How are advisees assigned to advisors?
Documenting requirements, and documenting our Discovery conversations more generally, is also of paramount importance. It enables us to re-review stakeholder comments as needed, validate our understanding so that we can come back with questions in the places where we have gaps, ensure alignment with you on how we understand the requirements, and subsequently consider how to solve requirements with technical solutions.
Planning the Right Approach
There are many approaches to requirement documentation; I will highlight a few used regularly by our team members. During the planning phase of a new project, we collaborate with you to identify the right approaches to gather and document requirements based on your stakeholders, the type of project, and more, and will often times use multiple approaches to meet multiple needs.
Sometimes we leverage use cases. A use case is a sequence of actions that describes the interaction between a user and the software system to complete an activity you need to accomplish. Ideally, a use case should include all the following:
A user (which could be either you or a constituent)
Any data inputs and outputs required for an action
A clear sequence of the steps that occur
A specific result or goal (e.g., a successfully submitted case)
Business Process Mapping
Sometimes we leverage business process mapping, which is the documenting of the process to achieve an outcome, in business terms, either today or in an ideal future. In other words, a current state business process map tells us the “as-is” functional and operational process, including descriptions of highlighted pain points and interdependencies.
We document your current state processes when we’re gathering requirements so that we can ensure a comprehensive understanding of the full scope of your processes today, thus enabling us to make better recommendations for the future state. We also may diagram future state business processes: optimized/streamlined, “to-be” business process flows based on what your stakeholders describe as a better approach to get something done, supporting the development of the eventual design and technical plans for your Salesforce instance.
User Stories
Most of our projects also include user stories. User stories are descriptions of individual requirements written in the format: “As a [someone], I want or need [something], for [some reason].” We populate all of the user stories for a project into a prioritized list called the backlog; most of the Stories are added to this list in Discovery as we’re gathering initial requirements, but new stories often arise throughout the project as well as stakeholders’ requirements change, or they realize new ideas that could help them work more efficiently.
Acceptance Criteria
We also draft acceptance criteria (i.e., a set of requirements necessary to consider a user story complete) for each user story, as well as other key components to categorize them and estimate their level of effort. Together, the core user story itself and its components are provided back to stakeholders to review and validate, which enables us to ensure that we’ve correctly understood their requirements and have captured all the critical details. This documentation as well as the other types noted above can also be leveraged throughout the project’s Build phase to ensure ongoing alignment and to support testing and training activities.
Without clearly defining what the end-users require from a business or functional perspective, prior to defining the technical solutions to meet those requirements, it’s possible that essential needs will be missed or that functionality will be configured incompletely or incorrectly. Thus, we conduct a comprehensive Discovery phase that includes various methods for both gathering and documenting requirements so that we can transition smoothly into a Build phase knowing that we have the ingredients for success.
