Beyond the RFP: How to Choose Technology Partners for Impact

Grants managers are adept problem solvers. We conduct equivalency determinations and set up expenditure responsibility reporting. We review wire transfer forms for the global distribution of financial resources. We are customer service experts working in multiple languages, usually with the help of Google Translate.

Upgrading and updating technology systems to keep up with the digital world are necessary evils. These migrations slow us down considerably and distract us from the high-risk compliance and risk-mitigation work primary to our grants manager job descriptions. Writing RFPs and managing technology migrations detract from grants managers’ ability to process grants.

I think this problem, RFPs vs. Impact, is solvable, but we need to explore new approaches to partnering with technologists who are responsible for contributing to the development, application, and advancement of social sector technologies.

What Is a System Migration?

A system or technology migration is the process of upgrading and updating technology systems to improve efficiency and effectiveness. It can involve moving data or software from one system to another, or from one operating environment to another.

A technology migration project typically involves several key steps, including defining a project scope, assessing the current tech stack and gathering requirements from across the organization, evaluating technology vendors and implementation partners, and ultimately planning, building, configuring, testing and training staff on the new system.

The specific steps and their order may vary depending on the project’s size and complexity. Additionally, effective communication, risk management, and stakeholder involvement are crucial throughout the entire migration process. It is foolhardy to expect one person or one department to oversee a project of this scale, and yet this is the trend I have witnessed in our sector.

Defining Scope and Required Functionality

The process of defining the project scope and gathering system requirements are often conflated. The scope is roughly defined by the directive to “find an adequate GMS upgrade that will result in parody, plus…” and then the requirements gathering work begins.

The grants manager asks supervisors, heads of departments, and senior staff what functionality they might need from a GMS upgrade. In the olden days, one of the first decisions we needed to make was cloud or server-based platforms. Now grants managers are expected to digest the minutiae of API integrations, currency exchange protocols, and language translation tools—for an entire organization and for their primary grants database.

Philanthropy’s primary administrative function is grantmaking. You might assume the migration to a new grants database would be a primary focus for the majority of the organization while the work is underway. This is not the case. Grants managers define a project scope (migrate tools, preserve data, tweak workflows), collect system requirements across the organization, and then they begin vetting technology and implementation partners to guide the technical aspects of the GMS migration journey ahead, which usually spans six to 18 months. Once requirements are collected, grants managers have traditionally been instructed to solicit Requests for Proposals (RFPs) from vendors.

And we have arrived at a chasm of disconnect.

The RFP Disconnect

An RFP should be a way to clearly communicate to potential vendors what you need for your next tech project. What are your project specifications? What is essential and what are nice-to-haves? What are your expectations overall? Sitting down to write an RFP is overwhelming. How do you convey what you need without writing a novel? How do you communicate what you need so potential vendors will understand, especially if you’re not a technical person?

Grants managers and philanthropy staff do not often speak the same language as technology vendors. The RFP is an attempt to bridge that chasm and elevate transparency. However, this approach is transactional and limiting in the over-emphasis on requirements and under-appreciation for the relationship-building, values alignment, and shared goals that accompany successful technology projects. How can we evolve as a sector, when we apply outdated knowledge sharing practices, especially around complicated topics like technology and data migrations?

Our sector is a close-knit community built on relationships that drive impact and not merely transactional resource exchanges. In the social sector, our values and organizational cultures matter. Technologists agree, the deliverables are easy, the technical requirements are achievable, and navigating the power and privilege inherent in philanthropy is where things get tricky. RFPs exacerbate power imbalances by prioritizing transactional information exchanges over deeper, and more impactful relationship-building practices.

RFPs are inadequate solutions to foster transparency and build a more inclusive sector. Ours is a sector built on values of trust, accessibility, and generosity. People transform ideas into reality. A set of shared values is a better starting point when aspiring to build new technology systems to support communities, stakeholders, and partners than a long list of technical requirements.

Reinventing Relationships between Grants Managers and Technologists

I recommend, in the interest of keeping our focus on generating impact, that we spend less time writing RFPs and more time nurturing relationships with social sector technology developers and implementers. We need to share our vision for how technology supports relationship building, cultivates deeper partnership with our grantees, and scales impact.

We need to clearly articulate our north star, why we are going there, and what support we need to make it happen. For example, instead of detailing the type of currency conversion functionality we desire as part of the RFP, we articulate our vision to send money to XYZ countries efficiently and securely and facilitate multi-currency reporting for various internal and external audiences. Through this approach, we explain to the vendor our expected outcome—smoother wire transfer workflows from the GMS—and how the functionality is expected to drive impact—clearer reporting for stakeholders. We need to be able to articulate WHY so that our technology vendor partners can help us determine HOW.

Developing Relationship-Based Practices

Answering why is more challenging than you might imagine. The answer is often, “Because we’ve always done it this way.” If you have had roaring success with your tech implementations, please do keep writing detailed technical requirements into your RFP.

Or you could try a different approach and double down on relationships instead of transaction, where your technology partners understand where your organization is going and how to most effectively and efficiently bring you technology to help you get there. Grants managers are adept problem solvers. Let’s take back the time we spend writing RFPs and generate impact by investing in relationships with partners and stakeholders.

The social sector is more than transactional exchanges and technologists chose this space because they also want to generate impact. Let’s find new practices that support transparency and efficiency. The aged solution of spending days writing an RFP is dead.

To explore these ideas further, check out our webinar, Down with RFPs: Bridging a Chasm, where you’ll learn about practical ways to reinvent technology vendor selection in service of relationship building and impact generation.