NONPROFIT SUCCESS INSTITUTE

SPEAKER SERIES 2021

SESSION 5 – TECHNOLOGY

JUNE 16, 2021

Session Speakers

Jennifer SandersDallas Innovation Alliance

Joni Martin Bryan9Forty Coaching

Armando CantuCARDBoard Project

Ola AdegboyegaCommunities Foundation of Texas

Joni BryanSheEO at 9Forty Coaching

STRATEGY | INCLUSION | TECHNOLOGYFor Community Leaders & Social Impact Organizations

Demystifying the Nonprofit Technology Selection ProcessA CRASH COURSE ON THE WORLD OF NONPROFIT TECH

Agenda● About me● The 2 types of technology providers● Build vs. Buy: Pros and Cons● Complex Scenarios & Data Silo Considerations● Pricing Structures● Do’s and Don’ts; 9 Reasons to Ditch the RFP● Questions to Ask Yourself● Considerations and Key Takeaways● Questions to Ask a Consultant

About JoniOver the past 25 years of my career, I have worked with hundreds of organizations: from micro-organizations with few or no paid staff, to enterprise organizations with staff and offices all over the world. My background includes:

● 8 years experience in consulting for Nonprofits and Social Impact Orgs● Awarded Salesforce MVP 2014, 2015, 2016, 2017, 2018; inducted into the MVP Hall of

Fame 2019● 25+ years working in the social impact sector; Founder/Co-Founder of 3 nonprofit

organizations● Educational background in Human Services and Community Organizing● Real world experience with fundraising, events management, marketing, technology,

human resources, and human services

About 9FortyWhat’s in a Name?

9Forty’s mission is to provide grassroots community organizations access to expertise, guidance, and information to more effectively leverage resources and technology available to further their mission.

That’s because I believe that change happens in our communities, in mobilizing passionate people to make change where they are. 940 is my community area code, and I chose the name to honor the importance of small but mighty community organizations making change to our world!

The Basics: Starting at the Source

2 Types of Technology providers:

● ISVs (Independent Software Vendors)● Technology Consultants/Technology Partners

SCENARIO

You are looking for an online donations tool. You would like the dtool to provide you with a giving page that lives on your website, take credit cards payments and ACH payments, and gather limited information on your donors, such as their name, address, phone number, and email address.

Decision: Build vs. Buy

BUY:

To go with a “Buy solution” is to identify that there are “ways” of doing “things” with technology that may or may not be part of a stand-alone product. AND

rather than building out individual pieces (ie, donation page, payment processing gateway, database to house donors) you would rather adjust your business

processes to match the product’s native functionality, or you utilize a pre-built customization or application that covers the gamut of what you anticipate

needing. Rather than focus on building out your needs piece by piece, you go with a total solution that includes some or all of the pieces.

BUY - The Pros● Comes pre- configured (it is an “OOTB” solution); ● Fits a wide range of clients because it is designed to fit most use cases;● Usually less expensive to setup and run (usually is a subscription model, or paid by

transaction)● Very quick to setup and go-live● Comes with a variety of out of the box reports (generally the ones most frequently

needed by the widest number of organizations)● Costs are known out of the gate

BUY - The Cons● Comes pre-configured, may allow little or no customization to fields or information gathered from

constituents;● Very rigid and inflexible, will only do what it is built to do, and generally is very good at that one thing;● Not scalable - generally will scale in number of donations easily, but won’t scale for process - ie, if you

wanted to start sending an e-newsletter to all your donors, you would need to export that list and take it out of your donor system to do so;

● Data may not be portable, especially if you cannot write your own reports; data may need to be exported by the vendor itself in order to move to another system if your organization outgrows the system

● May need still need assistance setting up more sophisticated products, and may still need to engage with a technology consultant (although starting with a product that is pre-built and engaging with a consultant to customize it will certainly be cheaper than building a product from scratch.

What if your scenario is more complex?

Now, let’s take our scenario, and move it 12 months down the road. You have purchased a product which accepts donations, sends out receipts, and captures basic donor information. It is working beautifully to capture those items, and now your marketing person wants in on the action -these donors should be mailed to and communications tracked! So you begin to explore other systems that may do that after you realize your donor management system will not... You implement a second OOTB product to manage your eblasts, but they don’t talk to one another, so reporting can be tedious as your organization grows.

What if your scenario is more complex?

And what about…

● Program staff tracking clients;● Volunteer sign ups and tracking;● Finance and forecasting;● Classes and registrations;● Event registrations...● The list goes on and can end in the dreaded DATA SILO

When Build makes more sense

BUILD:

To go with a “Build” solution is to build or customize pre-built products to match your organization’s business processes. In the build scenario, you scope a solution (with or without an implementation partner) and focus on building

out your needs piece by piece until the whole picture comes into view.

Advantages to Build● Generally there is a period of discovery where your builder (Consultant) determines which of your

organization’s staff need access to which information, and whether there is a need for a 360 degree view of constituents. After this discovery, they will usually recommend a product or more often an integrated suite of products to gather information into a central location;

● Your solution is customized to your organization’s needs;● Consultants generally have a wide variety of experiences with different types of organizations, and will

likely have a number of use cases to draw from in order to create your solution (ie, you’re benefiting from the work they’ve done with other organizations);

● Much less likely to end up with data silos and integrations are more likely to be implemented to avoid silos.

Disadvantages to Build● Cost is not entirely known: Usually these projects are estimated in a time and materials

fashion, and may go over the estimated cost; many times technology consultants also offer ongoing support options after the project is complete;

● Build projects take time, depending on how custom your project is;● Build projects may need ongoing maintenance from the builder (or someone on your

team with the expertise to maintain it)● Generally you can count on a minimum of 3 months with a build project, most ending up

around the 6-12 month mark.

Let’s Talk about Pricing Structure

BUY:● Usually either subscription (most frequent) or single purchase (usually these

products live on one computer and are not shareable)● Implementation and customization costs may be separate, but the costs are

known at the outset for the most part, if the ISV is providing both.

Let’s Talk about Pricing Structure

BUILD:Pricing is provided 3 different ways, depending on the consultant:

● hourly estimates (most frequent);● flat rate pricing (more expensive, but moves cost to the known); or● subscription (usually for things like support or coaching).

Let’s Talk about Pricing Structure

KNOW BEFORE YOU BUILD:● Hourly estimates are made for a best case scenario, and will list the estimated hours and

cost. DO NOT DEPEND ON THIS TO BE THE FINAL COST. Always budget for 25% over what the consultant estimated.

● Flat rate projects will have a higher cost than the same # of hours on an estimated project because the consultant is assuming the risk, and they will either charge more per hour, or estimate more hours so they don't lose money.

● Subscriptions are usually a monthly cost with a set number of hours and the price is known, unless you exceed the number of hours.

Deciding between Build and Buy: Do’s

● Figure out what your budget is and come in with a number - you’re much more likely to save time and get what you want and need when you know how much you can spend from the outset and you make that clear to the Build or Buy partner.

● Make a list of wants and needs from every stakeholder and prioritize them● Tell the Build or Buy partners you talk to all the priorities and how high they

rank● Don't be afraid to pay for discovery - money spent in discovery will save you

money on the project, as you will get a much more reliable and thorough estimate

Deciding between Build and Buy: Do’s● Create a Center of Excellence team represented by various stakeholders at your

organization to make the decision together and ensure everyone is being heard● Do share these important items with the build or buy partner:

○ Your budget○ About the org & stakeholders○ Regular language user stories○ 5 kpi's (key performance indicator) needed for each business unit the org will be solving for

● Do Account for the cost of adoption - this will be a learning curve and you will spend more time than you planned on it, regardless of which direction you go build vs. buy.

Deciding between Build and Buy: Don’ts

● Make your decision entirely based on today’s cost○ Consider the cost of maintaining silos○ Factor in staff time (it is not unlimited!)○ Consider costs AND NEEDS for the next 5 years when deciding

● Don’t… decide via RFPs and RFIs: these are a lose/lose

9 Reasons to ditch the RFP/RFI1. No matter how well written, an RFP cannot name all of the

requirements for your project - this translates into inaccuracy of estimate

2. RFP's waste loads of time3. Restricting your choices to only ones who have responded to an RFP

will result in a higher cost and fewer options 4. Reviewing responses to RFPs is not apples to apples5. RFPs don't encourage internal collaboration, they just take

requirements from those who are loud and available

9 Reasons to ditch the RFP/RFI6. RFPs are mostly written to replicate what you have and doesn't give

the consultant ability to come up with creative solutions7. Often all important stakeholders aren’t included in RFP writing8. RFP bypasses relationships and relationship is key9. RFPs are inherently political

Build vs. Buy Questions to Answer

Consideration #1: Does your organization understand the problem or challenge it is facing? Do you understand your current business processes and how those translate into your business needs?

Build vs. Buy Questions to Answer

Consideration #2: Does your organization have a Technology Road Map? If you are going with Buy, are you prepared to adhere to the processes and parameters of the product?

Build vs. Buy Questions to Answer

Consideration #3: Does your organization have the right in-house technical resources to embark on a self-implementation, support a product purchase, and become the expert for training, onboarding, maintenance, and upgrades?

BONUS Round: Questions for a Consultant

● Is this estimate a best case? What's the worst case? ● Will this estimate require me to purchase additional products or apps, or will all the

functionality be custom (products are cheaper over the long term, custom solutions will require expertise to maintain)

● Do you have support options after the project?● How do you train? Will or staff be experts at our own system after this? ● What types of organizations do you work with typically? Have you worked with an

organization like ours? ● Can I talk to staff members in the operations or delivery team (these are the folks who

will be interacting with you after the proposal is signed, it's important you like them, and they communicate well with you)

Final Tips● If the consultant works with for-profits, many offer a discount for nonprofits -

ask! If the consultant works only with nonprofits, it’s likely their pricing reflects this.

● Do they have any non consulting experience in nonprofits? (Ie, have they worked at a nonprofit)

● PRO-TIP! The person on your team most resistant to new technology should be part of these conversations and that person should have a voice and be listened to and spoken to by the consultant

● If you have a specific timeline, be up front! (A reasonable time line is 3 months to interview/ make a decision and sign a contract, 6-12 months for implementation, training, and adoption

Keep the Conversation Going...

Joni Bryan, 9Forty Coaching

www.940Coaching.com | joni@940coaching.com | 817.455.7347

THANKS!!!

Join us at our next session!

• Storytelling• Wednesday, June 30• 1:00pm-2:30pm

Chris McSwainCommunities Foundation

of Texas

Ben SkyeThe Storehouse of

Collin County

Cheri GarciaCornbread Hustle

Mona KafeelTexas Muslim Women’s

Foundation

Noelle LeVeauxCommunities Foundation

of Texas

for joining this Nonprofit Success Institute session!

THANK YOU