Video: Technology Roadmaps for Nonprofits

Presenter

Transcript

Kyle Haines: Hey everyone, welcome to Build Consulting’s webinar Technology Roadmaps for Nonprofits.

I’m Kyle Haynes, a partner at Build Consulting. And I’m really excited to be here today to talk about technology roadmaps, for associations, for foundations, and for nonprofits. I’ve included my LinkedIn information here.  Don’t worry if you can’t move that quickly. I share it again at the end, looking forward to connecting with all of you hopefully, after today’s webinar.

A bit about Build Consulting and how we approach roadmaps. We include roadmaps as part of our assessment projects, because we think they’re an important way to articulate the work ahead for organizations to transform how they think about technology. These roadmaps inform everything that we do, ranging from being a part time CIO and the portfolio projects that we undertake, to selections and implementation support, and beyond.

Build Consulting is an advocate for our clients. Our goal, when creating roadmaps, is to find the right solution or solutions for your organization by considering your needs, your resources, and your realities.

We don’t accept bonuses or partners with vendors. This presentation doesn’t talk about any vendor specifically, but it’s always important to me and to us to talk about what makes us so unique. We don’t partner with vendors so that we can remain passionately independent and give you unbiased recommendations that are not grounded in any relationship outside of our relationship with you

At registration for those of you who remember, we asked this question about, do you currently have a technology roadmap? These were the results from that poll. And while it was split about evenly between organizations that said that they did have a roadmap and those who didn’t. I was really surprised at the number of organizations that reported that they didn’t know whether they had a technology roadmap.

And in some ways, that’s emblematic of the opportunity associated with technology roadmaps. The opportunity is to create a way to articulate for everyone in a way that’s understandable for folks inside of it and outside of IT where the organization is going with respect to technology investments.

Learning Goals

For today’s presentation, my goals are to First, define what a roadmap is.

Second, I want to talk more about why roadmaps are so important as part of the strategy for an organization, or, I should say, as a distillation of the strategy for an organization.

Next, I’m going to talk about some of the prompters that we encounter when organizations

approach us and ask us to create a roadmap for them.

And lastly, I want to talk about how a roadmap specifically supports an organization as it thinks about bringing together its technology, strategy and organization strategy.

What is a Technology Roadmap for Nonprofits?

With that, let’s get started by defining what a roadmap is. But first a bit about what it isn’t.

I use this graphic to sort of represent how a lot of organizations think about the different systems in play at an organization, especially emerging and growing organizations, and how we can view technology as a series of applications or a series of solutions that help people get the work done.

This likely results in multiple systems that have some measure of overlap some instances where there might be shadow it, and definitely represents an ecosystem where there might be data spread across everywhere. And I’m displaying a little bit of a lead about data and how much I talk about it today.

Technology Roadmaps, Data, and AI

The emerging importance of data and roadmaps is striking. As we begin to hear more and more questions about AI data is becoming central to how we’re thinking about roadmaps.

But even before AI, this idea of data spread everywhere makes things challenging, like reporting impact measurement. It makes it difficult. It makes it time consuming. And in some cases, it’s impossible.

Imagine if you have multiple systems, that track important information about constituents. Or perhaps you have a cobbled together system of spreadsheets and reports and accounting tools, all to do financial analysis, reporting and budgeting and planning all of the things you need to help run an organization effectively. In this example, tools likely have been accumulated over time without a thoughtful strategy associated with them, and these have been accumulated to meet individual point needs. And they’re not part of a holistic strategy around technology or around a roadmap.

Some organizations have gotten better at IT. They’ve moved to an emphasis on fewer and less disconnected systems. But this is still lacking the details that we like to see in a roadmap.

The view of technology as just a series of applications, or even how applications are linked together, doesn’t help show the broader organization where the technology needs to go.

And I’m sharing here a roadmap from an engagement with a client from about 3 years ago. And it was cool because I actually didn’t have to make many modifications to it. There’s no identifiable information in here, so don’t worry if this was your organization.

I thought, this is a great roadmap to include, because it amplifies some of the points I’m going to make throughout the presentation. But if you look at this quickly, you’ll notice there’s some things that show how dated this now is. The value of keeping a roadmap current and up to date the most notable absence. Here is nary a nod to AI. Even if that nod is simply coming up with a position and coming up with a strategy long term for how an organization is going to think about how AI impacts the way that it works.

Don’t worry. We’re going to make a return trip here. We’re going to talk about some things that I think make this so useful for today’s presentation, and how it really rises to meet this organization where they are.

What does an effective technology roadmap communicate?

So, what does an effective roadmap communicate? The first thing is, they simply talk about when things are going to be happening. And this can often be eye-opening for folks as they think about their own individual technology projects. A roadmap helps them understand all of the other technology projects in play and how it impacts the sequencing of their project, and how at certain points an organization might be less capable of taking on a large technology project or investment.

Secondly, a good roadmap really helps give a sense of the scale of projects and the needed investments ahead. Are these projects going to take a few months? Are they going to take a couple years or longer? This is important because in some of these projects, people have unrealistic expectations around how long those projects actually will take.

Lastly, a good roadmap includes not only projects that are about software and solutions and selections and implementations. They talk about all of the other investments that need to be made alongside and in support of those specific investments in technology.

So why do we think roadmaps are so important?

I’m brought to this central idea that guides so much of our work, this idea that technology strategy is organizational strategy.

In our view, this is one of the most important reasons organizations need to think about a technology roadmap. Roadmaps are really just the output of thinking about – what is our technology strategy and how aligned is it where we want to go as an organization?

I’m sharing this technology strategy framework here. And you might notice that this expands upon the time-honored typical people process tech framework that many of us in technology have grown up on. This framework includes some of the more modern considerations of a technology strategy. Things like the involvement of leadership across an organization, things like governance and things like operational changes and data, and all of the things that have to do with bringing a technology strategy to life. This framework is linked in some way to every roadmap that we do.

I want to say one more thing about this. You’ll notice that we intentionally put technology last, because we think all of the things that precede it are important contributors to thinking about the right technology, the right applications, the right platforms that an organization needs to bring their technology strategy to life.

Good to Great

To amplify the point that I just made earlier about technology, strategy and organizational strategy, this quote got embedded in my head the moment I read it. I didn’t read it 23 years ago, but it’s good to great. The book that it came from is more than 23 years old at this point.

This quote talks about a number of things that make organizations and make companies move from being a good organization to a great one. And what I love about this quote is that it puts technology in its proper context. It’s a reminder that technology doesn’t lead to greatness. It supports good organizations from going from good to great. And great organizations have strong leadership, have strong governance, strong operations, and strong processes. I told you, there’d be a lot of nods to data. Great organizations understand the role of data in helping them transform from good to great.

Reasons to Create and Use Technology Roadmaps

There are many reasons that nonprofits, foundations and associations create their first technology roadmap and then use it as a guiding document for planning and executing specific projects and investments. I want to share some of the ones that we encounter most commonly at Build.

It is easy for us to think about these, from the global pandemic that sent most of us working remotely, to AI bursting on the scene, or at least bursting into our collective conversations in the past 2 years. These were large external shifts that were beyond our control. These shifts were so monumental and extraordinary that they have prompted board members to ask questions about technology in ways that they never did previously. They have prompted new questions from staff. That includes concerns about how these external shifts are going to impact your organization and impact the way they work.

And sometimes these large external shifts come from new programs and initiatives from new funding. All of these necessitate a technology roadmap and more so they necessitate frequent revisions to your technology roadmap, to be sure that you’re thinking about not only where you want to go internally, but any external circumstances that are changing, how you might prioritize and sequence technology investments.

The second item is we’re seeing more and more organizations who, instead of asking about technology questions and technology roadmaps, they’re leading with questions about data. Tapping into data is an important outcome of any technology roadmap and should be a strong consideration.

I’m lucky because the example I pulled out earlier and I’m going to share later has that nod. It has a nod to data. Data is obviously the foundation for AI, both generative AI and machine learning. These roadmaps that think about data are thoughtful about how organizations are going to think about training and upskilling and staffing for future data needs.

And again, I should say they are thoughtful about how to make the staff at organizations and the organization itself become increasingly data driven entities, as data becomes more dispersed.

If you remember that diagram I did earlier across systems like CRM, ERP or accounting software, case management software. Thinking about the power of the data that sometimes is locked away in those systems, ways in which you can untether that data from those systems and make it more accessible and more democratized, that can prompt staff and organizations to ask ever expanding questions and glean an ever-expanding set of insights from that data.

Before I continue a brief word from CIO Vision. No, this presentation is not sponsored by CIO vision. But I found this stat striking, and this is across both the nonprofit and for-profit and governmental sectors in a survey.

72% of CIOs think that before they can really even get to working on AI, they have some data quality issues that they need to solve.

I brought this up because data is going to be central to your AI strategies of today. If you don’t have AI strategies today, they’re going to be central to your AI strategies of tomorrow.

Technology Roadmaps and Software Selections

This is probably the most common reason for creating a roadmap. And it’s when a roadmap includes a significant investment in selecting and implementing something new. A roadmap, rather than just jumping into a selection, helps the organization.

Think about that new selection and how it might impact investments in other parts of the organization, and how that selection might impact other solutions.

For example, thinking about something like CRM. It’s hard to imagine a CRM project that didn’t also think about what the impacts and what the roadmap would be around the accounting system. And again, not that I let the tail wag the dog with the roadmap I included. I happen to find a roadmap that talks about one of those impacts. Specifically, it also prompts the organization to think about system selection and implementations about those specific projects and how it’s going to impact staff. So beyond just impacting them after the selection, after the implementation. Who in the world is going to do all of this work? How can we support staff during a selection? How can we support them during an implementation, so they can not only participate in the software or the technology project but do their regular day jobs. How are we going to support them either with additional internal or external capacity?

And lastly, it prompts other questions around a system, evaluation replacement, things that might need to be modified like how your organization operates, how your organization is staffed around that system, what business processes might be open for change and improvement and evolution.

Rapid Growth Prompts the Need for Technology Roadmaps

The next issue that prompts an organization to create a technology roadmap is the last one, and its rapid growth.

Sometimes a roadmap follows an organization after it’s expanded rapidly. Either it’s gotten a lot of funding. It’s merged with another organization or something else that’s made it just grow really quick. I want to brand this first bullet point gaps and overlaps. I love the cadence of that, the exercise of creating a roadmap when you do a good job of engaging a broad set of stakeholders, and you inventory. Lots of systems helps identify. Where are the gaps, and also sometimes places where systems are overlapping or even duplicative.

An example of that is a client that we worked with that, when we got in there, we figured out they had 3 or 4 different places they were storing their files. This creates, as you can imagine, all kinds of difficulties with respect to finding the right documents, it’s going to eventually create problems with AI. It creates security considerations. There were all kinds of overlap in how people were storing and managing the files that they worked with.

Lastly, the one thing I want to say is, and it probably goes to the point that I just made about the organization that had multiple ways of storing files is when an organization has rapidly grown and their IT footprint has grown out of necessity, our roadmaps often start with questions about governance.

In the future after roadmaps are created, how will decisions be made about when and what technology is acquired? What are the mechanisms in place to make sure that you are not creating shadow IT, that you’re not duplicating functionality, that you’re not using the tools that you have to the best of their abilities?

Visualization and the Technology Roadmap

I want to now share a bit more about how our roadmap can support both organization and technology strategies. And what a roadmap, I should say, how a roadmap really takes this idea of a technology strategy and creates a highly visualized digestible version of that.

To that point a roadmap should be something that you can take on the road with you. It’s a tool that’s designed not only for it, but also leaders within your organization.

We tend to get hung up on these very complex but necessary representations of how center systems interact, how they interface, how APIs flow, how data flows, the systems that are in place, licensing all of the things that are incredibly necessary.

But a roadmap is designed for two types of consumers, IT and equally important, those who work outside of IT.

I’ve mentioned in a couple places the need that to engage with stakeholders when developing a roadmap. A well designed and maintained roadmap includes the needs of the broader organization, and the only way that you understand that is to have a meaningful way to regularly engage key stakeholders within the organization.

Lastly, a roadmap shows that it is not just a tool that breaks, sorry that fixes things that are broken. It is a strategic investment or a strategic lever. It’s not just an operational investment.

The other thing that a roadmap does, and it’s a big part of IT. And along with the exercise to create it, the roadmap itself is expanding technology beyond just a singular IT department. It helps offices, it helps teams. The roadmap helps departments. All need to understand that they play a role in IT, but it also helps IT understand the strategies of those individual components of an organization, the roadmap becomes a two-way street of communication between departments and IT, and it really fosters a spirit of communication. It helps a spirit of technology planning, and it also reinforces that IT can’t be the only champion of technology-related investments and that everyone in an organization plays a role.

Roadmaps help show much more than just than investment in a single fiscal year or a single period of time.

They are multi-year, as is the one that I showed earlier. They show the scale of investment beyond a single year, or even the next fiscal year. And even though it’s not on a roadmap, they should be prompting questions about sustaining technology.

A roadmap includes these investments in some of the most important assets that your organization has are your staff. All of this technology doesn’t go anywhere without the people behind it.

And when I think of technology roadmaps and something like AI, it makes me think about the investments in upskilling staff and helping staff understand where and where not to use AI in their work. And when we go back to the sample slide a little bit later. You’ll notice that AI isn’t on that roadmap. But, as I said, I must have been prescient because I knew that data was going to become important. I just didn’t realize the timing and the ways in which it would become so much more important.

This is a formula that we share a lot, but it never seems to get old. It’s because everyone has lived a version of this.

Old Organization + New Technology = Expensive Old Organization.

As I think about the slide that I shared earlier, the one that had lots of different applications, some of them overlapping, some of them shadow. I wonder how many of these solutions in this fictitious stack really just led to an expensive old organization.

And when you see in this visualization some of the duplication that exists, it makes you wonder, how expensive has some of this technology gotten, and has it really lived up to its promise? Has it simply contributed to being an expensive old organization?

So, with that, as I promised, and we’re nearing the end of our webinar today. I wanted to go back to that sample roadmap I shared earlier. I picked this one, as I said earlier, for a number of reasons, because, as I thought back to the work of this specific client, I thought that some of the points that I made earlier about how important roadmaps are, and what makes for a successful roadmap really are highlighted and illustrated in this roadmap as it is in other roadmaps that we’ve created for organizations.

The first thing I would highlight that I thought was a nod to something I said earlier is for this organization.

The very first project is about establishing governance, because they had some significant decisions to make. As you can see the remainder of the roadmap related to data and technology. And we believed that creating a governance structure that really thought about how technology and how data worked at this organization was an integral input to other things that came later in the roadmap.

I wanted to highlight in the digital engagement track and also in other tracks that when we think about roadmaps, we think about selections as individual projects. I think a mistake that often gets made is people think about selection and moving right into implementation. I’m not suggesting that those two things don’t abut each other, but those projects involve oftentimes different people.

The people involved in the selection are important stakeholders in the implementation for sure. But the implementation might expand and expand the universe of people who are touched by it. So that’s why we think about technology selections as one project and implementations as a secondary project.

In Lane 4 of the roadmap, there’s this project that really relates to, not to technology, but it relates to data, and it relates to process. It’s talking in this example about how does this organization classify revenue? How well does it work both with in this case, the development team? How well does it also work with the membership team? How well does it work with the finance team? Lots of stakeholders in that. And we thought that work was necessary before the organization moved into a selection for an ERP solution later. And this is an example of something that’s not specifically a technology project. But it’s a roadmap project, because it’s setting the organization up to think about data and technology down the road, and to have already considered some of the things that are going to impact what a selection might look like.

The very last track. Don’t forget about the data in this one again. This is before AI. But we recognized that at some point in the future we wanted to be less beholden to a single system and its ability to capture data and report on data and analyze data. So, we included thinking in the future about what we call the data hub, we didn’t know. And in some ways, we still don’t know exactly what the technology will be. But in year two on this roadmap, we’re going to start thinking about what are the requirements for that data hub and use those to inform a selection of a data hub, either a data lake or a data warehouse, or a lake house, or a house by the beach, or whatever the term that’s most popular these days.

It is this is focused on thinking about that in advance of selection, and being prepared to think and have specific conversations about how data is captured, managed, and leveraged.

And then, lastly, this roadmap and the timing of it hopefully conveyed an earlier point that some of these projects are going to span multiple years, and they are going to be significant in nature. And so, this is a nod to that and prompts questions about how staffing and capacity is going to be addressed during the peaks of some of these more intensive projects. 

How often should you update your Technology Roadmap for Nonprofits?

A question that we get that I saw in the chat was about how often we should update the roadmap. If you think about things like AI, or you think about global pandemic, I guess really, the question is there’s an ad hoc need to update your roadmap. But it’s something. Even if that ad hoc situation doesn’t come out or come up. Rather, I tend to look at things like roadmaps quarterly. I think it’s a good idea with the technology leadership to review it quarterly to make sure that it’s still capturing where the organization needs to go.

I think at a minimum annually is the time to bring people in from across the organization and refresh the roadmap, even if it’s just bringing this to a meeting and saying, here’s where we are. Do you still see these as the priorities for the organization. Those are important exercises, even if the roadmap stays the same. This is about listening to people and giving them the opportunity to contribute to the broader technology strategy for a nonprofit, for an association or foundation.

Summary: Technology Roadmaps for Nonprofits

As we wrap up, I wanted to just summarize with some of the key things that, I think are important for a successful roadmap.

The first is a reminder that technology strategy is organizational strategy. A roadmap should be for everyone obviously linked to where a nonprofit foundation or association wants to go.

Secondly, a roadmap needs to have broad stakeholder engagement. As I highlighted on the last slide, I’m fond of saying everyone should get a voice, even if they don’t get a vote. So, translating that to the last slide that I just hit on, even if once a year you’re bringing the roadmap around to people and confirming their agreement or hearing any concerns about it, that is an instance of giving people a voice, even if they don’t get a vote. And some of those people, especially at the most senior levels of an organization, should, in fact, be voting and getting a significant seat at the table around whether the roadmap is meeting the needs of the organization.

Third, a successful roadmap has tracks that don’t include technology. They have things related to governance and shifts in processes or operations, data, questions and ways in which you might need to do training or leadership alignment.

And lastly, again, we talked about before; roadmaps need to change. They aren’t set in stone. Just as organizations flex and change, so does your roadmap.

I want to thank everyone for attending today’s webinar. I really enjoy presenting on this topic. We talk a lot about the things that we think, make organizations successful. The things that we think are interesting and relevant to organizations. We do have a newsletter, but I think the best way to connect with us is on LinkedIn. We get folks sharing stuff on there, commenting all the time. Please join us on LinkedIn.

And if you want to connect with me. I’d love that as well. Here’s the QR. Code and my LinkedIn name. You can search for either one of us if these aren’t working for you today, or you don’t have your mobile device in front of you.

And lastly, you know, if we can be helpful, please feel free to reach out. We really appreciate all of the time that people have committed today. Our hope is that you’ve learned something. You can take something back to your organization and get started on your roadmap or refresh the roadmap that you have. We’ll be sharing this presentation, making it available in the next several days and thank you again for joining today’s webinar.