When Build Consulting is contacted by a nonprofit organization that wants to do a software selection in a rush we always want to better understand the urgency.

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.
• 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.

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 all your organization’s 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.

Peril 3: Increased Staff Turnover

Software implementations can be naturally stressful. They are stressful for those involved in the implementation team, because they usually require additional tasks like, participating in design, configuration, and testing meetings on top of 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 fail altogether.

Peril 4: Damage to Constituent Relationships

These days technology drives constituent experiences like never before. This is true whether the constituent is engaging with the technology directly (e.g., when volunteering online) or indirectly (e.g., such as receiving a system-generated volunteering email).

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.

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. 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. 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.

Forewarned 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 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 and experience to help.