Tips for Choosing Enterprise Software

By Vaidehi Agarwalla 🔸, Domi_Krupocin @ 2021-04-09T13:37 (+42)

Authors: Dominika Krupocin and Vaidehi Agarwalla

As the Effective Altruism (EA) movement and EA organizations grow, there is an increasing need to implement various enterprise software to improve the organizational efficiency. Identifying and selecting the right product is difficult to navigate for those without prior experience. This post aims to help operations staff develop good strategy and tips to approach software evaluation and implementation.

Key Takeaways

• Enterprise software is an investment and there are high switching costs. (Read More)
• You need to figure out if you need new software, and how pressing the need is. (Read More)
• If you’re not ready to switch, try experimenting with cheaper solutions. (Read More)
• Invest time in gathering detailed requirements from your team before evaluation. (Read More)
• Prepare your team for the transition - develop a strong vision for why you need the change, and communicate well. (Read More)
• When vetting a company, it’s useful to get referrals, and invest time engaging with the company. Keep in mind hidden costs from customization and limitations, ask lots of questions and ask for an NGO discount. (Read More)
• It is usually better to buy software instead of developing your own. (Read More)
• You can sometimes do implementation yourself, but for important implementations we recommend playing it safe and getting it done professionally. (Read More)
• When arranging training, communicate your training plans clearly, make onboarding easy and ensure you fully transition to the new system. (Read More)

This post may be less useful for the average EA Group where a simple CRM solution like Airtable will suffice for most purposes.

0.0 How to think about enterprise software

• Software is an investment: Having a professional software allows for building and strengthening organizational infrastructure and capacity.
• There are high switching costs: Enterprise software implementation can cost a lot of money, time, effort, and energy. If you do not think through the choice, It's going to be much harder to shift your team to use a different software down the line. It’s best to "measure twice, cut once".

1.0 When to make the switch

1.1 Figure out if you actually need the software, and if you need it now

It may be tempting to try and optimize and get the perfect software in the first instance, but you will need to make sure a lot of things are in place first:

• Is your team happy with the existing system? If they are, it’s going to be much harder to switch over to something new. If you’re met with a lot of resistance but feel your team could really benefit from a new system, it may be worth discussing with them their reasons rather than just trying to get people onboard with a new system. For example, you could try doing a "team systems audit" where each team member anonymously submit 3-5 issues they have with the current systems. If team members can see the reason why they need a new system, they can be more  self-motivated to actually get on-board with the search for a new system.
• What are your top pain points and bottlenecks? Where are the gaps? What are the organizational needs and challenges faced? Answering these questions will help narrow down the type of software (or softwares) you may need. For example:
  • Are you having trouble with staff allocation? Look for a Project Management software.
  • Do you need a system that will help you manage your donors/ funders/ clients? Try a CRM.
  • Do you need a solution that will help you store and track certain information? Maybe you need a better database.
  • Do you need a task planner to help you manage your day-to-day tasks? Try to find a good Task Manager.
• How established and documented are your operations? If your operations are very fluid, not well-defined or documented, it may be difficult to find a software that meets your needs, because you haven’t defined what they are.
• What is your budget?
• Do you (and your team) have the time to invest in vetting, implementation, and training processes?
• How urgent is your problem?
• How expensive and time consuming is it to maintain current processes as they are?
• Implementation and training (see sections 2.4 and 3.0) can be a long and tedious process. It may make sense to leverage your current software until you are ready to move forward with the process of finding a new solution, and/or until the current software becomes too burdensome for you and your team to maintain.
  • No software is perfect, and new tools may present challenges you don’t face in your current system.
  • If the improvement in a new software over your previous software is not substantial, it may not be worth investing in a new software (yet).

1.2 What to do if you aren’t ready to invest yet?

If you are not ready to implement a new software, don’t worry! Change takes time and you can use this time to better understand your organization’s needs, strengthen your current operations, and better organize your data.

• Understand your organization’s needs: Talk to your staff to understand what challenges they face, if any. There is a lot of literature on needs analysis that may provide useful methods and best practices.
• Improve your operations with simple solutions: Sometimes companies invest in cheaper, imperfect solutions because the gains are enough that it justifies the investment costs and avoids expensive switching costs.
  • Try more affordable or free solutions, such as Airtable, Notion, Smartsheet, MS Project, Basecamp or Google Spreadsheets to add additional efficiency to your current processes, or to test different options  out.
  • You may find that these changes do not make a big difference in your current operations. Or you may find that they make your work much easier. Either way, this will allow you to re-evaluate your needs and determine the  importance/urgency of implementing a new software.
• Organize your data: Regardless of what your current processes look like, how you collect data, and track information, make sure that you’re investing time in keeping it well-organized and clean. This way it will be easy to export that data into a new system when the time comes. Trust us, it’ll be worth it!

2.0 How to choose and adopt a new software

2.1 Requirements gathering: Know exactly what you want

• Start with documenting your current processes into [standard operating procedures](https://en.wikipedia.org/wiki/Standard_operating_procedure#:~:text=A standard operating procedure (SOP,to comply with industry regulations.) (SOPs) in (a lot) detail.
  • Proper documentation is critical for any internal transition and ensures continuity.
• Engage with all internal stakeholders to understand their needs and pain points.
• Identify the top must-have and nice-to-have features and make sure you know exactly what you want.
• Think about features you’ll likely need in the next 2-3 years. What operational processes do you expect to implement or change?
• Be very explicit on the kinds of integrations you want. If you see a system that says "integrates to QuickBooks" don't just take it at face value. For example, think about what you want it to do compared to what that integration actually does? Is it a one-way or two-ways integration? Are there any implementation and/or ongoing costs for this integration?
• Keep your most important stakeholders (your team!) in mind - look for software that is:
  • User friendly: Software that has simple features and provides an easy user experience. The more complicated and cumbersome the software is to learn, the less inclined your team members will be to use it, which will make your life much harder. Software that is more configurable (e.g. allowing people to modify screens to suit their needs) may help your team in the transition process.
  • Collaborative (if you need it): Make sure you can easily tag different people, share documents easily, have multiple people comment on one project, etc.
  • Simple: The software should be easily managed by your least technical team members and not require any technical knowledge of familiarity.
• Consider exit costs: If you choose to switch softwares in 2 years, what would the transition process look like?

2.2 Prepare your team members for change

Bringing about a new change in an organization is challenging for many reasons. One of the most crucial aspects of leading the change is the buy-in from staff. No transformation can be successful if the idea is not supported by other employees - how do you gain support from your coworkers?^[1]

• Develop a strong vision and communicate it: Visions play a central role in producing any change (including implementing a new software) by guiding, aligning, and inspiring actions amongst individuals.
• Establish a sense of urgency: When complacency levels are high, it is difficult to achieve objectives; provide strong and convincing arguments as to why there is a need to implement a new software.
• Convene a guiding committee: Engage your team in the vetting process so that they can try out new software; additionally, having an active group of supporters who feel invested in the search process and are committed to making a change is a powerful and necessary component of any transformation.
• Demonstrate the benefits of the change: Show your team members how the change addresses their key bottlenecks and struggles.

Some common mistakes during overhaul:^[2]

• Relying on a champion: Don’t be overly reliant on one person who is in charge of the whole change.
• Losing momentum: However, having no team leader at all can be an opposite problem and cause the team and project to lose momentum.
• Haphazard approach: Focusing on "the issue of the day" rather than long-term goals.
• Going at it alone: Try to adapt resources from other organisations rather than reinventing the wheel.

2.3 Vetting

• Understand the time commitment: Software searches will take time. To find the right solution for your organization, plan ahead - you need to earmark time to invest in vetting companies & softwares. It took on EA organisation about 12 months from the initial exploration to Phase 1 implementation of their CRM. Industry average for ERP implementations are around 21-24 months.
• Get referrals and recommendations: Start by asking other organizations and/or individuals who have experience with a particular enterprise system for recommendations. Don’t forget to inquire about their vetting process, functionality, lessons learned, and challenges faced while implementing and adopting a new software.
• Does the company (or implementation partner) ask for your detailed requirements? A good company will ask you for details before jumping to a solution, especially if they are building a custom product. If they don’t, that’s a red flag. (These discovery sessions are billable).
• **Be proactive about sharing your detailed requirements and ask lots of questions: **
  • It’s best to share your detailed requirements with the software company and ask them to clearly state which features are available, and how they can be utilized on a day-to-day basis to meet your needs. Make sure you know which features are missing that you need, and how likely they would be implemented in the near future.
  • When in doubt, get on a call with a tech person to ask them about the commercial details. You can also try to schedule a call with an implementation partner, product engineer, or other person to get more specific answers.
  • Request a demo to see the functionality in real-time and ask about a free trial - playing around will give you the best idea about the user experience and functionality. If a company doesn’t offer any of that, it’s a red flag.
• Test before committing: Try out a few software options with a small team to see which one suits your needs the best.

2.3.1 Budgeting

Be wary of hidden costs: In general, keep in mind that there may be hidden costs or cost overruns. An EA operations staff was quoted approximately $10,000 for implementing a solution, but later found the sales rep neglected to mention there would be a separate ongoing cost for the software itself. Further, take estimates provided by the companies as a lower bound, and make sure you’re willing and able to go above the quoted estimates. For example, one EA organisation was quoted 30 hours for requirement gathering, but ended up being billed for 60 hours.

Always ask for an NGO discount: A lot of companies offer one!

Below we go over the common cost buckets and some notes on each.

• Implementation costs: Implementation is the cost of setting up the software. This is usually a one-time cost. If your needs or the software is simple, there may be minimal implementation costs. However, for more advanced software, implementation costs can be quite high. It may be worth investing time to see if there are ways to configure the software on your own if the software is a good fit for your needs and if you have the right staff to work on that. It may be safer to go with the professionals if you feel you don’t have the time or expertise to figure out how to properly set up your software platform.
• Training costs: There will be time costs to onboarding any new users and possibly monetary costs if you need to involve your training partner. Be sure to factor that into your cost estimates - if the software should be easier to onboard new people to than your previous software, this is a plus. To minimize future training costs, make sure training sessions are recorded sessions for future employees.
• Ongoing costs: Ongoing costs are usually monthly or yearly licensing and maintenance costs.  Always ask for nonprofit discounts if this applies to you.
• Customization costs: Customization can be attractive if the software you’re looking at is missing a few key features that might make your operations smoother. However, software customization can increase your implementation and ongoing costs, and your overall overhead as well. We think it’s better to avoid customization where possible.
• Integration costs: If your software integrates with other platforms, you need to include costs of these platforms in your estimates, as well as the cost of integration if it is not included in the base package, or is customized.

2.3.2 Buying vs. developing your own software

Should you purchase or develop your own software? Is it better to purchase a software or build something in house, especially if you have access to talented programmers/software engineers?

With inhouse development, there are important questions about sustainability to consider:

• Who is going to be maintaining the inhouse system on an ongoing basis?
• Who will be providing technical support?
• What about updating the software, and/or potential integrations with other tools?
• What happens if your system developer leaves the organization?
• What about if the organization grows/downsizes? How will this platform be adaptable to change?
• Who will provide training to staff?
• What are the costs of all of the above and time commitment? (This is VERY important)

Generally, it is not a good idea to have a system that is dependent on one person only, unless your staff are developers/ technical people themselves. If there aren’t good answers to all of the above for developing your own solution, you may want to consider purchasing a software rather than developing a new system inhouse.

Sometimes, you may get offers from (well-meaning) volunteers or programs to help you build out a certain feature or website functionality. These offers are even less likely to be a good idea than developing something in house, because volunteer efforts can be less reliable.

One EA organisation had a bootcamp rebuild their website for free but it came with lots of bugs and typos built into the code, and they were unable to add new pages. Since the organization didn’t have access to volunteer developers, it took them a team ~100 hours to fix things. This remained the issue for a year, until they found a volunteer to fix it for them.

2.4 Implementation

After you’ve identified and purchased a new software it’s time to start the implementation process. It may take a few days to several months depending on the complexity of the software, data migration, integrations, and other factors. You can reduce implementation time and costs by doing the implementation yourself for some softwares. However, if you’re not confident and the data is sensitive (e.g. financial data) it’s worth having an expert implementation team do the actual migration. In those cases you can save time and costs by doing the prep work in advance, yourself.

3.0 Training

Once you’ve chosen and vetted a software, you now need to get everyone on your team to actually use it, if even one person doesn’t use the system, this will greatly increase your work.

3.1 Communicate the training plan clearly

Make sure your team members are aware of:

• The time they need to invest in the onboarding process: Although you should try your best to minimize the time needed to be onboarded (see below), it’s important that people know how much time they will need to invest. One organisation has found it useful for high-priority but low-urgency tasks like training,  to set up a coworking time for the team to do the training together.
• The hard deadline for the transition: By setting a hard deadline, you create a sense of urgency around the transition.
• How the training will happen: Will you send written instructions, have live training, or have the team watch pre-recorded videos?
• Give your team the opportunity to discuss the training plan or raise any concerns with you.

3.2 Make onboarding easy

Write concise instructions & document your norms: Even if you think the software's user guide is very good, it's likely you can make them more concise because your instructions are for your organization's specific use case. And doing this upfront, from the get-go is key to save your team (but mainly you) lots of time in the future.

Generate short-term wins: Implementation is a complex and time-consuming process - establishing short-term goals to work towards are great motivation and demonstrate commitment to the process.

Be helpful and accessible: People have a tendency to put off a task if they can’t figure it out - if there’s a way to disincentive or nudge people away from this, and towards directing problems to a trouble shooter, you could save your teammates hours.

• Block regular office hours (or make yourself available in other ways) so that individuals know that they have a dedicated person to go to.
• Proactively follow-up with your staff to gather feedback and make sure everyone feels comfortable on the new system. You can also use this feedback to develop an FAQ for everyone.

3.2 Ensure you fully transition to the new software

If you’ve prepared your team in advance, there will hopefully be less resistance to the new system. However, be ready for people to keep trying to use the old system. Don't give up, don't resign yourself to the two-system world. It will take time for everyone to accept the change and get used to the new software, but with your help and joint effort, your team will succeed. Seize opportunities to walk someone through a concrete example - maybe your team member hasn’t set up their new software account yet, but need to complete a related task. It can be an excellent opportunity to encourage them to do that through the new software.

Need help? Reach out!

If you'd like to chat about the above, reach out! Dominika works for Operations at Rethink Priorities and has experience implementing different kinds of enterprise systems in her previous work, and Vaidehi has experience as a software consultant and currently works for an ERP software company. We may not know the best solution to your specific needs, but hopefully we can help you figure out how to make the decision and walk you through the process.

If you have expertise in enterprise software (especially CRM/ERP/PM software), your time could be very valuable for EA organisations looking to make a switch. Consider offering your time on the EA Hub.

Thanks to Marisa Jurczyk for suggestions, Martin and Sawyer for their insights on the Operations AMA post and Kathryn Mecrow-Flynn for reviewing this post.