10 Questions Your Nonprofit’s Technology Roadmap Should Answer

Many nonprofits first come to Build Consulting because they want a better technology roadmap for their organization. This article will help you think about what your nonprofit’s technology roadmap should include. These are positive ingredients that should be in the mix if you want a successful roadmap. If you have questions about what your nonprofit’s technology roadmap should address, start with this article!

But first, what is a technology roadmap?

“Technology roadmap” is not the term used at all nonprofit organizations. Elsewhere, this term might be replaced with “IT (or Information Technology) Roadmap,” “IT Strategy,” “IT Plan,” “Information Systems Strategy,” “Data Management Strategy or Plan,” “IT Audit and Recommendations,” “Information Strategy,” “Business Systems Strategy,” or another term.

Every organization has a slightly different view of technology and its role within their organization, and to some extent that view is indicated by what they call the guiding document that informs how they use technology at their organization.

But what every organization needs is effectively a “roadmap”—a strategic plan that identifies:

1. Where do we currently stand?
2. Where do we want to go?
3. Why do we need to go there?
4. How do we plan to get there?
5. What will be our travel costs?
6. Who will need to make the trip?
7. What level of effort will be required for travelers?
8. What roadblocks might we encounter?
9. How long until we get there?
10. When can we have a snack?

Each of these questions is addressed in the sections below.

Why do nonprofits want a better roadmap?

What drives the need for a “better technology roadmap” varies from one organization to another. Some drivers include:

• “We need to replace [major system X: CRM, ERP, etc.] and it is important we do it in a thoughtful way that takes the needs of the entire organization into consideration.”
• “We’ve never had a technology roadmap before, and we want to make sure our organization is on the same page in terms of what tech we need and how we are going to pay for it.”
• “Our technology roadmap has been very ‘IT-focused’ in the past – mostly concentrating on network and hardware. We need a roadmap that includes our business/data systems (software).”
• “We want to move from a reactive approach to a proactive approach to technology—from ‘break/fix’ to ‘strategic/planned.’”
• “Our organization thinks about information systems in silos (very department or program-oriented). We want to start thinking strategically, across departments and programs, about what is best for our organization.”
• “We have a lot of inefficient or manual processes that need to be rethought and better supported by technology.”

There are many other reasons why an organization might need or want a new roadmap, of course, but those are some of the primary ones we at Build hear from new clients.

And Now: 10 Questions Your Nonprofit Technology Roadmap Should Answer

1. Where do we currently stand?

Your roadmap needs to include a realistic assessment of where your organization currently stands—what it currently has, and how well that serves the organization.

Because ultimately technology is used by people managing processes—and because technology is so fundamental to how we live and work in the modern era—this assessment should take a comprehensive view. It should include leadership and governance, operational capacity, business process, data, and technology—the five pillars of Build’s Information Strategy Framework. If you don’t consider all five of those areas effectively, you run a much greater risk of future technology projects not producing the intended results.

The description of where the organization stands, or its “current state”—must be understood and agreed to as reasonably accurate by all stakeholders that will be engaged in moving towards the eventual goals determined for the roadmap. If one or more important voices within the organization do not agree with the assessment of the current state—perhaps a disagreement about the severity of certain perceived gaps or shortcomings, or even a disagreement about what should or should not be included in the assessment—inevitably you will not be walking the same path as an organization, because you will not be starting from the same point.

2. Where do we want to go?

Defining where you want to go with technology at your nonprofit can be difficult if you think about it purely in technical terms. Therefore, you shouldn’t first think about where you want to go, or “the future state” in terms of specific technology systems (or even system categories, like CRM or ERP) and features.

Rather, the destination for your roadmap should focus on business outcomes you want to achieve: what your organization will look like in the future, and what it will be able to do better or differently at that time.

Ultimately, what all nonprofits want to do is increase their mission effectiveness—so at the highest level, any technology roadmap should be closely tied to the mission, vision, and strategic goals of the organization. But we encourage organizations to express more clearly the 3-5 top business goals that they would like to achieve through improved use of technology, typically over a three-year timespan.

Examples of these top business goals might include:

• Engage more deeply with constituents so as to increase the impact of our mission.
• Increase the amount of revenue the organization receives from major donors.
• Reduce the guesswork in financial budgeting and forecasting.
• Better understand the skillsets of our staff (or volunteers).
• Help our members feel a greater part of our community.

Again, consensus is key. A particular department or program might have a perceived technology need that likely won’t be addressed in the early stages of the roadmap if that need doesn’t align to the highest business goals (strategic imperatives)—or due to limited resources, might not be budgeted into the roadmap execution at all. In these cases, leadership will need to be aligned as to what is most important, and hold to that message throughout the duration of the roadmap—or until the priorities shift due to changes in the landscape.

3. Why do we need to go there?

Stating where you are, where you want to go, and how you want to get there doesn’t necessarily give you why you need to go there.

You need clear and compelling reasons to help stakeholders within the organization understand why it is important they take the necessary steps to arrive at the destination. When stakeholders have this shared understanding across the group, they are more likely to keep their legs moving if the terrain gets difficult.

Typically, organizations define their reasons for change in a mix of “pain to reward” or “challenge to opportunity.”

• Example 1:
  • We are currently not offering competitive salary to case workers. This results in high turnover. (Pain/Challenge)
  • Increasing funding from major donors will help us to pay more competitive wages and decrease turnover, leading to greater quality of life for staff and improved impact for our clients. (Reward/Opportunity)
• Example 2:
  • Recent benchmarking for our fundraising strategy indicates we can increase revenue by 20% if we engage with donors in ways A, B, and C. These methods rely on technology that is not available for our CRM. (Pain/Challenge)
  • Selecting and implementing a new CRM represents a significant cost ($300K) and internal effort. But we stand to gain $1.5M in the first year after making the change and implementing the recommended practices. (Reward/Opportunity)
• Example 3:
  • We have great relationships with our funders and clients, but the way we manage projects internally is very inefficient and team members are often overtasked because of lack of insight into current and forecasted team member utilization. (Pain/Challenge)
  • Implementing new professional services automation (PSA) and enterprise resource planning (ERP) systems will provide the project insight we require, allowing us to continue to serve our funders and clients at a high level, while improving culture and morale internally. (Reward/Opportunity)

Change management isn’t about making everybody happy—although of course, we would love it if that were an outcome. But to be effective, change management starts with clearly defining the change that needs to take place—and agreement between key stakeholders that this is the right change. This starts at the high-level, as indicated above, and needs to be broken down in increasingly fine levels of detail as the technology initiatives move through the assessment, selection, and implementation phases.

4. How do we plan to get there?

Now that you have the starting point and the end point in mind, a combination of business and technical analysis will be necessary to determine how best to get from point to point.

Typically, this process will involve planning a set of projects that fall into three major categories: assessments, selections, and implementations. Each of these projects should be described in terms of the high-level objectives, key activities, and deliverables.

Assessments

Clearly, some level of assessment was required to determine where the organization currently stands, as well as to help develop the vision for the future. But additional assessment work will likely be necessary to learn and document the business and technical requirements for the future systems. These might include process maps, data inventories, privacy/security requirements for the types of data you need to manage, policies that will need to be developed or improved for effective management of the new tools, and more.

When these requirements are developed, they will need to be prioritized so that both your organization and future technology solution partners (vendors) will know what is most important to your organization—this helps separate “must have” from “nice to have” features, and/or what must be included in an initial implementation phase and what might be included in later phases.

Selections

To be successful, technology selections should be based in clear, prioritized business and technical requirements (as mentioned under “Assessments,” above). This helps ensure competing vendors are certain about your needs and can speak directly to those needs when responding to requests for proposals (RFPs) and preparing system demos. It also helps ensure your selection team has the ability to score the proposals and demos based on clear criteria, and make open-eyed decisions about what the vendors present for their consideration.

Some nonprofits lock in their requirements at the end of the assessment and don’t engage with vendors until the selection begins. Sometimes, their first engagement with vendors is when the RFP is issued. I recommend some interaction with vendors during the assessment phase, because it can be very helpful in shaping stakeholder expectations and requirements. If, for example, few members of a CRM selection team have ever been exposed to a modern, cloud-based fundraising CRM, it might be a good idea for them to have a preliminary demo of one or more representative solutions before the requirements are finalized during the Assessment phase.

Implementations

Once you have the business and technical requirements defined through an Assessment, and the future solution(s) chosen though a Selection—that is the time to start planning the implementation…. Or, at least, that is what many organizations think—to their detriment.

In fact, the implementation planning process needs to begin with the Assessment, because that is when your organization will start to surface the changes—to policy, operational capacity, process, and data—that the organization will need to make in order to successfully implement any new technology that it selects.

There are many reasons why nonprofit technology projects fail, but certainly a key reason is waiting until after the implementation has already started to put together a robust change management plan in addition to the technical implementation project plan. A good change management plan identifies all the specific changes that users will be required to make in order for the new technology to be successful, identifies the impact of those changes on people in various roles, and defines measures to be taken that help to mitigate or manage the impact. Mitigation activities should include leadership alignment, communications, training, and support.

5. Who will need to make the trip?

A question that clients typically ask at the start of projects is “Who in our organization should be involved in this effort?”

Generally, when creating a new technology roadmap for their nonprofit, an organization will conduct a broad assessment to identify the greatest areas of need relative to their strategic goals. This is what gives the necessary perspective to understand which projects should be considered for the roadmap.

This assessment, and the roadmap creation effort that follows, should include key decision-makers on the executive leadership team, directors, managers, and key subject matter experts from across the organization.

Generally speaking, an executive sponsor will spearhead the process on behalf of the executive leadership team, and engage the directors and managers (or selection of them) to represent the needs of their departments and programs as core members of the assessment and roadmap team. Other directors and managers not on the “core team,” along with other key subject matter experts, would likely be interviewed as part of the assessment process. In some cases, a survey might be used to collect input from a broader group of technology users throughout the organization.

A comprehensive technology roadmap—or a roadmap focused on a critical technology area (like CRM)—should always include active participation of one or more executive sponsors and should be socialized to the entire leadership team for their review and approval. These are critical strategic decisions, often representing large expenses, that have a much lower chance of success absent this participation.

Once you move into executing the roadmap, deeper assessment projects will often lead the sequence for each area of technology improvement—for example, performing business requirements documentation at a greater depth prior to a CRM selection. The same (or mostly the same) group of stakeholders will need to be involved in both the assessment and the selection, representing those departments and programs that need to have input into, and buy-in for, the new technology and the change required to use it successfully.

The resulting implementation would again rely on the same group of stakeholders (as were involved in the assessment and selection), perhaps with some appropriate alterations. But broad, active engagement will also be needed with all users of the system to be implemented, largely in the form of communications related to the change that is to come, pre-roll-out training for the new policies, processes, and technology, and post-roll-out training and support. (This set of tips specific to CRM adoption gives just one example.)

6. What level of effort will be required for travelers?

One of the major challenges nonprofits face when planning technology projects—whether they be assessments, selections, or implementations—is planning the internal time that it will take to accomplish those projects. This is sometimes referred to as the “soft cost” of a technology project.

Organizations that have good management abilities understand that their staff’s time is finite and that new technology efforts will require time commitments that cut into already-busy schedules. This necessitates either adding additional capacity to those functional teams (departments, programs, etc.) or reducing current workloads by deprioritizing other tasks or initiatives. Simple math: if a team member is already working 40 hours per week, and the technology project will take 8 hours per week, you need to take that into account by adding 8 hours of capacity to that team or taking 8 hours of current responsibilities off of that person’s plate.

The number one reason why organizations spend more time in technology projects than originally anticipated, and the foremost reason why roadmap timelines become protracted, is if leadership does not ensure that time-in-project for staff is properly estimated and that the technology project is clearly and properly prioritized relative to other organizational or team initiatives.

This is particularly true of complex implementations of systems that reach across multiple departments and programs—such as org-wide CRM and ERP implementations. When a major CRM or ERP project is in progress, we recommend it be one of the organization’s top 2-3 strategic priorities during the duration of that time period.

Often, technology solution implementation partners are ready to move faster than the nonprofit customers they serve. If the customer’s time isn’t properly estimated and allocated, significant work stoppages and slowdowns can occur—and the vendor has no choice but to temporarily or permanently reallocate their own project team members to focus on other client projects. This combination of circumstances can be disastrous for the success of the implementation.

7. What will be our travel costs?

Nonprofits that have clear Assessment-derived requirements, and are rigorous in their Selection efforts, stand a much better chance of getting realistic cost proposals from vendors.

But often organizations need to have a good sense of potential future expense when they create the roadmap—in other words, well upstream of the Selection effort. This is where it can be helpful to create a preliminary, high-level set of requirements for the potential solutions (for example, a fundraising CRM and a grants management system) and get some preliminary cost information from the market.

We typically see organizations get this cost information in one or more of four ways.

• Benchmarks. Sometimes nonprofit industry studies are available that provide a sense of how much nonprofits pay for technology in different categories, and how much staffing (in terms of headcount and cost) might be necessary to support those technologies. But there are also parallels between many nonprofit business models and for-profit peer organizations, which allow for some effective comparisons when benchmarks are only available in the for-profit space.
• Conversations with peers. Nonprofit organizations are often able to connect with peer organizations that have similar requirements and have recently gone through a similar technology assessment, selection, and implementation process. Getting true costs from peers that have been through similar projects can be very helpful in estimating future costs for your own endeavors.
• Conversations with solution vendors. Vendors are understandably cautious in giving ballpark estimates for projects without an available set of detailed requirements. But particularly for products that are relatively narrowly defined—such as software meant to serve a very particular use case—the way that product can be used and hence the ways it can be implemented are limited. In this case, early pricing estimates for the product itself and the implementations costs may be more reliable.
• Conversations with consulting firms. Experienced firms like Build Consulting are often able to predict, with some degree of accuracy, ballpark costs for future technology solutions. Of course, the better they know the nonprofit space, your type of mission orientation and business model, and your organization itself, the more accurate those estimates will be. Consulting firms may also reach out to solution vendors on your behalf, and can often do so without disclosing the name of their client in the process. This gives you a buffer if you are not at the stage where you want to start having conversations with vendor sales teams.

Generally, expenses like hardware purchases, software license fees, and consulting time are identified as “hard costs”—and these are most typically represented nonprofit technology project budgets.

But “soft costs”—the time commitments that will be required of your staff—are equally important to calculate. (See question six, above.)

8. What roadblocks might we encounter?

Every journey worth taking involves some measure of risk. You’ve probably taken note of some of those risks in reading the preceding sections of this article, including lack of leadership engagement, inaccurate cost estimates, and not planning for internal staff time commitments.

Risk management isn’t a popular topic, largely because to do it effectively you have to imagine that your project has failed, identify everything that could have caused it to fail, document those points of failure, gain agreement that they represent real risks to the success of the project, and then plan to mitigate those risks in advance of them happening (to help ensure they do not occur). Conducting this exercise before the project is sometimes called a “pre-mortem”—and yes, that isn’t a bright and sunny word.

A more productive way to think about risk assessment, then, is perhaps to turn the exercise on its head by envisioning what the project will look like if it is successful at a very high level, including a good level of detail. In doing that, you will also identify the risks. You will also be able, through this process, to identify the risk management (or mitigation) steps.

• Example 1: The CRM project will be successful if team members have enough time to be properly involved. The corresponding risk, therefore, is that other initiatives or responsibilities will pull team member time away from the CRM project. To manage this risk, we need to have the appropriate level of engagement from their leaders/managers to ensure staff members’ time remains free to participate.
• Example 2: The Expense Management system project will be successful if staff have the training that they need to successfully adopt the new tool. The risk is that we haven’t historically done training well for new systems—such as the recent payroll system rollout, which didn’t go well. To manage this risk, we will budget extra resources for the implementation partner to provide more training, rather than relying solely on internal resources.
• Example 3: The Digital Engagement Platform project will be successful if our Communications and Development teams understand the best practice-based processes they will need to follow to use it effectively. The risk is that those teams will not be able to prioritize professional development because of their already busy schedules. To manage this risk, we will arrange the project within our annual development cycle to ensure staff can fit professional development courses into a predictable lull in our activities.

Risk management plans can often only be done at a high level when a new roadmap is developed—including such omnipresent risks as budget overruns and time constraints—and then are refined on a per project basis as the organization moves through the assessment, selection, and implementation projects. Typically, implementation projects have the most robust risk management plans because they have longer durations, greater complexity, and higher costs than the assessment and selection projects.

Risk assessments are not a “set it and forget it” exercise—they are living documents that need to be frequently revisited in order for technology projects, particularly large and complex ones, to be successful. As projects move forward, some risks decrease and others increase. Some perceived risks prove to be unfounded, while new ones emerge that weren’t originally anticipated.

9. How long until we get there?

A good roadmap includes the projects that need to be undertaken, the key activities within those projects, the deliverables they will produce, the projected hard costs (such as licensing and consulting fees), and soft costs (internal time commitments). This, along with your organization’s strategic goals, will inform the prioritization and sequencing of technology projects on the roadmap within a timeline.

In addition to major drivers like strategic goals, costs, and time commitments, when modeling the project sequence on a timeline, it is very important to take into consideration a few additional major factors.

• Holidays. Organizations frequently do not take federal holidays, and the personal time off staff often take surrounding them, when planning their project schedules. This includes vacation-heavy times during the summer months.
• Conferences/meetings/convenings. Many nonprofits produce or engage in major events on a regular schedule, and these can become “all hands on deck” situations around their place on the calendar. It is important to take these events into consideration when planning technology projects.
• Planned leave. It is important to take into consideration planned leave, such as parental leave, for key team members when planning project timelines.
• Rest breaks. People can only go through so much change in a given time period. Engagement in technology projects often means working harder during that timeframe. Before team members get burned out, plan to give them a break to recharge their minds and emotions.

Taking these things into consideration will inform the length of your projects or project phases, the extent to which they can overlap, and where there should be planned gaps between or within projects.

10. When can we have a snack?

The phrase “An army marches on its stomach” is pertinent to roadmap development literally and figuratively.

We’ll discuss the figurative interpretation first. Every roadmap creation process should include the identification of “quick win”—improvements to the current state that can be made relatively quickly with a low level of commitment in time and cost.

Quick wins tend to be discovered organically through the process of having discovery conversations with stakeholders, whether as part of a broad assessment prior to creation of the roadmap, or in discrete assessment projects that occur before a specific system selection. But a conscious effort is needed to make sure the quick wins are documented as part of that process.

Quick wins become the “snacks” that sustain team members while they wait for the larger meal at the end of their journey. For example, if an accounting team wants a better accounts payable (AP) automation tool, but that implementation project would be in Year 3 of the roadmap (behind more pressing organizational needs such as improved CRM and digital engagement tools), it would be good to identify a few potential quick wins that could improve the AP process and/or tools in the short-term. This will help the accounting team feel heard, and give them some support to help sustain them through the intervening two years before a new ERP or AP process automation system can be implemented.

It is human nature to get grumpy without snacks—this author included!

And now to the literal sense: we’ve noticed that people more frequently attend—and are more focused, cheerful, and optimistic—when food is served at technology project team meetings. This is particularly the case when lengthy meetings are required and a high level of attentiveness is needed for the entire meeting—such as a day’s worth of vendor system demonstrations. Serving food also tells team members their time is appreciated, that you care for their well-being, and that you want to try to lighten what is often a tiring and sometimes laborious “extra responsibility.”

In the current COVID-19 era, with the majority of stakeholders working remotely, it is difficult to replicate this “feed the team” approach—but we’ve seen organizations try to replicate it by encouraging team members to bring a special snack to a meeting, or sometimes even mailing snack boxes to team members. Virtual happy hours for team members, including cocktails or mocktails at the end of a long day, can be appreciated. But the most important thing is to come up with ways to maintain a positive atmosphere, a sense of demonstrating care, a commitment to keeping things fun—and just taking a pause to have a treat and celebrate a milestone.

The Bottom Line: 10 Questions Your Nonprofit’s Technology Roadmap Should Answer

These are the positive ingredients that should be in the mix if you want a successful roadmap. If you have questions your nonprofit’s technology roadmap should address, start with this framework and tips to build a Technology Roadmap.

Every organization has a slightly different view of technology and its role within their organization. All nonprofits need a guiding document that informs how they use technology at their organization.

This is a strategic plan that identifies where your organization is, where you want to go, and what technology needs you have to address to get you there.

Need more expertise?

If you don’t know if you have a roadmap, if your roadmap is up to date, or if you are stuck with a technology plan you don’t know if you trust or if all the correct stakeholders have been involved, you can contact Build for a free consultation on how to best move forward. This goes doubly if you find yourself in trouble on a major technology project and are learning during the implementation that key ingredients, including the documentation of your technology roadmap, are missing.

Build can also act as an interim or part-time CIO to get you, your project, and your organization’s technology back on your feet and back on track.

Build’s team knows nonprofit operations and technology (including CRM and ERP systems), 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!