Nonprofit Tech FOMO (Fear Of Missing Out) pt 2

Does your organization struggle to match your IT to your actual business needs? 
Learn how to right size your IT and get rid of FOMO.

In pt 1, Johan, Pat and Carolyn discuss Tech FOMO and the reasons nonprofits are susceptible to feeling it. They ask the webinar audience about their last new tech implementations and explore everyone’s current FOMO, AI. In part 2, Pat walks us through an IT decision making pathway (which you can download below) and Johan answers audience questions.

Fear of Missing Out (FOMO) is a natural human condition. And when it comes to technology, shiny new tools and platforms can seem very shiny. Add in tech giants’ large marketing budgets and vendors who pressure you to keep up with the latest and greatest, and you can feel like you constantly need to move to the newer, better solution to get the latest features, or you will be missing out.

What if you could escape the cycle of reacting to new technology marketing by firmly establishing a new tech decision making process based in your nonprofit’s needs, with flexibility and vision, that includes a mechanism to thoughtfully evaluate where you want to go with your nonprofit technology over time?

Join CEO Johan Hammerstrom and Director of Information Systems and Technology Pat Sprehe for this webinar to learn how to assess your nonprofit’s readiness for new technology. Give your leadership team practical tools to evaluate new technology wants vs needs.

Is your nonprofit suffering from new tech FOMO?

Free Download: IT Decision Making Cheat Sheet For Nonprofits

As with all our webinars, this presentation is appropriate for an audience of varied IT experience. Community IT believes strongly that your IT vendor should be able to explain everything without jargon or lingo. 

_______________________________
Start a conversation :)

• Register to attend a webinar in real time, and find all past transcripts at https://communityit.com/webinars/
• email Carolyn at cwoodard@communityit.com
• on LinkedIn

Thanks for listening.

Transcript

Identifying Tech Needs: Case Study Staff Survey Tool

I want to move on now to how to identify needs. I think, Pat, you and Johan, we’re going to talk a little bit about a recent non-AI tool that we looked into at Community IT to roll out to our staff and how that went. And what did you do in that situation to identify the need, find the tool, and then roll it out?

Pat Sprehe: Yeah. In this particular case, this came down as a request from leadership. Basically, from Johan and the leadership team. We have transitioned over the past couple of years to be a fully remote organization. We have about 50 to 60 staff. There was a concern that the leadership was losing touch with the well-being and the feelings of our regular employees especially those who were hired entirely remotely from the DC area.

The task was for a way to take a pulse of how employees were feeling, how they were doing on a regular basis, weekly, monthly, however. And at first blush, it seemed like, well, maybe we could put together some Microsoft form or a Google form, if we were in Google, and just send out a survey every week or every month, put that together in a spreadsheet and figure out what to do with it from there. 

We developed a solution selection process internally to determine what tools we want to use, if we want to use them, and how we want to implement them.

We can use this example to walk through this decision process. We’ve identified the problem, we want to take it slow, so the first thing we want to do is we want to engage stakeholders and identify our stakeholders and come up with an implementation plan. Typically, this involves demoing various tools … 

Well, actually, the first thing it involves is just some basic research. 

When it comes to employee engagement, for example, the first thing we want is we want some framework. How do we create our questions for this survey we were thinking of? How do we evaluate the different criteria? How do we assess how employees are doing? How do we preserve anonymity? How do we do that? 

We did some Googling. We looked for advice from other organizations that have done this. Maybe consultants have recommendations on tools to use. 

You don’t want to rely on the vendor. You are going to get input from the vendor. You’re definitely going to see demos from the vendor. But you don’t want to rely exclusively on the vendor by any means. 

And after that, we also wanted to do a pilot. We don’t want to buy all licenses for all 60 staff. First we want to try this out for a small set of staff, make sure that any kind of tool works for us. If we were doing a survey, we’d make sure that the survey works for us and that it’s fulfilling our needs. 

We want to use some champions, especially in the pilot. Hopefully people who ask more questions give us more of a challenge.

And we absolutely wanted to take our time with this, because the more time you take in advance, the smoother the actual implementation and the usage of it becomes. 

Typically, when it comes to a solution, there’s a few market leaders. Those tend to be the ones that you probably want to go with first, because those are the ones that have aligned around the best practices and are the most user-friendly and the easiest to use.

Johan Hammerstrom: If I can just jump in before we go to the next slide. I think the first two or three points can’t be over-emphasized. I went into the process with a preconceived idea of what I was looking for, and many of you may be able to relate to this.

A lot of this was really to address a request from our board. As an employee-owned company, we have a board that we meet with regularly, and they kept asking me, like, well, how do you know how the employees are doing? And they were really pushing for a way to report on that.

So that was the initial need that I expressed to our Chief Operating Officer, Johanny Torrico, and then she worked with Pat. But I didn’t really go into more detail beyond that, and I didn’t say it needs to be this kind of solution or that kind of solution. 

Articulating the need at a very high level gave Johanny and Pat a lot of space to explore different solutions, which was great because they came back to me with possibilities that I hadn’t even thought of that ended up being much better than what I was originally envisioning.

When you’re working with your leadership on finding a technology solution, it’s important to make sure that the leadership is not getting into the weeds in terms of defining what the solution needs to be, but rather remains focused on what the organizational need is.

And then you can enter into this really great collaborative process. Because at the end of the day, what’s available is what’s available and you have to fit your needs into the solutions and to the software that’s available, but with an eye to that market consolidation point at the end there, which is an excellent point. Oftentimes, the market helps you refine your own requirements.

Pat Sprehe: The first thing we did was some research. What we found was that we didn’t have to build this out on our own. There were tools we could use in order to help us with this. And that a lot of those tools were based on common best practices across various industries. A lot of the questions that the tools are asking to engage or to gauge employee satisfaction, employee engagement, were based on research that either these organizations had done or that the industry had done. I think the tool we use has research pulled from, or that they had done with Gartner, and I believe it was Deloitte, that may not be correct, to create like a set of tools and a set of criteria. 

We identified some of the stakeholders, which would be the people who are making decisions about, you know, whether we want to pursue this tool or not. For this case, it was mostly me and our COO, Johanny.

We created a list of basic requirements. And these are just the things that we either need or we want or would be nice to have from the solutions we’re looking at. 

Then we did demos with the various solutions.

And from there, you know, with a demo, you can pretty quickly decide whether this is something you want to continue further, or sometimes it’s a solution which is just not a good fit. We had one solution which used gamification for increasing employee engagement. Gamification means that if you as an employee hit various KPIs, you hit various milestones, you get an Amazon gift card. That wasn’t really a good cultural fit for us. We very quickly knew that’s not something we want to pursue further. We could drop that one. 

We did come up with a couple of solutions that look promising. And so, we started a trial. And the way I think about this is that a trial is where you want to go in, and you want to dig through the settings and the usage, and to see how user-friendly it is. Does it have all the features you want? Is this very usable? 

One employee engagement tool, which we thought we were going to use, was this very big, powerful tool. But then when I got into the trial and started using it, it turned out that it was hard to use, and it was very much a top-down approach, and it wasn’t a great cultural fit. And this is where we move on from the basic requirements into the nitty-gritty details of the actual usage of it. We opted for another tool. It’s called Office Vibe, if you’re interested. 

And from there, we moved on to a pilot. We asked for volunteers from the different teams at Community IT, and we scheduled time with those champions, as we called them, once a week for about a month. We walked them through the tool, we showed the champions everything it could do, because we wanted them as our champions to know everything that we were looking at, everything that we wanted them to do, everything that we would want the employees to do, so that if anybody had a question in the future, they could go to one of these champions, and the champion would be able to answer 90% of the questions. We had them run through the usage of it. 

This particular tool sends out a pulse survey every week. It has anonymity baked into the tool. It has written feedback available, those kinds of features. We had them test all of these different features and got some feedback from them. I will say that I actually thought that we were, this pilot was too big, we didn’t need this pilot. But it turns out I was wrong. We actually got some really good valuable information from the pilot.

People had questions that I’m glad that they were asking during the pilot, otherwise I would have been answering the same questions 60 different times if we had gone directly to implementation. So yeah, this pilot was definitely very useful. 

You’re going to spend a lot of time in the pilot because the pilot is also where you really start to create and develop the process documentation that you have. 

How is the tool used? How is it going to be used in the future? One process that immediately you should plan to update whenever you’re implementing a new tool is your new user onboarding. Whenever you have employees in the future, you have to make sure that they’re trained on this new tool.

There’s how it’s used, what our expectations are, like all that kind of information should be written down, should be documented, should be tested. 

Then comes the training for staff, whether it’s just a small group using the tool, or it’s all staff using the tool. Sometimes these can be two different sets of users. Generally, if just a small group is using the tool, you may want to train those staff in detail on the tool. But you probably want to communicate to all staff “Hey, we have this new tool we’re using. There’s this new security tool that we’re using. You probably won’t see it, but if it comes up like this is what it is, it’s very useful to keep staff informed of what’s going on the various teams.” 

Then we have what we call the service transition, which is where we go into full service. We’ve communicated to all of our staff. If this is a tool we’re implementing externally, we would be communicating it to our clients. This is also where if there are contracts related to implementing this tool, so we have some services that we offer to our clients. This is where contracts would be developed, contracts would be signed.

And then at some point, you would want to come back probably in about six months or a year, and you’re going to want to revise and improve your processes and maybe revisit your staff training. I know that whenever we’ve implemented a tool, the way that we think we’re going to implement, there’s usually minor modifications to it, that we need to come back and just update our processes after implementation.

IT Decision Plan Download

Carolyn Woodard: I’m going to jump in here and say that we did create a download just of these three slides that we’re talking about, the IT decision plan, about how you can make IT decisions.

Is your nonprofit suffering from new tech FOMO?

Free Download: IT Decision Making Cheat Sheet For Nonprofits

Pat Sprehe: Yeah, actually, this is a very short slide. So essentially, I just wanted to point out that we talked about implementing a solution. For implementing a new process, a new policy, it’s largely the same process. 

You identify the need; you gather your stakeholders. When you’re building out a policy, you break it down into pieces and then build it out step by step. Create your documentation. You pilot the process; you train staff on the process or policy. And then again, you revisit the documentation after several months to correct and improve. 

A quick example is we have this very large user onboarding process at Community IT. There are things that need to happen before a user starts, a lot of technical setup, make sure they have their computer. There are things that happen the day the user starts. They meet with HR, they meet with internal IT, make sure that they can log in to everything. And then there’s two weeks of training. They meet with all the different managers and learn what each team is doing. They learn the different tools that we use across our organization. And then their manager is meeting with them and providing training. Aligning all of that is a very large process. 

When we first implemented our updated process last year, we had to come back.There was just a simple question about like, well, who is supposed to send the invites for all the training that needs to happen? Is it HR? Is it the manager? We tried it one way, we had to come back and do it the other way. So now it’s largely the managers who are sending invites to the new employee.

Carolyn Woodard: And I think this process design policy plan could be used for any policy. 

I just mentioned we have a template for an AI acceptable use policy. How is your organization expecting staff to use AI tools? And that would be something that you could run through this as well. You roll it out, train people in the policy, and then revisit it. Do they understand the policy? Are they still using AI tools the way you’re expecting them to? It really is useful in multiple different situations. Thank you so much, Pat, for running through that.

And as I said, we have that as a standalone. You can download those three slides and use them as you would like to. 

IT Roadmaps to Counter New Tech FOMO

I think, Johan, we’re going to have to jump through these slides pretty quickly. We do have some other content on IT Roadmaps. But just how would you use, how does an IT Roadmap relate to this idea of identifying your needs and then matching the tool to your needs?

Johan Hammerstrom: Yeah, if you want to post the links, we have a couple of webinars where we go into much more detail about IT Roadmaps. I encourage you to check those out if you’re interested in developing a roadmap. But basically, the whole point of this webinar is that there’s two antidotes to FOMO.

The first antidote is what we just covered, which is focusing on the need rather than focusing on the solution. And that process that Pat walked through is all about how you can start from the need and arrive at a well-deployed, well-implemented solution. 

The second antidote is an IT Roadmap, which is about contextualizing the need, one specific need, with all of the other needs that the organization has for IT to fulfill. 

An IT Roadmap is just a list of the technology projects that an organization has, all these recommendations that are all intended to meet a specific need. Because the organization, your organization has many needs, and the problem with FOMO is that you throw out all the other needs that you have to just focus on this one technology solution.

Contextualizing the need for particular technology against all the other needs that the organization has is really important to make sure that you’re focused on the right things, you’ve identified the organizational priorities, and that you’re pursuing those first and foremost.

And it also helps you to manage an organization’s capacity for change, because you can’t do everything at once. And you listen to the example that Pat walked through of the employee engagement solution that we rolled out. It took half a year, and it involved a lot of people being very focused and committed to making it successful.

You need to make sure that your organization has the capacity to take on that change, and you need to look at the other initiatives that you’re pursuing, because you only have so much capacity for change. 

Following an IT roadmap is a great way of getting out of the FOMO that you or others in your organization might be feeling.

Pat Sprehe: Yeah, it definitely takes a lot of time. I think that’s the biggest cost, even beyond the cost of whatever licensing or product that you buy when you implement a solution. I know every demo, you have to have a meeting afterwards to discuss the demo, and then you have to have weekly check-ins to figure out what are the next steps and who’s doing what, and are you making progress on it, so that it requires a lot of time.

Carolyn: More time, schedule more time than you think you’re going to need. And I love that idea, Johan, of taking those costs into account when you’re even budgeting for a new technology solution. You might be thinking, “oh, I need to put in my budget the cost of the licenses, or the time of someone to do the demo.” But really, then, you’ve got to also budget in the time to have focus groups or have the pilot or have time to revisit with the managers. And so, adding all of that into your calculations is important.

Johan Hammerstrom: Here’s a really good rule of thumb. 

If you don’t have time to explain it to your staff in an all-staff meeting, you don’t have time to roll it out. If it can’t fit into your all-staff agenda at some point in the year, then you shouldn’t be doing it.

Carolyn Woodard: Yeah, it’s just going to take a lot more time than that. Prioritizing as well. If it’s not enough of a priority to find time for it in the all-staff meeting, then you’re not going to be able to prioritize it later.

I’m going to quickly go back over the learning objectives for today, learning what tech FOMO is and why nonprofits can be so susceptible to it, discussing AI and other transformative tech moments, and learning to identify your needs. Thank you so much for going through that case study with us. That really was helpful.

I think to just give a concrete example of a time that we use this technique, this kind of checklist, learn how to make software selections and new initiative decisions, and understand change management considerations. We kind of breezed through that quickly, but we do have some other content on our website about change management and how you might use an IT roadmap to help with change management, including the selection of a new IT that you want to use. 

Q&A

If we have a moment or two, Pat or Johan, if you can stay on and answer a couple of these questions from the chat.

AI Tools and Data Privacy

Johan Hammerstrom: Yeah, I can answer pretty quickly. In terms of AI tools and data privacy, it’s really important that you not use publicly available tools with any data that you consider private. So public tools like ChatGPT are taking in the questions that you’re asking, the prompts that you’re providing, and just incorporating those into the learning.

It’s a huge statistical model. The chances that your particular data is going to get surfaced is pretty low, but still, you don’t want to take that chance. Microsoft says that Copilot does not ingest any information that’s proprietary. They maintain pretty strict walls with the customer data. Any of the data in your Microsoft 365 tenant is not being used to train any of Microsoft’s learning models. 

Cybersecurity and AI

I think a question was asked about the partnership that was announced between Microsoft OpenAI and Palantir, which is a national security contractor.

And I think that’s a good example of probably where, and Pat alluded to this earlier, I think this is a good example of where AI is really going, which is custom applications that are ingesting large amounts of proprietary data. This is an example where they’ll be looking at national security data to do pattern recognition that would otherwise be impossible for humans to do. And that’s probably where you’re going to see the most progress with these large models where they’re taking in a lot of proprietary data.

And big finance, I’m assuming, is going to at some point leverage AI. That’s when you know that when AI has really arrived, when large financial firms are using AI to track the stock market and combine proprietary information related to companies to provide investment advice.

Carolyn Woodard: I think, isn’t Gemini also, if you are logged in to your Google account and you’re using Gemini, that’s also private?

Johan Hammerstrom: I think so. What I would say is have an AI policy, and we have some links and some resources on our website about AI policy for organizations. That is probably a good place to start to make sure that you’re addressing data privacy concerns with respect to AI software.

Carolyn Woodard: And then, of course, having that policy within your organization so that your staff know how they’re expected to use those tools. If you do want them to be logged in to Microsoft when they’re using Copilot rather than going out to a public tool, that would be part of your policies. And then you’d need to make sure, as Pat said, that you’ve rolled that policy out and that you’re revisiting it with staff so that they continue to understand as AI tools change, what you’re expecting them to do for acceptable use.

Pat Sprehe: Educate new staff.

Carolyn Woodard: Yeah. And of course, when new staff come in, they need to learn that policy, of course. And that should all be written down.

Well, thank you so much for joining us, Pat and Johan. I feel like we really could only scratch the surface of how you make decisions, but I feel like this was very useful and valuable information, a framework for how you should go about identifying your needs, and then moving from the needs to the tools that might address them, and then all of those other steps that come after making that decision of how you’re going to roll it out to your staff and incorporate it in your policies. Thank you so much for joining us and thank you everyone who’s still on with us.

I will let you get going, but thanks for staying another minute or two with us to answer those couple of questions. And thank you so much.

Pat Sprehe, Johan Hammerstrom: Thanks Carolyn. Thank you everyone.