When Your Technology Falls Short: 3 Tips to Document Requirements
Fiona Buttars, PMP
Manager, Professional Services
It’s inevitable. As a nonprofit fundraiser, marketer, or administrator, you will eventually run into something (or let’s face it, maybe a LOT of things) you need your CRM to do, but the technology can’t deliver with its out-of-the-box functionality.
Being the nonprofit professional you are, you go into problem solving mode. If it’s a very niche requirement, maybe there is a third-party tool that can accomplish the task? If it’s an issue of siloed data, maybe a custom integration can solve the problem? Perhaps you’ve outgrown your current technology, and it’s time to replace the system as a whole? With the numerous possibilities, where do you even start?
Here at JCA, we’ve found that it’s helpful to first capture your need(s) before searching for a solution—whatever the size or complexity of the problem. We’re sharing three techniques to help you articulate and document your needs.
1. Develop a Business Case
A business case is a written document that explains the reasons for making a change. A business case evaluates the benefits, costs, and risks of this change. The purpose of this document is to convince decision maker(s) to approve an action.
You and your team can use a consolidated business case to drill down to the most important “Whys” for a new solution, before there is a need for a formal request or approval process. Walking through these three questions can help articulate your business case.
Business Problem: What is the problem and what are you trying to solve?
Example: You store event information in external spreadsheets and you have challenges reporting on event data.
Goals and Objectives: What do you want to achieve?
Example: You want to provide more timely and comprehensive reports to leadership.
Success Criteria: What and how will you measure if you are successful?
Example: You are able to track all essential data in one system and produce comprehensive reports that show the following data points: member ID, name, level, event attendance, cumulative spend per year.
2. List Functional Requirements
A functional requirement describes the service that the software must offer and specifies particular results of a system. Generally, functional requirements are expressed as: the system must do x requirement.
Requirements can range from business processes and administrative functions to data manipulation, authentication, and authorization. It can be helpful to categorize the requirements, particularly if they fall across different teams or departments in your organization, such as Audience Services, Annual Giving, Donor Relations, and Event Management. Another helpful form of categorization is to divide your requirements into a “must have” and “wish list.”
Requirement examples include:
- System tracks solicitation efforts at multiple levels such as by program area or campaign, specific effort, packages within an effort and communication channel (Mail/Email/Event, etc.)
- System suppresses constituents from mailing lists
- System records event staff and roles (paid staff and non-staff volunteers), including speakers
3. Develop User Stories
User stories originated in the agile software development world to divide functionality up into smaller pieces. User stories are short descriptions of a feature told from the perspective of the user and are more about the need of the user as opposed to the system, such as how the feature provides value to the person, you, and your team.
There are three basic steps you can use and adapt to create user stories.
Index Card: The idea is to write down your need on an index card and keep it concise. A format you can use is: As a user, I want/need x so I can accomplish y.
Example: As a gift processor I need correct matching gift information so I can link gift records accurately.
Conversation: The requirement needs to be discussed so there is a shared understanding. Conversations can foster collaboration and lead to refinement of the requirement. In the agile world, the requirement needs to be accurately understood to be incorporated into development. In your case, the key is to share your requirement with other(s) and potentially refine it based on feedback.
Confirmation: Confirmation is when we take these essential requirements that come out of conversations, and we state them as criteria or conditions that must be met by a potential solution. This helps test to ensure that the requirements meet the defined criteria. In your case, this may be speculative since you are not in the development phase of a custom product. However, you can still come up with some useful applicable acceptance criteria.
Example: Users can complete transaction by credit card. An acknowledgment email is sent to the user once registration is complete.
These three techniques will help you better understand, document, and refine your needs as you work through your decision-making process.
Are you in need of some help to define and gather requirements?
Every organization has its own distinct and surprising challenges. Through interviews, discovery, and careful analysis, our nonprofit CRM consulting experts will help you align your technology with your organization’s strategic focus.