Cloud for Good
Search
Close this search box.

An Interview with BWF on the Value of the RFP Process

Conducting formalized purchasing processes represents an essential aspect of any business seeking to maximize return on investments and improve organizational outcomes.  Request for proposals, or RFPs, help define projects, set expectations, and ensure the right clients and/or vendors are selected to help businesses grow effectively and efficiently.  Cloud for Good recently sat down with BWF’s Jason Boley, Senior Vice President of Systems and Operations, to discuss the value and best processes of the RFP process.  BWF is a complete fundraising consulting firm employing consultants with extensive expertise in every facet of philanthropy, a base Salesforce.org partner, and a trusted partner of Cloud for Good’s.  

What is the overall value of going through an RFP selection process?  

Jason Boley (JB): Our experience with clients and vendors is that going through a structured selection process better prepares the organization for a project quote by defining the scope of work, outlining the technology ecosystem of the organization, and identifying potential barriers to success. Clarifying these items beforehand will result in a more accurate response about scope, timeline, and cost. An RFP selection process often leads to better outcomes for our clients and more transparent working relationships with the vendors.   

When is the appropriate time for business requirements gathering and what does that involve?  

JB: We generally recommend that organizations focus on high-level requirements gathering before authoring and issuing the RFP to more fully define the project. Specific process mapping is usually integrated into the implementation process once a vendor has been selected. An exception to this would be if any unique or problematic processes that are identified that may impact the system selection process. Diving deeper into these in advance can sometimes inform and refine the overall scope of work required.   

What is the difference between business requirements gathering and business process mapping?  

JB: Business requirements gathering is a high-level review of the organization’s technology ecosystem and identifies current limitations and desired future-state functionality. Business process mapping involves performing a “deep dive” into a specific business process. Doing so creates a workflow map of that current process, which is then used to design the process in the new system and identify necessary changes to improve efficiencies. Business process mapping is essential when transitioning from a server-based software platform to a cloud-based development platform. This is a key time to assess and improve processes that meet the goals and preferred workflows of your organization.    

What is the difference between an implementation partner and an ISV partner?  

JB: An ISV partner, or Independent Software Vendor, typically focuses on installing and configuring a technical solution for the organization. Their success is usually defined by having the software operational, the data converted and moving the client to long-term maintenance. An implementation partner typically operates as augmented staff to the organization and assists with strategic direction and project oversight. An implementation partner tries to advance the business process of the organization by assisting in re-envisioning how the organization does its work. The worst thing that can happen in an implementation is that it simply mirrors the processes of the old system.  

What is temporary project staffing and why might that be needed?  

JB: Many organizations are already resource-constrained in terms of staff and budget and don’t always realize the time and mind space requirements of a CRM selection and implementation. Temporary project staffing can fill a variety of needs and is typically borne out of the organization’s biggest gaps, which in many cases can be a lack of staff. This staffing solution can range from full-time to part-time staff augmentation.   

When does the planning phase end?  Who are the right stakeholders and at what point should they be involved in the selection process?  

JB: There are generally two types of planning. First, planning to purchase and move to a new Constituent Relationship Management (CRM) system. Second, planning for the successful implementation of the product chosen. You can never really plan too much but must also recognize that you cannot plan for everything. The first phase is focused on more broad-based planning that defines need, resources, timeline, and appropriate technology. We often recommend that a broad group of stakeholders participate in phase one; this should include leadership, division leaders, and a broad spectrum of people with a vested interest in the outcome. Including the opinions of key team members and leaders will be essential for long-term dividends. The second phase is more focused and concentrates planning on migrating specific business processes, testing, launching, and change management. The migration phase must involve leadership sponsorship but will more heavily involve technical resources and business process subject-matter experts to guide the technical transition. 

Why is it important in the Salesforce ecosystem to perform a needs assessment upfront?  

JB: Salesforce is not a defined software solution; it is a development platform. Select ISV partners have developed customized versions of Salesforce that work in different ways that seek to solve the unique business needs of fundraising organizations (e.g., gift processing). Salesforce is very much about building a patchwork of best-of-breed “apps” designed for specific business processes to design a holistic solution. The result makes projects more complicated to scope and price than what most fundraising organizations have experienced historically, as there is not a single vendor proposing a one-size-fits-all solution.  

Once the RFP is issued, are there best practices around vendor engagement?    

JB: Most RFPs have a structured response process that is mediated by a procurement office to treat all respondents fairly. It is critical to outline dates clearly and to accommodate a period in which vendors can ask questions of the RFP issuer and have time to respond appropriately. RFPs with tight turnaround times may result in rushed responses or no response at all. An RFP is only part of the process; organizations will have additional opportunities to engage vendors during demonstrations and follow-up discussions.  

Could you speak on the difference between buying software and buying a development platform?  

JB: Historically, vendors have offered fundraising software solutions that function in a specific way and have offered little flexibility. The functionality either met the organization’s needs or did not, and the organization would adapt their processes to the software. Modern development platforms have upended this paradigm by allowing organizations to design systems interfaces, add fields, and even design complex business processes. The result is a more customized and dynamic experience, but it can result in increasing the complexity of system projects if organizations are not adequately prepared for this change.  

What factors or red flags would contribute to a company declining to be involved in an RFP process?  

JB: In general, organizations would prefer to have several RFP responses from which to choose. Developing a concise and clear RFP that encourages a vendor response and has reasonable deadlines goes a long way to encouraging responses. At the same time, organizations can do homework ahead of time to target platforms that most likely fit their needs. For organizations that are strictly “shopping” for systems, they might consider a lighter request-for-information (RFI) document that precedes an RFP to ensure that the RFI submitter and the responders to it become familiar with each other thereby increasing the likelihood of a response to the formal RFP. An RFI is easier to respond to and allows vendors more freedom in their response than would occur in a structured RFP process.  

At BWF, Jason Boley’s areas of responsibility are information technology assessments and strategic planning, enterprise reporting, business process assessments, and data flow and integration analysis. The many clients he’s served have accomplished their goals through his work on departmental and staffing assessments, CRM evaluation, selection and integration, enterprise reporting strategy and metrics definition, and industry benchmarking projects. 

You May Also Enjoy: