The Five Perils of Rushing Nonprofit Software Selections
Occasionally Build Consulting is contacted by a nonprofit organization that wants to do a software selection (and possibly also the subsequent implementation) in a rush. There are several factors that contribute to the reasons an organization might need an expedited timeline—some avoidable, and some not. But regardless of the factors driving the decision, it is important to know the perils of an expedited selection process, or risks may emerge. Building a better nonprofit software selection process can’t ignore that real time constraints often emerge. These five perils of rushing nonprofit software selections should help your organization avoid disastrous software decisions.
What Drives the Need to Quickly Select a System?
There are several factors that drive a rushed software selection. These include:
- To take advantage of funding that might not be available if there is a delay in the expense, such as with a time-limited grant or when approaching the end of an organization’s fiscal year.
- A pressing business opportunity has emerged that requires the organization to have a new system in place to perform the work properly—such as data gathering and analysis tools, or project management tools.
- A system currently in use by the organization will be discontinued in the very near term by its vendor. Generally, this produces a rush only when the organization has put off replacing the system until the last moment—but there are definitely occasions where a vendor goes belly-up and the nonprofit needs to move off that vendor-provided system quickly.
- An organization has a security breach with their current vendor-hosted system—and no longer trusts the current vendor to keep the system secure, or…
- The organization has a security breach with a self-hosted system (such as a file server or a web content management system), and wants to use this incident as an opportunity to move to a better solution (such as a cloud file management system or a managed CMS).
- An executive, board member, major donor, or other influencer is fed up with the perceived problems associated with the current system, and wants find a solution as quickly as possible.
Sometimes there is a good reason to rush the process, and sometimes there isn’t. An organization may see the benefits that might be achieved, but not clearly see the associated perils. Having a clear view of both may help to inform whether the reason for rushing is as good as originally perceived.
The Five Perils of Rushing Nonprofit Software Selections
There are several perils (or risks) that occur when attempting an expedited selection process. Those perils include:
Peril 1: Incomplete Business and Technical Requirements Assessments
Conducting a selection on an expedited timeframe means you may not be able to allocate an appropriate amount of time to developing the business and technical requirements that you share with vendors. In turn this means those vendors will not be responding to your full set of requirements. This can result in a complete implementation failure when it becomes clear that the selected system cannot meet your *full* requirements.
Real-life examples of this within the nonprofit space are abundant, in part because incomplete business and\or technical requirements are a leading cause of technology project failure—and can occur regardless of whether the process is conducted in a sprint or at a steady pace. Many organizations do not have the expertise or experience necessary to perform an adequate requirements gathering process. Add that lack of experience to an expedited timeframe, and you are compounding your risk.
Poor requirements may result in problems like:
- Inability to create needed reports … because the system does not provide the necessary relational data model
- Poor integration with another important system … leading to duplicative or inaccurate data
- Not being able to use the system at all … because it doesn’t meet a key security requirement
- Not being able to able to deliver a user experience that satisfies the system’s users … because users were not adequately included in developing requirements
- An insufficient number of the right level of user licenses and no budget for additional costs … because a complete count of users was not made
- Learning that you will need to implement additional system modules that the organization can’t afford … because miscommunications were made along the way about module functionality
- Selecting a vendor that has a good knowledge of their product, but insufficient knowledge of your nonprofit’s industry sector … leading to either a failed implementation or significant cost overruns.
Peril 2: Lack of Stakeholder Buy-in
Involving stakeholders in the requirements gathering and selection efforts takes time to do well. Compressing the timeframe for a software selection process can result in a lack of buy-in for the new system.
Technology change projects are inherently also organizational change projects.
It is important to acknowledge that implementing a new system may lead to policy, operations, processes, and data changes. If your team of stakeholders—which might range from an executive sponsor to front-line staff, or even volunteers—aren’t consulted during the selection stage, they may not be willing participants in the change that will be required to successfully implement the new systems.
It is worth noting that an organization could select the right software but still have the implementation fail because appropriate stakeholders never buy-in to the new product and process. Stakeholder engagement during the selection leads to stakeholder cheerleading during the implementation.
Peril 3: Increased Staff Turnover
Software implementations, particularly for systems broadly used inside an organization, are naturally stressful. They are stressful for those involved in the implementation team, because they usually require additional tasks (for example, participating in design, configuration, and testing meetings) in addition to their ordinary daily tasks. Implementations are also stressful for end users of the new system, who will need to learn how to perform their work in a software environment with which they aren’t familiar. Inevitably, the new process does not do everything the old process did, which is also stressful as users learn how to accomplish their job requirements in new ways.
These stresses may result in some staff turnover for those who aren’t willing or able to go through the change process with the organization. Rushing the software selection process increases the risk of staff stress and staff turnover. Adding additional stress by running an implementation hampered by poor requirements or lack of stakeholder buy-in within the selection process can increase staff turnover even further. If there is turnover at key positions important to the success of the project, such as losing your Director of Development in the middle of a fundraising CRM implementation, the implementation may grind to a halt or die altogether.
Peril 4: Damage to Constituent Relationships
These days technology drives the constituent experience like never before. This is true whether the constituent is engaging with the technology directly (e.g., when volunteering online) or indirectly (such as receiving a system-generated volunteering acknowledgement letter in the mail).
Let’s imagine that an organization rushes its volunteer management system selection, and ends up implementing a software product not well-suited to the needs of the organization. If this results in challenges with volunteer communications and scheduling, it will be damaging to relationships with volunteers.
Similarly, imagine that another organization rushes its association management system, resulting in a system that cannot properly calculate member renewal intervals and costs based on their membership tier and current status. If this results in members being charged at the wrong times, or for benefits not received, or being charged the wrong amount, or being sent an automated email saying their membership is about to expire when it actually is good for another six months—well, you get the idea.
Perhaps most concerning to nonprofit organizations is relationship building with donors that can be jeopardized by flawed fundraising software selection and implementation. Technology has revolutionized donor relationship management, but most of us have also probably experienced its dark side of sloppy or inaccurate communication from organizations we donate to.
In some way, every piece of technology used by an organization has the ability to increase or decrease the quality of constituent relationships. Software that helps increase operational efficiencies frees up resources that can be applied to initiatives that more directly contribute to mission fulfillment, improving constituent relationships. Software that bogs down operational processes and leeches time away from mission-related activities can weaken constituent engagement and damage the full potential in those relationships.
Peril 5: Damage to the Brand
Some software systems deliver the primary ways in which constituents engage with an organization. The clearest example of this is a website’s content management system—your web presence can be the most powerful presentation of your brand to the public. Another good example would be an online community where constituents engage to have conversations, receive services, etc.—these can be heavily branded environments.
For those types of systems, software selections that do not result in the right system, or in a successful implementation, can have a profound impact on the reputation of your brand. And in the case of a public website, you may never have an opportunity to know exactly who is turned off by that brand experience—and so it may not be possible to quantify the damage.
But there are other considerations. Imagine that as a result of a rushed software selection process, you selected a CRM system that didn’t have good enough security measures in place, resulting in a future data breach that damages the perception of your brand in the market.
This “damage to the brand” peril is strongly related to the “damage to constituent relationships” peril. Good relationships lead to constituents carrying a positive brand message out to the market, resulting in new relationships. Poor constituent relationships can do the opposite—decreasing your brand visibility and reputation.
So, What Can You Do to Avoid the Five Perils of Rushing Nonprofit Software Selections?
The perils of rushing software selections will vary in degree based on the software being selected and the qualities of the organization. Generally, the higher the complexity of the software selected, and the greater the change the new software will require from the organization, the greater the risks of moving too quickly.
It is important to understand the perils that may arise from rushing a software selection. As the saying goes, “Forewarned is forearmed.” If you work for an organization that is moving forward with a haste that seems unnecessary, this article may help you raise awareness of the attendant risks and build the case for a timeline that allows for a better approach.
But sometimes there are good (or at least unavoidable) reasons to rush a software selection. In that case, greater awareness may help risk mitigation planning.
- Can the organization give greater priority to immediate stakeholder time involvement, allowing for requirements development to be done quickly but effectively?
- Is there a way to quickly prequalify software options so the organization can focus on a deeper review of only two products rather than a cursory look at eight?
At the least, risk mitigation might include simply getting everyone associated with the project together in a meeting, to talk clearly about the opportunity that is driving the rushed process as well as the risks that go along with it. You might be able to gain agreement that the organization is doing the right and necessary thing, and that you have measures in place to mitigate the risk, or that the outcome is worth the added risks!
Self-awareness and transparency go a long way towards building good will for initiatives that carry risk. Forwarned is forearmed—knowing that a rushed technology project is unavoidable, multiple check-ins can be scheduled to mitigate these and other anticipated failure points as they arise.
- Can more intensity be put into the technical specifications gathering, because of the short timeline?
- Can a project manager be assigned specifically to increase stakeholder involvement, because this risk is fundamental to failure or success?
- Is everyone involved getting the time and (financial) incentives to prioritize the project selection and implementation and is their “regular” work being managed to allow them time to participate? Is the project creating unmanageable stress on managers, users, and other stakeholders? How are the human needs of staff being met during this high-speed project? How will participants be rewarded for success?
- Is the impact of the tech project on constituent relationships being fully accounted for?
- Is minimizing risks to the organization brand being prioritized?
Need more expertise?
Even—especially—quick nonprofit technology projects need assessment and implementation support to put them on the path to success. Whether you need a trusted partner who knows the vendor landscape thoroughly to save you time in researching your options, or a software selections consultant to help translate nonprofit requirements to vendor-speak and vice versa, Build has the expertise to help.
Build’s team knows nonprofit operations and technology (including CRM and ERP systems), we know the software vendor landscape, and we are experts in change management. We combine deep nonprofit experience with a set of information strategy best practices, to provide you with all the qualities you need in a strategic nonprofit technology advisor. Let’s talk!