Lea Remigio

This is a follow-up post to Foundation-funded Technical Assistance Projects from September 17th. That post was mostly about why nonprofit social service organizations need technical assistance from their foundation funders. At the end of it, I heedlessly promised to write about some of my ideas for what a foundation can do to help their grantees embrace technical assistance projects in a meaningful way. So, I’m back with this.

Some examples of technical assistance projects can be found in the previous post, but for this post, I’ll try and use a single example of a technical assistance project: A foundation-funded software training project. You can use your own imagination and decide what type of software it is – MS Word, a case management system, a contact management system, Excel, and online donations platform, Worpress(!), etc, but the idea is that the foundation would fund a professional software trainer to go on-site and provide training to grantee staff on whatever software package you’re imagining right now. Whatever the software is, it’s something that’s already commonly used (or something that you want them to start using) at each of the participating grantee organizations.

Now that the project example is out there, here are the ways I came up with that the foundation can ensure their technical assistance project dollars are well-spent. I came up with three categories, which all start with C. The C categories were a coincidence at first, but then I got carried away. (How’s that for cohesive construction?) Continuing on….

Conditions

Treat your technical assistance project similar to a grant. Or exactly like a grant. Require a small financial buy-in from the grantee. With technology more than other substantive areas of business, people have a tendency to value something they have invested in. (“If it’s free, it can’t be worthwhile” is not, by the way, a concept I subscribe to. There are a lot of really great software applications out there that are free or free-to-nonprofits.) Your technical assistance project should not be completely free.

If you absolutely cannot or will not require leveraged funding for the project, require the grantee to provide some other type of buy-in, which brings me to the next obvious condition – staffing. I’ve already written about the need for grantees to dedicate resources, so I’ll squelch my harping on that topic now. But I really want to harp on it some more. Suffice to say, the best way to ensure dedicated grantee resources is to require them under the terms of the grant.

Place a timeline on the project. Following my software training example, set a firm deadline for when the grantee programs must show evidence of coordinating training dates for their staff. Set another deadline for when the training must be completed. Send an end user survey out after that final date to get direct trainee feedback.

Tie some grant reporting outcomes to the program’s use of the software. This is sort of like a final exam, but sneakier. For example, if you provided advanced MS Excel training through a technical assistance project this year, require submission of a specifically formatted pivot table as part of your Children’s Grant year-end reporting. This grant condition is also a great idea if your TA project was for subsidizing or purchasing software licenses in bulk.

Communications

Spend some time strategizing and defining the terms of the technical assistance project. Then clearly and consistently communicate those terms to the grantees/potential participants in the project.

Seems pretty obvious, right? It does, but it’s possible for a great strategic foundation to skimp on the strategy and planning when it comes to technology projects. I’ve seen perfectly reasonable, educated and strategic thinkers glaze over in the eyes when presented with the technical details necessary for planning a TA project. They recognize the need (or can be convinced of a need by others who recognize it) but don’t want to be involved in the details. (“Why are you needlessly complicating this, Lea?”) But the details are necessary. To be fair, most of the perfectly reasonable, educated, strategic technophobes I’ve worked with were willing to consult with people who could help them plan and communicate the details of the project. Remain a technophobe if you must, but keep your like-minded and reliable geeks close at hand.

After you’ve defined the project and communicated, don’t forget to sell it. Promote the potential benefits, both immediate and long-term to get buy-in from the leaders of the participating organizations.

• The new software knowledge gained from the training could give program directors some tools to increase operational efficiency. Maybe that administrative assistant can stop typing envelope labels one at a time and use the MS Word mail merge feature instead. Or maybe you can use that fancy new case management system to email correspondence to your clients instead of hassling with the mail service.
• Program staff members who will learn to use a new piece of software will have that skill to add to their resume and can take that with them as their careers advance. Most non-profit are not able to offer high salaries, so consider new technology training a career development perk. The younger employees who grew up using computers will especially benefit from this.
• If your grantees are clustered by state or region, solid software training on a shared platform can produce a user group that can easily transition from one grantee organization to another. An example of this is the legal aid organizations in Florida. 27 out of 30 of them all use the same case management system solution. Attorneys frequently move, ending employment at one legal services organization in Florida to go to another. The attorneys can come to their new employer already knowing the case management system, requiring less training and handling more cases than they would be able to with an unfamiliar software. They may also spread “best practice” ideas from one organization to another.

Connections

Most of these could probably be lumped under the Conditions section of this post, but I needed a third C to make the concept catchier.

Consider how you can use the technical assistance project to bring the participants together and foster a more cohesive network of providers. Some groups may do that naturally. For those who need some encouragement, here are a few ideas.

• After the technical assistance project is completed, bring the participants together to share with their peers how they utilized the assistance. Take a half hour or an hour of time at a regularly scheduled meeting to have the grantee leaders explain their good ideas for how to use the software they were just trained on.  Give them donuts and coffee. People like donuts.
• Promote inter-agency collaborative work on the technical assistance project. Allow me to stray from my simple software training TA example for this one. Implementing a web-based client intake system could be an excellent opportunity to share staff or website resources for such a project. Participating programs would have to work together to determine client eligibility and referral rules, among other things, which is a great way to avoid gaps in your service network. As the funder, reward collaboration appropriately with additional money or resources. Make an example out of the grantees who play nice together. Play favorites with the high performers.

And this one is such a radical collaboration concept that I’m introducing it with its own sentence.

• Examine how much a role the grantees themselves might be able to play in the grant making process. RSF Social Finance calls this Shared Gifting. And I think it’s a really cool idea for increasing cohesion and collaboration among a group of nonprofit social service organizations that share a funder and have similar missions. And here’s the part where I heedlessly promise to write about the concept of “shared gifting” in a future post.

Last but not least, consider including your own foundation staff in the technical assistance project. For many foundations, the grantee technology is better than their own. Sometimes this is justifiable, but at some point, it can get a little embarrassing.