A powerful, practical framework for change

• Investing in new technology systems only to find that your colleagues have not adopted them?
• Making changes to your systems or processes only to find that people revert to their old ways?
• Hearing about “change management” but feel unclear on what it is or how to perform it?

Nonprofit Technology Change Management

Most technology projects have non-technological goals: raise more money, reach more supporters, serve more program participants, or become more efficient. To reach those goals, not only must the technology improve, but the habits and behaviors of system users must change – sometimes significantly.

In this video, we share how to manage the challenges of aligning organizational change with technology projects. Learn how to examine the impacts of a technology change and identify the steps required for an organization to manage the change.

Transcript:

Johan Hammerstrom: Welcome to the May Community IT Innovators webinar.  Thank you for joining us today for our webinar on “Successful Nonprofit Technology Change Management.”  My name is Johann Hammerstrom.  I’m the president and CEO of Community IT and the moderator for this series.

We’re very pleased to be presenting this webinar today with our information strategy partner Build Consulting.  A little bit more about Community IT: we’re a 100% employee owned company, our team of almost 40 staff is dedicated to helping non-profit organizations advance their missions through the effective use of technology.  We’re technology experts and were recently named the top Washington DC- based managed services provider by MSP Mentor.  And now it’s my pleasure to introduce Build partner, Peter Gross, to introduce himself and also tell us a little bit more about Build.

Peter Gross: Hey everybody, my name is Peter Gross and I was one of the co-founding partners of Build consulting.  Build consulting, we work exclusively with nonprofit organizations, helping them with technology strategies to help them transform the work that they do and we were longtime partners with the Community IT folks and really glad to be able to be here with you, and with them, for this webinar today.

Our agenda for the webinar today is really pretty simple, and we hope it’ll be relatively quick from a presentation standpoint. We’re first going to talk about

• why technology projects often fail,
• we’re then going to talk about a simple approach that we have that can help improve your chances of success,
• and then we’ll walk through a case example
• and then take questions at the end.

We’re hoping this will take between 15 and 20 minutes and then we’ll have questions at the end.

At Build Consulting, we have 2 core beliefs that really motivate us, both to do this work, and to approach it the way we do.  The first is our belief that technology can empower organizations both to work more effectively themselves, and to help change the world.

But the second motivating core belief, is that the technology fails so often because we treat it like a baseball field in Iowa.  If we just build the technology, people are going to come and use it.  But they often don’t, because the success with technology requires a strong and a flexible organization that can move forward at the same time that the technology is moving forward.  The fact that they don’t just come when you build it. It’s perfectly captured in our favorite formula, the abbreviation of which is OO + NT = EOO.  You take an old organization and you just add new technology to it, you’re likely to just have an expensive old organization.

The key is to find the right things to add to the formula that will make the outcome a transformed organization.  Because that is critical to your success. 

We believe that a truly effective approach to transformation using technology, starts with a focus on leadership and governance. It allows us to ground our technology strategy in the strategies and the mission of the organization and to ensure buy-in and support from the highest levels of the organization. From that strong foundation, we can then make good decisions about what kind of operation we put in place to manage that technology.  Design really solid, effective processes, organize our data well.  Only then are we able to make choices and investment in technology that can truly bear fruit.  Technology can be the accelerator, but it can’t be the driver of the transformation.

Ultimately we do believe if you pair technology with transforming your organization, you have the opportunity to make the world better.  So just a quick commercial tjust to tell you a little bit more about what we do:  like I said, we work exclusively with non profit organizations.

We have 3 basic service areas.

• The first is part time CIO services, where we put in experienced non profit technologists working with the leadership in your organization to help drive technology strategy.
• The second, are Build Projects, there are things such as system assessments, system selections, and support for implementations, including change management, which we’ll be talking about today, and our
• Build Teams offering provides organizations with highly skilled and strategic database administrators to help you manage your systems.

But just to ground us back in why we’re here and the problem we’re trying to address, we’re here because of the number of technology projects that frequently either fail completely or don’t live up to what they were hoping would ultimately happen once they implemented it.  A good deal of the failure rate associated with technology projects and probably projects in general, is related to the fact that we simply don’t do a good job of anticipating the effect of these projects on the people that they’re supposed to help, on the people affected.  When these impacts then hit them, we lose their hearts, we lose their minds, we lose their eyeballs.  It disrupts our results, we don’t get the return on investment that we’re hoping for.

Examples

So just to give you a couple of examples of what we’ve heard of the years of manifestations of this problem.  Frequently in fundraising, we hear stories of folks that moved into a cloud based solution for something like fundraising, could be other ones as well, and the folks that are using it are still unhappy.  Because it turns out that actually the technology wasn’t the problem.  The problem was that the leadership didn’t set clear expectations and guidelines for its use and that no fundraisers, no frontline fundraisers, were involved in the implementation.  We ended up implementing it incorrectly.  We see this story repeated over and over, and not just for fundraising, but for membership, case management, program management, events, pretty much anything you could think of.

This is actually a recent story we heard from a client, where they implemented a new credit card reconciliation tool for expenses and receipts.  In the cloud, mobile enabled. They expected everyone would be thrilled because it was a kind of a nice looking interface, it was easy to use, it was mobile, but because they didn’t actually involve end users in that project, they didn’t realize that this whole process actually adds a bunch of work to their plate, so rather than getting time savings and excitement, they actually got time added and a great deal of frustration.  The reason these problems happened is because we didn’t critically examine the impacts of that proposed change; and we made decisions that jeopardized our ability to get a return on investment.

So the answer to a lot of these challenges, lies in the field of organizational change management.  It’s a pretty academic sounding term, but it’s actually pretty simple when it gets boiled down.  We like the definition by Prosci; Prosci is a leading research and consulting company specifically focused on change management, it’s all that they do.  And the core of that definition is that change management “guides how we prepare, equip, and support individuals to successfully adopt change.”  You’ll notice it doesn’t say guides how we make everybody on the project happy.

It’s a frequent misinterpretation of change management for nonprofits is that it’s about making sure that everyone is happy with the change that is happening.  It’s not.  It’s about making everybody ready for that change and hopefully in the process making some of the people happy.

When to Use Change Management?

So when do you need to use change management techniques?  Here’s the test that I’ll give you.  If your technology change requires people to adjust their behaviour in order to achieve your goals, you need change management.  I’m going to read it again.  If your technology change requires people to adjust their behaviour in order to achieve your goals, change management is something you need to invest some time in.  Good news is, and you’ll see there’s tons of research books, theories, etc. out in the change management and consulting communities.  It can get awfully complicated.

What we’ve done is actually try to simplify it into three steps to get people started down this road; and these are the three steps:

• defining the change,
• identifying the impact from that change, and then
• preparing for those impacts.

This framework works regardless of whether you’re talking about a really small change, like a minor process tweek, or adding some additional fields, etc, all the way up to a large change with say a huge CRM system implementation or financial system implementation.

So a little more detail on what happens in each of these phases

This first one, defining the change, I can’t emphasize how important defining your change is.  We see so often, working with our clients, people have plowed ahead with the change and aren’t really even clear about all the components of that change. So our advice to you, in defining the change, is to write it down and be specific as you can, share it with stakeholders and leaders, revise it, share it again, and ultimately get to final agreement.  That final agreement is about two things:  the first is ensuring that decision makers and key stakeholders agree that this is in fact the right change.  The second, for everyone in the organization, is to ensure that they’re clear that the change is coming.  That doesn’t mean everyones agrees to it, but at least everyone is clear on what’s coming down the road.

The second step is about identifying the impacts of that change.  And for those of you familiar with stakeholder analysis, this contains stakeholder analysis within this step.  The key is to identify the individuals and the groups that are impacted by the change, determine how they’re impacted, and how big that impact is.  Because, if you’ve identified what those impacts are, then you can start to leverage certain strategies to ensure that we  become more prepared for the change. 

And there’s three of those strategies here which we talk about.

• First is about activating leadership which basically just means ensuring that your leadership is prepared to be cheerleaders, funders, supporters, and users of the system of other changes that you’re putting into place.
• Second, you need to determine who needs to know about this, and be communicated with about it, what the messages should be, and when and through what mechanisms.
• And third, you need to make sure that you’re training the right people at the right time, and that you have the right support for them after the change goes live, or after the change happens.

So that’s the framework, define the change, identify the impacts, prepare for the impacts.

So I’m going to walk you through a specific example;  the example we made up was Build Consulting, our company, moving from using spreadsheets to do time and expenses and invoices to a more formal cloud based time and expenses system; so that’s the example that we’re going to work through.

So our first step would be to define that change.  You can see that I’ve written it down and been at least a little bit specific.  (11:42) If this was the real document where we were putting this together there would be more detail in here, I didn’t want to overwhelm you with it.  But really being as specific about the change as you can is important.  Basically the change that’s happening is we’re replacing those spreadsheets and implementing a new time, expense, and invoicing system.  And it’s going to affect those groups that you see there.

To gain agreement, what we would do internally is discuss it among the partners and maybe some of the employees, vote on that change, and also consult with our staff, our subcontractors, our bookkeepers, etc, so they’re clear on what’s happening and when, and what will be expected of them.  For every change that you might think about implementing, this sharing and gaining agreement could look a little bit different, but that’s the basics of it.

So now we know what’s changing, and now the important thing is to identify what the impacts of those changes are on specific groups and individuals.

So you can see that as a result of moving from spreadsheets to a formal time and expense system, we’ve identified a number of process areas that are going to be affected.  Time and expense entry, time and expense approval, invoicing, processing invoice payments, and then sending data to QuickBooks.

In each of these areas, we have identified who is impacted, what that impact is, and whether it’s a small or a big impact.  And I know that there’s a ton of information to try to digest on the slide, so we’re just going to focus on one line of these processes, just to show them as an example of the kind of detail that we put in here.  So not only do, in this particular case, not only do partners have to use the new system for their own time and expenses, and use it for time approval, but in fact, in this particular example, the partners had never done time approval before.  So it’s a new process, and a new policy.  So it’s important that we not only think about that they know how to do it, but we also need to set a policy and a process that says when time approval’s going to happen, what the expectations are for how they evaluate employee time, etc.  So, it has a business impact beyond just the system changing.

So then once we’ve identified those process areas, those impacts, and who’s affected and how, we can then create strategies for addressing those impacts.  Now, the entire version of this grid would be probably 10 to 12 rows long, we’ve condensed it down here, and again we’re going to focus just on one line, to show you how we would work through creating strategies to address this impact.

So again, the impact, the partners and the fact that they have a new time approval process and system.  And it will highly impact them because it’s something new they have to do every week.  And then there’s five areas where we’ve identified strategies to address the impact.

So there’s the job impact.  The partner’s job description now has to include that time approval process, which it didn’t have to include before.  We would provide to the partners actual weekly progress updates that would happen weekly for fifteen minutes, or thirty minutes, depending on what was necessary, and that might happen a bit less often for employees or for other folks that are stakeholders.  We know that partners are going to require training on the application as well as training and education on the new policy that’s going  to be in place, and finally we want to make sure, because there are highly impacted stakeholders, we want to make sure that at least one partner is involved in the process design and testing the system to make sure that we’ve implemented that functionality properly and their voice is heard.

So that evaluation we just went through, and I realize we went through it extremely quickly, but if you go through that same process for all of the impacts and all of the stakeholders who are affected, what you have at the end of it is the ability to create a plan in each of those 5 areas.

• You can create a stakeholder involvement plan that will tell you who should be involved in the project and in what way.
• You’ll be able to ensure that changes to jobs and processes and policies are both accommodated and documented.
• You will know what you need from leaders, and you’ll know how to get them activated in their role at the right time.
• You’ll be able to come up with a communication plan so you know when to communicate with folks and
• you’ll be prepared for the right kind of training and the right kind of support for the folks in your organization.

Our hope is that the tools that we’ve described here, and we realize we’ve flown through pretty quickly, are going to help you make your projects more successful.  After the webinar, when the folks from Community IT send out their emails that have both the recording of the webinar and the links to the slides, we’re going to include a template of the kind of grid that you just saw that you can actually take and use in any way you want, and take it and apply it to the next change that you might have in your organization.

Johan Hammerstrom: We have a number of

Questions.

The first is asking for a little bit more clarification on the differences between defining the change and preparing for impact?

Peter Gross:  Defining the change, I tend to think about it as explaining what that change is; what is coming down the road. In the example that we gave, we’re replacing a system of spreadsheets with a more formal system for doing time and expenses that’s going to impact not only employee time and expenses, but time approval and how we do invoicing, how we do payments and how we do our financial accounting. So that’s more of a broad statement. Be as specific as you can be to make sure that people understand the nature of that change.

Preparing for impact is really about saying, okay, we’re going to take away the spreadsheets and we’re going to put in place this new system. In what ways does that impact people? For some people it’s a small impact. For our accountant, for instance, it might be getting the data in a little bit of a different format, but essentially their job is staying the same. For a partner or an employee, they’re using a brand new system to do time and expenses and some form of project management.

And then the strategies themselves are the things you do to address those impacts.

• Training, as an example, is a strategy to address the fact that people need to know how to use that system.

• Communication plan is a strategy to make sure that you don’t start off the project, go three months where no one hears anything. When people don’t hear anything, a vacuum basically creates a lot of paranoia. People make up their own stories about what’s happening. So what’s a reasonable way to communicate with the right folks at the right time to make sure they know what’s coming down the pike, how it’s going to affect them, et cetera? I hope that helps clear it up a little bit.

Johan:  Yeah, I think so. It’s a great question though, and I think it’s an issue that happens pretty frequently with software applications.

This organization says they fought with whether or not to update their fundraising software, mostly because of unrealistic expectations about what the program should be doing versus what it actually does.

The question is, are there communication guidelines during this process to address that disconnect between the expectations people have and especially the unrealistic expectations people have around what software can do versus the reality of software limitations?

Peter:  Wow. Within the context of change management, what we often find is that the first step of defining the change and being clear about what impacts it is going to have and getting that in front of people is an educational tool and it starts to ask the kinds of questions that are implied in the question that that person asked.

As an example, in almost all cases, if folks aren’t using the system that they have to do fundraising and they just refuse to use it, putting in a brand new system generally doesn’t get them any closer to that goal, because the change is much more about what is the process that we have in place? How do we work together? What are my expectations? All of those kinds of things contribute to the success of a fundraising program and the ability of technology to leverage it.

The more clear you are on what change is happening and implicit in that is – what change is not happening? So if your fundraising team does not have a strong process in place to manage prospects, as an example, new systems won’t do anything better for them than the old systems did. The truth is, you can raise money using index cards, it’ll take a while, but the essence of major gift fundraising you could do without a technology system, although it’s made better. So it is a universal problem everywhere probably, but certainly in nonprofit organizations.

Johan:  Yeah, I think it’s a universal problem. Certainly exacerbated when an organization has complex tasks and workflows and collaboration that needs to happen.

Peter:  Yeah, exactly.

Johan:  Here’s the next one. This is an organization that’s designing an internet for their grantees to submit documents and reports. They would submit them through an internet instead of through email. This is an interesting one because in this case they’re talking about external stakeholders, external users.

What’s your sense for how long it takes people to adopt or feel comfortable with new processes both internally and externally?

Peter:  There’s so many variables in there and a lot of it depends on the incentive system that is put behind whatever the change is. So if you look at that particular example using using an internet to collect grantee reports, from the grantee side, if you all have a policy in place that basically says, “we better see that last report or your last check is not going out the door,” I can guarantee you that process will be adopted immediately.

If, on the other hand, internally there’s steps that have to be taken that move from email to internet and there needs to be support for making sure that that person has the right incentives, the right training, not to return back to the old way of doing things.

If folks are properly prepared and have the incentive and are managed to adopt the new system, generally speaking, we find that happens reasonably quickly. And again, obviously more complex processes take a lot more time.

But I think the difference between the grantee’s incentive and the staff person’s incentive is instructive of how important it is to build that consideration into the processes that you put in place. If I have absolutely no incentive to put my time into the timing system, I’m probably not going to do it. Now my other partners would get mad at me, and we wouldn’t be able to invoice clients. We wouldn’t get paid and I wouldn’t get paid.

So I’ve got a great incentive to actually adopt that new policy and to approve everybody’s time very quickly, because we want to get those invoices out the door. A combination of good and appropriate training and good and appropriate incentives, whether they be sticks or carrots, are the key to getting those processes adopted more quickly.

Johan:  This question is about advice you have for implementing steps after the change has occurred.

So the project, the software, the IT has been rolled out, but change management wasn’t followed during that process. The project hasn’t failed, the software’s still being used, but it hasn’t been nearly as impactful as it should be. What’s ex post facto the best way to go back and do change management?

Peter: It’s a great question. In some ways I think you could do this same exercise, right? I mean, at this point you’d probably be able to answer these questions better, because the impacts are going to be obvious or more obvious anyway, right?

Do a postmortem impact evaluation, perhaps interviewing those folks, gathering information in a way that you can get a sense of where the disconnect was. There’s no reason that these strategies can’t be applied even though you’ve already gone live. If the problem was that perhaps the process was not particularly well thought through, let’s think through the process. If we need to make some adjustments and how the system is configured, that’s fine.

And then roll out some supplemental training. If they just feel lost in the software and don’t feel like they know what to do, then perhaps arranging for some additional support, some additional folks who can sit by them, while they work and help them through that or having a help desk that they can call into with questions and encouraging that.

I don’t think any of these are limited to the scenario where you’ve implemented the perfect change management framework from the beginning. I think it’s inevitable that you’ll get to go live, even if you did it well, and you’ll find some things you didn’t anticipate. Perhaps some things that just didn’t get executed as well as they could have. No reason we can’t go back, take a second bite at the apple and see if we can make it better the second time.

Johan:  Great. That’s encouraging, because I think many of us have experienced that and would love to have a second bite at the apple when it comes to implementing technology solutions.

We have time for one last question. Another great one, and I want to thank everyone for the great questions today. This is a question about communication.

What communication approach works well in these two different scenarios and oftentimes these go together?

One, where the organization lacks experience from a leadership standpoint with project methods. So, an organization where the leadership isn’t necessarily accustomed to a project management approach.

And then two, organizations where end users are siloed in their departments and not really communicating.

For an organization-wide initiative, specifically what communication approach helps you to overcome those two challenges?

Peter:  If you go through this framework and you say, we’re implementing this new system that does X and it’s going to affect department one, department two, department three in sort of similar ways, maybe with some differences.  They’re going to be using a lot of the same functionality, but they’re all sitting in their own silos. That is something that should specifically come out of this evaluation and it should drive the project to be the example to the organization of how you start to do collaboration.

We don’t run implementation projects, but when we support implementation projects or when we do system selections, this is frequently the case. There’s a lot of different parts of different organizations that do relationship management of different kinds that overlap in a lot of different ways. And what we insist on is that when we are defining either what the system that we’re going to choose has to do, or when we’re implementing particular functionality, each of those departments has to have a representative at the table as we’re doing the selection, the design, the training, whatever the case may be.

And what we find often is that these projects can serve as a template for the organization about how collaboration is supposed to work. I can’t tell you the number of times where people have said to us, “This is the first time we’ve ever been in the same room together. I had no idea that 75% of what they do is actually similar to what I do.”And that isn’t to say that can’t be uncomfortable sometimes because people have competing priorities and those have to be worked through. But using your project as an opportunity to model the behavior that you want the entire organization to engage in is a step in that direction.

One of the communication techniques that we try to use is as we’re moving into these either selection or implementation or just change projects, if we want to break down the silos, we have to start using language that is not siloed. And so we try to be really careful and thoughtful about making sure that when we’re talking about the project, we aren’t putting people into silos. We’d rather talk about the relationship management example I gave as, this is going to be an organization-wide relationship management tool and it’s going to be impactful for this group and that group and this group.

It’s a collective approach as opposed to saying, we’re going to go live with the development department next week and then after that it’s going to be the legal department and then after that it’s going to be the partnership department. Obviously, some of that may be true, but thinking about crafting language that doesn’t reinforce the siloes is another way to use communication to actually break down those barriers.

Johan:  Got it. And we have some clarification.

This is a situation where the leadership role is as the champion of the project, but they’re not familiar with IT project models. They’re in full support of rolling out this new solution and for that reason, are the ones charged with communicating with the organization, but they don’t have a lot of experience with IT projects.

Peter:  I got it. Thank you so much for the clarification and I think the short answer is that

In general your leadership shouldn’t be talking to your organization about IT models and about project management methodology and about the technical aspects of the project. Their job is to champion that change as a business change.

It’s not, we’re using agile methodology to roll out a brand new CRM platform on Salesforce, and we’re going to be accessing APIs, et cetera, et cetera. All of that stuff is true and for certain audiences it makes sense.

What the leadership needs to talk to is, here’s the reason we’re making this change. Here’s the problem it’s solving. Here’s how we’re solving it with minimal technical or methodology references. It’s about the business of the organization and that’s what your leaders should focus on communicating to people.

Again, going back to the example of how you talk about defining the change. Speaking to people in terms they understand, because it is about the business that they care about, it’s about the organization that they care about.

And in fact, defining that change and defining the impacts can feed into it if you set up that person up with a PowerPoint with some talking points or just some bullet points that they can use, depending on what their style of communication is, but helping script them about what those business changes, business impacts, business benefits are from the change that’s undertaking.

Because if it’s truly only a technical project, if you’re taking one server and swapping it out for another, if you’re trading one cloud hosting provider for another, chances are most people don’t need to know about that part of the organization. And that’s not much of a an organizational change management effort.

If it involves the business and involves people changing their behaviors, we need to talk to them in their language, because they don’t care about IT methodologies, they don’t care about for the most part about technical architecture or other pieces like that. So I hope that’s helpful.

Johan:  Very helpful. That was a great clarification. Great question. Your answer Peter, I think provides a lot of assurance for leadership that they don’t have to be IT experts and in fact could probably add more value to this process by not being IT experts, but by connecting the dots to the business needs.

Peter:  Exactly. We get people, leadership in particular, telling us all the time, I’m not an IT guy. I leave that to those folks, right?

We don’t want you to be an IT guy. You’d probably be a bad IT guy. We want you to be a business guy or gal. That’s your job, to tell us how you want to run your business and then we’ll figure out how to make the technology accelerate that process.

Johan:  Yeah, absolutely. Well, thank you Peter. I appreciate you taking the time to answer that last question and very much appreciate your time today and sharing this framework with us. It was very interesting and something that I know is very pertinent to nonprofit organizations.

Peter:  Well, I hope it was helpful and I hope the template for the change impact will be helpful to folks as well.