Over the course of my nonprofit Salesforce career, I’ve come face to face with what I now view as the dreaded requirements document. This is the (extremely long) detailed spreadsheet that a consultant may prepare for you to detail all the specifics of what is to be built in your system.
Examples of what might be on a Requirements document:
- This field should be moved from a multi-select picklist to checkboxes
- This custom object should be created
- Install the NPSP Relationships and Affiliations managed packages to track jobs
- Values in this field should be consolidated into the following values
Every time I came in to lead a project mid-way, I shuddered to encounter this unwieldy document. There were in fact, real solutions detailed there – the NPSP Affiliations could absolutely be a great way to track jobs – but it didn’t give me any of the why, or what was most important going forward for the client.
Besides being extremely difficult to navigate and pull out any sense in a laundry list of requirements, these documents deliver one of two possible outcomes:
- You will get exactly what is spelled out in the requirements document (which may not be what you need), or,
- midway through the project your consultant or developer will figure out what you really need, and they’ll ignore the requirements document and thus throw out the time your organization invested in creating it.
For example – you may need to track jobs. But perhaps you need to track jobs for the students in your program – and your real goal is to see how long it takes for your student to find a job once they start looking, and your secondary goal is to track how long they hold that job. You want to compare their job placement and retention rate to the general population in their age group, and report on that to funders. You also want to build out your jobs referral and internship program, and track students matched to jobs also based on internship.
Affiliations don’t look so great anymore.
Once these important outcomes of what it means to you to “track jobs” are defined, the specific requirements detail can be built on a more solid foundation (and at that point, the fields involved can be refined in a 15 minute conversation with your consultant on demoing the solution).
As a nonprofit, knowing your own requirements are important at a base level (your tool needs to be cloud-based; participants need to be able to login to one system only to access their data).
But I’ve never seen an excel spreadsheet actually define organizational goals in any cohesive way. It’s time we as an industry serving nonprofits focused less on requirements documents, and more on documents that outline actionable goals that are achievable through the Salesforce.com platform.