What You Will Learn

In the ever-evolving landscape of nonprofit work, harnessing the power of cutting-edge technology is becoming increasingly pivotal for those aiming to drive social change. However, navigating the complexities of enterprise-wide technology projects like ERP, CRM, or even exploring artificial intelligence (AI) can be a daunting task for nonprofit executives.

This webinar sheds light on the strategic differentiators that pave the way for successful nonprofit technology projects and address some of the common challenges nonprofit leaders, driven by a passion for positive impact, must address when tasked with implementing enterprise-wide solutions.

We delve into the art of strategic decision-making, offering invaluable insights that transcend the realm of technology and extend into the heart of successful enterprise-wide technology projects. Kyle emphasizes the importance of a holistic approach; intertwining the organizational objectives with technological advancements, nonprofits can create a synergy that propels them forward.

Furthermore, successful technology adoption involves a keen understanding of the diverse interests at play within the nonprofit landscape. Kyle shares practical strategies for navigating the intricacies of balancing competing interests, ensuring that technology solutions not only meet the immediate needs of the organization but also foster collaboration and innovation.

This presentation is appropriate for all current and emerging nonprofits leaders, including those with varied IT experience. Build Consulting is proudly vendor-agnostic and our webinars cover a range of topics and discussions. Webinars are never a sales pitch, always a way to share our knowledge with our community. In this webinar we share our advice and insights based on what we are seeing in our community.

Transcript: Six Strategic Differentiators in Successful Enterprise-wide Nonprofit Technology Projects

Kyle Haines: Welcome to Strategic Differentiators in Successful Enterprise-wide Technology Projects. I’m really excited for today’s webinar and to bring Build’s experience where we highlight some of the things that we’ve seen that help set up enterprise-wide technology projects to be successful.

As you’ll see from today’s webinar, there is a lot that I want to cover. And as a benefit, we’re going to be sharing with you some of our best resources that we use on large projects where the impacts of a technology change extend across the entire enterprise.

I’m Kyle Haynes. I’m a partner with Build Consulting. And I get the opportunity to play a role on projects of all sizes where we partner with the leading nonprofits, foundations and associations to integrate their technology strategy with their organizational strategy.

Before we get started, Build Consulting is an advocate for our clients. Our goal is to find the right solution for your organization by considering your needs and your resources and your realities. And so, we don’t accept bonuses or partner with any vendor. 

I introduced this idea that often, when you’re talking about technology strategy, you’re talking about these types of projects.

We believe that ultimately the strategy around technology is, in fact, an organization strategy. And this idea should underpin just about everything that we’re talking about today.

The idea is that, especially for projects that are enterprise-wide, we think it’s important for you to understand and concretely articulate why a technology project, in fact, is supporting something much larger.

Today, we’re gonna be talking about the resources that we tend to use on these types of projects: 

• Assessments, and roadmaps, which is where we often start. This is something that we think is essential as organizations begin to plan large enterprise-wide technology projects.
• Selections, which for us become an opportunity to really understand in detail the operational process. 
• Governance and data, change that’s going to be associated with a large technology project. 
• And lastly, implementation support where we are integrating change in project management into large enterprise-wide technology projects.

47% of Tech Projects Fail

This is a bit of sobering information as we enter today’s conversation. And we actually think this stat is a bit conservative. And it’s what leads us and brings us to taking such a comprehensive view of technology change. And I think in many ways it’s the motivator for today’s webinar. And I wanna share in more specifics how we came to this statistic.

CRM projects: CRM projects are indicative often of these large enterprise-wide technology projects. And they’re indicative because oftentimes, these types of projects expect enormous change across departments with multiple stakeholders being impacted and given that, this rate of failure is striking.

A few things that I wanted to note about this stat. One thing is the age of this statistic. It’s now more than, I think, 13 years old, and I think it’s curious that it’s really difficult to find information about enterprise technology project failure, and I think there’s a couple of reasons for that.

The first is that there’s probably not a common definition of what failure actually means. Does failure mean that you didn’t even complete the project? Or, does it mean that the project was completed, but people aren’t really using the system? Does it mean that the project was completed, people are using the system, but you didn’t really meaningfully move the needle?

So it’s hard oftentimes to get at this idea of, what does failure look like? My second hypothesis is that many organizations are reluctant to declare projects as a failure. And so this is probably, in fact, a little bit of under-reporting on the extent to which CRM projects, and probably other types of projects, are viewed as failures by nonprofits.

I note some of the reasons that people cite for the failure of enterprise CRM projects, and note how few people, just above one in 3, actually blame the technology. And I’ll bet if you have the opportunity to dig into that number a little bit more, in fact, you would learn that it’s the other things that really were at the heart of why a project wasn’t successful. Ranging from not really understanding the strategy all the way to, perhaps not taking the opportunity to look at key processes, and how those processes would be impacted by a change.

So with that, let me get into some of the differentiators that at least, I think, make for successful enterprise-wide technology projects.

The 6 Differentiators

These 6 differentiators. I think that if you actually ask my colleagues, they might come up with many of the same things. Perhaps they would have a larger list, or they might sub something else in here. But at least in my experience, these are the things that really make the difference on these types of projects.

1. The first thing I want to talk about today is the importance of understanding, when you’re taking on a project like this, what does the change actually mean? How large of a change are we really talking about? 
2. The second thing we’re going to talk about is how to identify your colleagues that are perhaps really excited about this project, people who are perhaps excited but nervous, and those who might have fundamental questions about the wisdom of undertaking this project. 
3. Thirdly, and this is going to feel a bit random, I want to talk a bit about data strategy. And why, increasingly, I think it’s such an important part of enterprise-wide technology projects. In the context of this list, it might feel a bit out of place, but bear with me. 
4. Next, we’re going to talk about making staff ready for the change ahead. 
5. We’ll then move into some of the things that organizations tend to forget when they’re thinking about a multi-year technology project and what’s required from a budgeting perspective. 
6. And then, lastly, we’re going to acknowledge that sometimes these projects can feel like a bit of a slog, and how to mitigate and plan for that reality.

Identify the Change

So one of the first differentiators is around understanding and communicating the extent to which an organization is going to be expected to change. And I note that on this slide there’s a QR Code, a link for our change management impact catalog.

I think this is so important because one of my colleagues was fond of saying that change management really starts at the beginning, at the assessment phase. So many successful projects start thinking about this early and the ones that are less successful, think about change management at the start of implementation, and many times it may be too late if you don’t really understand the extent to which an organization is going to be impacted.

And as I’m gonna share in a moment, this is really about writing down the impacts of the project and getting specific and using this tool to help leaders understand the extent to which people, departments, and the entire organization are going to be impacted by a change. 

When you download this, the first thing you’re gonna see is it’s massive. So you’re gonna want to grab a cup of coffee as you begin to dive into this incredible resource. But in all seriousness. Do take some time to review it.

Keep the parts of it that are helpful, and remove what’s not. We are sharing today a version that is capable of tracking the needs of the largest enterprise-wide technology projects. Not all columns may be useful to you, and that’s okay.

The other thing that I’d note as you begin to digest this document and the potential for capturing this rich and robust detail around it: this is actually a living, breathing document, as many of our templates that relate to change management are. This document has a life throughout an enterprise technology project. So what does that mean? The goal is that you’re iterating on this as you learn more and more throughout the life cycle of a project.

The second differentiator is that you create a mechanism for people to feel as though their voice was heard in a project.

The reality is that no one likes to feel like a change was forced on them, or if that’s their perspective, they at least didn’t have the opportunity to weigh in. So the idea here is to really find out how people are feeling about this project.

Identify the People

The idea further is to get specific and begin to learn who are champions for this project? Who are the people that are less convinced of the project? And the idea is to invest in moving people in a positive direction as the project progresses.

The resources I want to share are some of the questions that we actually use as we begin to understand, or at least attempt to understand what people are feeling about this project.

This is a bank of questions that we use when we try to understand the sentiment that people have around an upcoming change, and oftentimes, we use these in the form of a survey, and the survey has a couple of advantages. The first is that it gives you a way to actually quantify how people are feeling. So rather than it being something that’s subjective, it can be more quantitative as you measure how people are feeling about the change.

The second thing that’s nice about surveys is that you can choose to give folks a degree of anonymity in doing the survey. Perhaps make it optional that people include their name so that people can really surface any discomfort or hesitation or fears that are emerging around this project.

Lastly, just as a quick note, many times when we use this survey we’re just trying to capture whether people agree or disagree with these ideas. Personally, I like more of a sliding scale. I like to see everything from strongly agree all the way to strongly disagree, because I really want to see if we are able to move people away from areas of disagreement to greater areas of agreement about these types of impacts.

Data Strategy

This is the one that if you remember, I said I was going to have to make a case for why this is so important. I include data strategy in the differentiators that make technology projects successful because often technology projects have an enormous component that is related to data and technology is not going to solve problems that might be, in fact, linked to data. And by understanding your data strategy, what it helps do is set realistic expectations around what parts of this project relate to data and what parts of this project relate to technology. And in many ways it may surface areas that need to be invested in around data itself.

Here is an example. I recently read this report from CIO Vision 2025, and it was talking about AI. I was struck by the number of global CIOs who really believe that before they can approach AI, they have a data quality issue that they need to address. 

So imagine if this was your nonprofit. If there was a lot of energy and excitement around AI. It’s important, as you think about AI and technology investments, that you also understand where you are with respect to data quality.

What I’d like to share is this data maturity index we use when we’re assessing organizations around technology or data and really trying to understand where a non profit is in its data maturity growth. 

I’m including this slide because it is a good prompt to think about some of the things that might require investment in addition to making a technology investment. Those investments can be creating more of a data centric culture at your organization, it could make just small investments in helping people understand the data that’s available to them, democratizing that data so they can access it and use it to inform decisions. There can be investments in helping leadership define and understand data and create key performance indicators associated with that data. And lastly, it could surface the need to simply create a greater data governance practice so that high quality data can be collected and managed and analyzed.

Again, these are included as prompts so you can think about data in the context of an enterprise-wide technology project.

The next resource I wanted to share is a Build Consulting proficiency matrix. What it is attempting to do is identify the way in which staff are going to need to adapt as this technology project gets underway and prepping people from a skills perspective for the new technology that is going to be part of the work that they do.

It outlines areas that your organization will need to think about staff transition and create training and learning resources for them that extend beyond the project. So thinking about adoption tools, thinking about training plans, training programs, thinking about new staff that you may hire in the future and onboarding them into these complex and robust technology platforms and tools.

Maybe it will also help you think about budgeting for new staff if there are significant gaps that can’t be met by existing staff, and you don’t think they should be met by existing staff. So areas that you might want to invest in outsourced help and help from vendors along the way.

When you download it, you’ll see that it’s color coded to flag and highlight areas of concern or areas of opportunity in the template. Or in this example, there are 5 areas in this hypothetical technology project we expect people to have some proficiency, and hopefully, some interest in. As you evaluate people’s proficiency and interest in these areas – this is an opportunity for a survey – it flags areas that perhaps are concerning. It also flags areas that perhaps are not particularly concerning. 

With Monique, in this specific example, perhaps her role really has nothing to do with cyber security and she doesn’t have any interest in it. That’s okay. But what we want to identify with Monique is areas where, if she’s expected to be a strong project manager, she is identifying that she has low proficiency in that area. So how do we make investments to support Monique throughout the project, so that she can become more capable and a project manager that can contribute to the success of the project?

Budgeting

The next differentiator that I wanted to talk about is budgeting. In our experience, when people come to us for our advice on these projects, many times they are not fully aware of all of the things that they should be thinking about as they develop a budget beyond an initial assessment and selection of new technology. 

In the implementation and ongoing lifecycle of an enterprise-wide technology project, some of the things that we think often get missed are the need for help with the implementation itself.

The idea that existing staff may not be able to absorb a large technology project into their existing portfolio of work needs to be validated and understood many times through intensive periods in projects like this. It might be anywhere from a half, to 3 quarters, to full time with respect to the amount of time that’s going to be required of them to participate in an enterprise-wide technology project.

Change Management

The other thing that gets missed is the need for change management. And unfortunately, these are the two things that get cut when people do budgets. As my colleague Debbie likes to say, if these things get cut during a project, you can either pay for change management and project management now, or you can pay much more later.

Many leaders believe this is the way a technology project tends to work with regard to budget. They tend to underinvest in understanding where the organization is, what scale of change is going to be involved and what the impacts are. They then move quickly into engaging with vendors without really understanding their organization’s or their departments’ requirements. 

And so this becomes less about mapping a technology platform or solution to what your organization needs. It becomes more about this bright, shiny object and the vision that their vendor has. We think it’s critical that organizations really understand their requirements.

Usually, leaders understand that as the implementation progresses, there is going to be greater investment of money and staff time. It might involve staff augmentation to support staff as go live begins. But there’s this misnomer that once go live happens, that investment can tail off, and investments that are required will be minimal post go live.

This is closer to what the reality is on successful enterprise-wide technology projects. We think that, irrespective of how you approach it, making investments upfront in an assessment where you gain consensus, and where you understand the road ahead, pays enormous dividends throughout the life cycle of a project. It makes for more successful implementations. It makes for more realistic budgeting around implementations. I can’t underscore how important it is to make sure that your organization really has a concrete understanding and a consensus about what this project means.

Organizations that treat requirements-gathering as not just an investment in picking a vendor, but really understanding what’s needed at your organization, and what processes need to be supported and articulating what those processes are, pays dividends not only in the selection, but in the implementation as well. It gives vendors an understanding of your expectation and your organization’s expectation of how you want to work in the future.

Finally, a big differentiator on successful enterprise-wide technology projects is not tailing off the investment at go live, but thinking about: What are the ongoing investments that are gonna be needed to make this successful? So anything from staffing to bringing in ongoing expertise and coaching, training, sending people to conferences where they’re continually learning, modifying job descriptions. Where you say it’s an important component of your job to learn how this technology can support the organization in new and expanding ways. Thinking about all of those, in my view, are investments that need to be budgeted for from a time perspective or from a financial perspective.

Challenges

The last thing is the reality is that these projects often take multiple years hence. We’re talking about a multi-year budget. The reality is that over time, you and your colleagues may really start to hate this project because it is going to have challenges, and it’s going to require large investments of time, and those things, as I said earlier, can feel like a bit of a slog.

We have some ideas, and we have some tools that we use to help keep the project team and the organization invigorated and sustain enthusiasm throughout the project.

Some ideas here that we’ll highlight in detail as we talk about our Build Communication Calendar template are that getting lots of voices involved in this project helps demonstrate the importance of it, and reduces the monotony of the same voices talking about the importance of this project, again and again.

The other things that make for a successful project is acknowledging that interest is going to wane and also acknowledging when things don’t go particularly well. Have plans for talking about both of those, and be honest and candid about when things go well, so that the messages around things going really well resonate more.

The other thing we think is important in our communication template is giving people successes along the way, giving people milestones along the way that they can celebrate rather than making it all about the end of the project and the end goal. What are the things that you can do to acknowledge that progress is being made, so people feel a sense that the project will have an end date and that there is a proverbial light at the end of the tunnel?

On this slide, what I wanted to highlight is that one of these communications early on is actually coming from the CEO, even if she’s not the one who’s writing it, even if the project sponsor is writing it. This is an opportunity to really frame the importance of this project and to really frame this idea that technology strategy is organization strategy.

The other thing is acknowledgement that the communication plan needs to be thoughtful of communications after the project’s go live is over. So perhaps this template is really about, for example, an enterprise resource planning, or an ERP project, and how to think about the things after go live that should be acknowledged and celebrated: we completed our first month-end and closed the month, and we did it in record time; or the robustness of reports expanded greatly; or you had new people engaged in it. Whatever those things you are thinking about, what communications can happen post go live.

OO+NT=EOO

As we wrap up today’s webinar, I wanted to bring us back to the importance of the topic today, which is a formula that we use all the time at Build. And if you’ve worked with us before, you have seen this formula before, and I included it today because it really never gets old for people. Everyone has lived a version of this formula, Old Organization + New Technology = Expensive Old Organization, and so hopefully, what you can do today is use these differentiators to help your organization ensure that it’s not one of the organizations that would frame an enterprise-wide technology project as a failure. But instead, think about how you could use these to become an organization that is, in fact, transformed by a technology project rather than becoming an expensive old organization.

I really appreciate everyone who joined today’s webinar. We’re excited to share this presentation afterwards, so that you can get your hands on those resources, if you didn’t use your camera during the presentation on the QR code. Thank you again for attending. I’m Kyle Haines. Have a great day.