View this video directly on YouTube (and subscribe to our channel!)

Listen to the Podcast

Like podcasts? Find our full archive here or anywhere you listen to podcasts. Or ask your smart speaker.

Transcript below

How to Succeed with Your Software Implementation

Facing an implementation project? Now that you’ve made your software selection, what are your next steps? How can you maximize this opportunity for your nonprofit, and minimize the risks, time, and expenditures to reach the goals for your new technology?

In this video Peter Mirus, co-founder of Build Consulting, discusses ways to succeed with your software implementation, shares leadership strategies, and answers questions from the webinar audience.

What you’ll learn:

• What does it mean for the implementation of a new software or platform project to be a “success?”
• What are the key elements your organization needs to have in place to guide an implementation to success?
• What are the secrets of successful nonprofit tech implementations that fail to get enough attention?
• How can you help your nonprofit be in the 50% of tech projects that succeed?

There are many reasons why software implementation can be less than successful. Maybe you need to alter the composition of your project leadership team, perhaps your training objectives or requirements aren’t clear, perhaps you haven’t organized your time management well, or maybe you just need a strong change management template to help you keep up on multiple and multi-faceted team tasks.

In this webinar on how to succeed with your software implementation, Peter Mirus shares tips gleaned from over two decades working with nonprofit leaders to improve tech selection and adoption. Learn how to set your nonprofit up for success.

As with all our webinars, this presentation is appropriate for an audience of varied IT experience. Build is scrupulously vendor-agnostic, so this conversation will feature a realistic look at the impact thoughtful leadership can have on your project implementation outcomes.

Presenter:

Transcript

Peter Mirus:  Hello everyone and welcome to our Build Consulting Webinar for October 2021. Today we’ll be addressing some of the critical elements to success when implementing any software product, but particularly those implementations that require a good amount of behavioral change from your users. My name is Peter Mirus and I’m your presenter for today. I have over 20 years of experience serving all manner of nonprofit organizations as a Business and Technology Strategist and Executive, and I’ve run into many implementations over the course of that time. So, this presentation is based in part on my own experience and also on industry best practices and what Build’s partners and senior consultants have learned over the course of doing this throughout our careers.

I do have an agenda prepared for today—starting with engagement from executive sponsors, definition of the business benefits, business and technical requirements definition, project planning and direction, risk assessment, change management, taking a collaborative iterative approach, and then finally rounding it out with supportive tools and professional skills development. Some of these will get more time than others, but we will be moving quickly today in covering a number of topics.

Even though I have an agenda prepared, I’d really love to hear from you in terms of what brings you to this webinar and what you would most like to get from today’s session, if there was one or two things that you’d really love to come out of this session with. If you could go ahead and put them in the chat right now, that would be great. I’ll give you a minute or two to do that while I go through some sort of wrote slides that talk a little bit about Build Consulting and what we do and then I’ll come back to this later. You can also ask questions throughout the webinar, of course, and at the end, feel free to just chime in any time.

So, Build Consulting is a consulting firm that focuses exclusively on nonprofit organizations. We only work with nonprofits and it’s within the realm of technology and information system strategy and support. We have a collaborative approach that empowers our clients to make informed choices for their organizations. These are the different ways that Build leads in the social good sector, or in other words the type of projects that we do.

The thing that all of these services have in common is they’re designed to help nonprofits transform themselves to better serve constituents of all types, including funders, donors, program beneficiaries, staff, volunteers, the general public, you name it. And the way that we help organizations with implementations is we sit on their side of the fence and the relationship with their implementation partner or software vendor and help lead or support the leading and management of those implementation projects basically supporting or augmenting the capacity of your own internal team. So, this is something that we often do for clients, and it’s largely focused on project leadership or project management and change management.

As always, our webinar recordings will be available on YouTube and also, we now make them available in podcast format as well. So, you’ll receive an email notification when those are posted to our website and you can search for the Build Consulting Transforming Nonprofits Podcast, wherever you get your podcasts.

What are the keys to success for implementation?

So, let’s just dive right in. What are the keys to success for implementation? So, while they’re indicated in the agenda that I presented earlier, I’m just going to take each one in turn, starting with this idea of having actively engaged executive sponsors. One of the things that technology projects have in common when they’re successful is actively engaged leadership or executive sponsors, and there are a variety of different ways that executives can help in this way. I’ll mention a few of them today and then there’s also several different articles written in our blog at buildconsulting.com about how leadership can engage in technology implementations.

First and foremost, executive sponsors should provide visible participation and regular communication about the project and they can assist with the prioritization of resources towards the effort providing guidance and support and helping to ensure accountability. Particularly for major projects that require a large reallocation of staff time to complete successfully, actively engaged executive sponsors may be the difference between being successful with an implementation or not. We frequently see that nonprofit organizations start with strong executive interaction in the project, but then sometimes that executive attention can wane over time, and there is a strong correlation between losing that executive focus on the implementation and implementation performance setbacks.

And as I said, you can read more about this on our site and you can find out how you can engage in a project as a leader, whether it’s at the C-level of a project or at a director level, or even at a manager level. Basically, what are people looking for from their leaders when it comes to technology projects and implementation specifically and how you can meet those needs?

So, what you see on screen here is an example of how you could define an executive steering committee. That’s one way that you can think about having executive interaction or engagement in technology implementations. It’s just good to get everybody on the same page in terms of who those people would be. This is an example from a real Salesforce implementation on the screen here, and what kinds of roles and responsibilities they would have over the course of the project and what their expected level of effort for those roles and responsibilities would be. This is actually an excerpt from a project charter, and we’ll get into what might be included in those charters in a few minutes when we talk about project planning and direction. We can also talk about how to best determined milestones and communications cadence as part of that. Thanks for that question, Jesse.

Identifying Business Benefits and Performance Measures

So, I want to move next to identifying business benefits and performance measures. So, a lot of clients ask—Build often says that over 50% of technology projects aren’t successful. That is an industry metric. It’s not one that Build came up with, but the question that logically comes after that is how you should define success? And so, we define success in technology projects, particularly implementations, as whether or not the project achieved the intended benefits not just in the short term, but for however long that intended benefit was to last. So, to ensure a project is unsuccessful or a failure when it doesn’t realize the intended benefits. And if it does realize the intended benefits, then it was successful. So, a good example is if your organization implements a new CRM system for the primary purpose of increasing revenue and revenue does increase, then it is considered a success. And if it does not increase the CRM project is probably going to be considered a failure.

One of the things that industry best practice indicates is that when you’re defining business benefits and performance measures another way to think about these as intended outcomes, it should be done as a collective effort and that includes all of the necessary stakeholders, and that those people should agree what purposeful actions during the implementation will ensure that those benefits are realized and sustained once the project ends. Also, to develop clear structures and models for performance measurement. An example of a business benefit would be to achieve a 10% increase in sustaining members. Technology can help support this, particularly if it does things like predict which donors will become sustainers and helps automate campaign outreach, but technology alone will not address that goal. So, purposeful actions during the implementation might include effective training of staff on how to use the features inside of the system and documenting new business processes to make sure they can be sustainably performed over time, including surviving potential employee turnover.

Performance Measurement

There are three different ways that I like to think about performance measurement. This is an excerpt from a project that I led not too long ago. It was for a Salesforce Communities based project that was branded “Engaged” and that’s why you see engage on the screen there. And we thought about engage in terms of its performance as a product, as a service, and then as a business accelerator. And in terms of the product, basically how well does the product support the business user’s ability to execute the processes—just does it do what it’s supposed to do at that basic level?

We also evaluated it as there’s a set of training resources, communications, and support resources that are sort of wrapped around this product and how well do these services support effective use of the product. So, that’s sort of measuring the effectiveness of change management and training and support relative to the product features themselves. And then finally, as the business accelerator, and this is where you would think about your typical business outcome goals like that 10% increase in sustaining members that I mentioned earlier. It can be challenging to figure out how to measure these things and what specifically to focus on, but it is important to define them at least in some way and make sure that they’re broadly understood and socialized so that everybody knows what the target is and they’re pushing it from the same side of the desk.

Business and Technical Requirements

Business and technical requirements definition is something that we could talk about all day. It ties into conversation about constituent journey mapping. You can find resources in regard to both in the Blog and Learning sections of the Build Consulting website, but basically what I want to highlight here is that I think somewhere in the nature—in the range of 50% of implementation projects fail in at least—in part due to poor or inaccurate development of business requirements. So, a business requirement example would be the ability to transfer a case record from one counselor to another within the same agency and the technical requirements might include a full data encryption for that data, both in transit and at unrest for all counselor, client, and case data. Business and technical requirements should be carefully documented and prioritized, and the reason why I emphasize both is because it’s very difficult to do technology implementation successfully if the organization views all of the business requirements of having equal priority. There are different ways to effectively prioritize requirements.

We have a particular method that we walk clients through, but it’s basically to indicate and support what features need to be available at what points within the implementation rollout and how they’re valued according to the business need. So, one of the reasons that Build Consulting prefers to get involved with client technology products during the early assessment and roadmap phases, because when we first get involved in the implementation phase, it often becomes apparent that the organization will need to back up and do some requirements definition in a more deeper, thorough manner before they can have a successful implementation.

And when a vendor is engaged already and the implementation is already moving, it can be very difficult for an organization to make the decision to push the pause button, then sort of step back in the process a little bit. But the benefits of doing that in a thorough and correct way can be great and we get good feedback on that from clients, and often also from the software vendors, who frequently tell us that our clients are better prepared to have successful software selections and implementations than any of their nonprofit customers. It’s common for us to hear feedback like, I’ve been working in this space for 15 years and this is the best RFP we’ve ever received. And that’s because our clients have already anticipated and wrestled with and made important requirement decisions prior to going ahead with the selection and implementation efforts.

I had mentioned constituent journey mapping previously. That’s a good lens through which to look at documenting business requirements. This is a human service focused constituent and journey process, just as an example of what that might look like. So basically, taking a client— in this case with a volunteer—a mentor that was providing them with small business mentoring services through the point where you’re prospecting for potential clients, you’re identifying them, moving them through some sort of registration and intake process, developing an engagement plan or a success plan for that individual or group, delivering that plan, running progress to reports, and measuring outcome. This is where your program performance or initiative, or process performance and monitoring and evaluation would take place. So, taking a look at each of your—the constituents that your organization serves both externally and internally mapping out the constituent journeys at some level, and then developing business requirements in support of each of those journey phases is a nice, comprehensive way to go about doing it.

And the question might be well, what does the documentation look like? So, it could be narrative documentation, it could be a visual documentation, or oftentimes some combination of the two. This is on screen here, an example of the type of business process mapping that we would often do in support of a phase of a constituent journey. In this case, it’s about being able to file applications for a loan for development of rural housing and a part of that process. And then, oftentimes it’s necessary to document the data requirements that go along with each of the steps in the process. So, you’re collecting information from the constituent as they step through the process and it’s important to understand how that data needs—what its purpose is and how it’s related to each other.

That can take the form of a data object relationship map with an accompanying narrative such as the map that you see on screen here. This is called Crow’s Feet Notation. It’s designed to help understand the different relationships between the major data components regardless of what system that they’re in. So, it’s a little bit of an abstraction and it can seem a little bit opaque if you’re not used to looking at Crow’s Feet Notation. Once the team gets the hang of looking at it and understanding it and sees it paired with some simple narrative statements, it can be really helpful to helping teams across different parts of the organization understand what data the organization has and how it relates to other pieces of data. And then you could also do a detailed data inventory to accompany that, and this is particularly helpful for either large scale system implementations, or when you’re doing integrations between systems, and you really need to understand what data is collected in which systems, how it’s stored, how it’s validated, and really having a comprehensive index of that because you can’t otherwise see it all in one place.

And then once you’re moving from business requirements into technical requirements, there might be some need to do some sort of a systems map or other form of technical documentation. This is just a high-level map that helps to understand the different parts of an integrated product to deliver services to clients in a sort of case management context. And then as another example, just targeting back to the earlier process mapping that I showed, these are some examples of how you could take a journey flow and associate it with additional sort of narrative detail for the business requirements and technical requirements. And this is something that we can train the organizations to do as well for themselves. One of the things that we take pride in as a consulting firm is using the projects, whether they be selections or assessments or implementations to help build capacity inside of client organizations, so that they’re better able to do for themselves the next time a related need arises.

Project Planning and Direction

So next, I’m going to talk a little bit about project planning and direction. One of the things that makes the most—is the biggest contributor success in implementation projects is having someone to lead the project that’s already successfully performed a similar project in a similar situation—experience is really key. And sometimes it can also be someone that’s led a project that hasn’t been fully successful in another situation but has had the opportunity to learn from that experience, but overall experience is key. Someone who can best anticipate and identify and help to mitigate the various challenges that will inevitably emerge over a particularly complex implementations will be better suited to do the project planning and direction for you. And then empowerment for the project leadership role is critical. If you have an unempowered project director or manager, it can be very difficult.

Stakeholders can feel free to ignore or disregard that person, or simply not prioritize their time towards the initiative. And to that point, one of the primary challenges at nonprofit organizations is successful time management and that can be a big problem for implementations, because often people are taking time away from their day jobs, so to speak, to participate in these projects. So, as an example, if you’re in a development team at a nonprofit, and you’re implementing a new CRM system, you’re going to have to take time away from your regular activities. And even if the amount of time that you need to contribute to the successful CRM implementation is quantified, if the rest of your time for your regular activities is not quantified and, in a way, it’s hard to know what needs to be taken off your plate in order to allow you to participate in the implementation process and that results in all kinds of project time crunches. One of the largest risks facing implementation projects are just bottlenecks that’s based on lack of staff availability to participate. So particularly organizations that tend to view from practical perspective, all staff time as being infinitely flexible, have a large amount of difficulty when it comes to conducting successful software implementations, particularly for major systems like a CRM or an ERP system.

Project Charters

So, one of the key tools for creating a good project in general and managing it well is to establish a Project Charter. What you see on the screen here is the table of contents for a project charter for a fairly robust initiative. They don’t all need to be this complex, but they can be anywhere from a couple of pages to maybe 12 to 15 pages for larger and more complex projects. But in general, what you want to make sure is to give the context, make sure that everybody’s on the same page in terms of what the project is supposed to achieve, and what its business drivers are. We mentioned those earlier, just to make sure everyone’s on the same page in terms of terminology and assumptions. It highlights the objectives for the project and the business benefits and then really start talking about risks. We’ll think about that in a moment as a separate subject. And then, you’re going to really lay out your approach to the implementation of the project, the timeline, and the project plan, which I’ll show an example of in a moment, as well as roles and responsibilities associated with the project and the time commitments associated with those.

So in general, it can be a good exercise for organizations to put together, at least a minimal project charter for all types of projects. Oftentimes nonprofit organizations will say to us, well, you know, we don’t really have clearly defined projects, particularly for our internal initiatives. And as I said earlier, if projects aren’t well planned out and their time isn’t properly allocated for them or that time isn’t measured or evaluated relative to other time commitments, it can result in a lot of internal projects, particularly that never get fully across the finish line, or just sort of fizzle out and you want to make sure that isn’t the case with your implementations.

Project Plan

Somebody had asked in the registration questions box an example of a—basically a project plan for a CRM implementation. And so, an example of that at a very high level is on your screen here, and basically you can just run your eyes over the steps. First is just to prepare and plan, get everybody ready for what’s coming, go through that process and data model design, which I mentioned earlier—some form of that and determining what the appropriate level of detail is for that, is where having an experienced project leader can come in. Then we recommend an iterative system configuration or a system development and user acceptance testing. And we’ll be touching on how to—what are the key elements of running a collaborative, iterative implementation process in a moment. Change management planning and then the rollout itself and then finally some level of intensive support, which I’ll talk about in a little bit more detail in a moment.

So those are—this is an example of one way, which we would outline a project plan for an implementation at a high level. It varies according to the nature of the project, but these are some of the most consistent elements. And I thought we’d just take a little bit of time to go through them with an additional layer of detail here.

So, in the preparation or this prepare and plan phase, you want to first identify the key internal stakeholders to engage in the project. And those would be people that are responsible or accountable for the outcomes, people that need to be consulted in order to effectively determine the business and technical requirements for the system, and also those that just need to be communicated with and kept informed throughout the process.

So that’s just sort of applying a traditional RACI, responsible, accountable, consulted, informed model to sort of thinking through who the key stakeholders might be—to engage in a project. This was—this project plan was taking from a charter that was primarily focusing on internal stakeholders, but you also may have external stakeholders that you would like to engage in a project as well. And a good example of that might be if you’re developing a constituent facing technology system, and do you want to really engage those constituents, whether they be volunteers or donors in the requirements development, based on their experience of the organization and its current systems to date and also perhaps, engage with them in future testing of the product. So even though it says internal stakeholders on the screen here, it could be a combination of internal and external stakeholders, and then you’re going to do basically a stakeholder analysis.

And what that primarily is intended to do is capture the primary needs and sort of viewpoints of the individual stakeholders that are participating or the groups of stakeholders, as well as to help start to identify which business processes impact the individual stakeholders and to what degree. And that is really the start of doing a change impact analysis, which can be very helpful for evaluating how to do your communications training and support later on, both prior to, during and after your rollout effort. And then set up finally validate the project approach and process and then do the setup for project management tools and mechanisms, which we’ll also be talking about in a few minutes.

And then you want to do the process and data model design. In this case, we were going to do a visual process map and narratives, the master data model, and then in this particular project, it was at this point that we were actually going to kick off the project with the stakeholders. And the reason for that was that we had already done an extensive constituent journey mapping project with this client as part of a previous effort. So, they were already engaged. So, we didn’t need to do the kickoff with them at the very start of the project, just when we had already completed part of the body of work that we were going to bring back to them in terms of the process and data model designer reengaged with them at that point. So, ordinarily you’d see that kickoff during the prepare and plan a section of the project.

And then of course you want to review those maps and narratives with the key stakeholders and then refine as needed to create the final design documentation, and I kind of final in air quotes. It is the final for this part of the project. Collaborative, iterative, design processes sometimes also called Agile processes, take into accounted feedback and or responsive to it throughout. So, this just means final for this particular stage. And then as you see here, going through an iterative system configuration and user acceptance testing process and everything that’s entailed in that, and then doing the change management planning.

Now the change management planning is not necessarily a linear step here in that you could do the change management planning while you are also doing the previous iterative system configuration and user acceptance testing here. But your change management planning really can’t be fully developed until you really know for sure what the system is going to be able to deliver and how it’s going to deliver it. It could be because, it’s at that point that you really are able to tie down what the impact is of the change on the users and the other stakeholders. So, at that point you’d also be looking to create your change management plans. And we’ll talk about that in a little more detail in a minute, and then actually do the rollout. A key aspect of a rollout is making sure that not just that stakeholders understand how to use the tool, but also that they have any necessary professional development if they have a changing role with a new system—a changing business role and we’ll talk about that a little bit in a few minutes as well. And then you’re going through the steps of a traditional rollout process.

Even with the level of detail that’s here, this is a pretty high level of summary for a project plan. It’s just at the level necessary to get all stakeholders on the same page for a project charter review and kickoff. There would need to be additional depth of detail to actually manage the project. And then in terms of support, I always like to highlight from my clients early on that they should prepare for some sort of intensive support for a certain period of time after the rollout. So, it’s just a reminder that the level of support that users are going to need after the rollout is probably going to be at a higher level and the support that they needed with the older system that, with which they were already familiar. That’s not always the case, but it’s most frequently the case. So, it’s good to budget and plan for an intensive support period that then tapers off until things get back closer to baseline.

And then finally, just to confirm another point from earlier, something that the project charter should take into consideration is staffing and time commitments and I’m not going to spend a lot of time on that right now, because I’ve spent so much time on it already. This is just a visual example of how you might articulate what those are, what the roles are, who would be staffing those roles, what their key responsibilities would be, what success looks like, and then what level of hours’ worth of implementation would be needed on a weekly basis across the implementation time period. And this was a particularly lengthy implementation because we are rolling it out to—rolling the system out to over 9,000 users nationally, and it was done in phases over a period of time to make it more manageable.

Risk Assessment

So, I would say that one of the least consistently performed aspects of a good, successful implementation project is doing an upfront advance risk assessment. Some folks actually would call this a pre-mortem and essentially what the exercise entails is thinking in advance of all of the ways that the project could go wrong, which is another way of saying you just need to identify the potential challenges or risks for the projects in advance, including each one source, the probability of it occurring, and its potential impact on project costs, schedule, or performance. And it also introduces a mitigation or response plan for each risk. And it’s also important to note that risk assessments are not one and done propositions. And once you’ve put a risk assessment together, it needs to be revisited and updated to track the status of existing risks and add new risks as they enter the picture.

So, this is an example of a slide from findings that we had done for a client in advance of them entering into a large financial planning and analysis tool selection, and implementation project. And it basically was just to provide them with feedback based on their—the interviews that we do with our stakeholders, that oftentimes new technology products and initiatives, as well as projects and initiatives in general, were launched without a sufficient analysis of capacity and change readiness. So, this is an example of a risk that might—a broadly stated risk that might be applicable to an implementation effort. This is an example of one potential way that you could keep track of your risks. You could do this in Excel or in a Word document even, or in a Google Doc. This is just an example of how it’s organized in a system called Teamwork Projects, which is a similar to Asana or some other project management tools.

And the reason I use it is because it’s a nice visual and grid of how to keep a risk register. You can see here the source, probability impact, impact areas, and then the mitigation and response plan, as I said. And this is another area where having experienced project leadership can come in handy, because they’ve been there and done that. So, they can help anticipate not just the potential opportunities that are in the project, but also the potential challenges or risks before they emerge and at least, to have a good plan in place or a provisional set of steps to account for that. So, it’s just good to make sure that you think about risks in advance. It’s not a fun thing to do, but it could really save you later on because, especially in large complex implementations, things will go wrong at some point and you’ll need to try to be prepared, to be responsive and be able to route your project around that challenge.

Change Management

So now I would like to talk a little bit about change management. This is becoming an increasingly large aspect of Build’s work over the past three or four years. And it was, I mean, we’re focused on nonprofit transformation. That’s our mission. So, transformation requires change, and it makes sense that change management be a key part of any transformation. Technology change always require some sort of behavioral change. There’s no such thing as a technology change project that is not also an organizational change project. And the practice of change management helps define the change that is coming, assess its impacts, as I said earlier on the various roles in the organization, and helps prepare those roles for impact. As I’ve mentioned, we have resources on our site that you can access for this and that go along with different parts of this presentation, one of which is a Change Impact Analysis tool and template.

And so, one of the things that people ask, well is change management about making everybody happy and the answer is no. Change management is not about making everybody happy. It is about helping to prepare them for the change. Although obviously we would prefer that people be happy. And then another question that people often ask us, well how do I know if my project needs change management? And the answer to that is, if your implementation project will require users to change their behavior in order to use the effect—the tool effectively, then yes, some degree of change management will be necessary.

And what you see on screen here is a Build Change Management Framework, it’s based in part on industry set of practices that are mostly championed by an organization called Prosci. This is sort of a simple distillation of a number of change management industry best practices from different sources, to make them more accessible and usable for both us and for our clients. It basically identifies at a high level what you need to do to have effective change management. I just want to try—your attention to the third stage, which is activate leadership or also sometimes called leadership alignment, and the communicate, and train and support sections. These are what most people think about when they think about how to have effective projects in terms of managing all of the communication and support that needs to go around the rollout effort.

And so, if you asked most people that were about to engage in an implementation project at a nonprofit, does leadership need to be aligned? Of course, they do. Do we need to have good communication? Of course, yes. Do we need to provide training? Yes. Do we need to provide support? Yes. So, there’s not a lot of disagreement there, but without the prior two steps of making sure that we define exactly what the changes are that are coming with the new system and identifying who is impacted in what ways and how much, it becomes very difficult to really dial in on how specific—how specifically the leadership needs to be activated. What are the key issues, the key points of emphasis, and how can they contribute around what key issues do we need to be communicating with stakeholders in different ways?

How are we going to prioritize finite training and support resources to what areas of functionality, etcetera, etcetera? So, this is just a way to think about and approach doing the business of change management more effectively. And what you see on the screen now is a Change Impact Analysis. It’s done on a bare evaded version of our change—sort of impact analysis template that you can find on our website and in the green areas here, you’re basically looking at the define the change section. It’s broken down by constituent journey process area or stage, and then it identifies—identifying the impact in the blue background fields there to the right. So, what role is the impacted? What’s the description of that impact and to what degree?

So, this was customized to the needs of this particular client and project. And as I said, the tool—the template is available for download in the learning section of our website for free. There’s an initial sheet of the template, which is an Excel document that says how it should be used. And in terms of determining what level of detail to describe the change, that’s something that varies from project to project based on its size and complexity, and the nature of your team. It’s something that you might just have to learn through experience—try it at a certain level of granularity, see how that’s working out and then adjust as needed.

Collaborative, Iterative Approach

So, I alluded a couple of times to the importance of taking a collaborative, iterative approach and mentioned that this is sometimes called an Agile process. Studies show that organizations that take this sort of open and collaborative approach, that’s focused on incremental design and implementation processes show a greater potential for success. Excuse me. This style also helps keep all of the key stakeholders engaged throughout the many critical decisions and reviews, and approval process that can take place within an implementation project from the start of the requirements discovery, all the way through post implementation phases sometimes.

So, one of the things to just keep in mind when you’re thinking about moving to a more agile or iterative approach for implementation projects is that, when a vendor is selected to help implement a system and that vendor uses an agile approach, it’s important that that vendor has the ability to be flexible when working with an organization that has never, or never successfully been through a true agile process. So, introducing an agile process to an organization that is not used to working in that style can be a major culture clash that can cause projects to get bogged down or sometimes even collapsed entirely. So, in agile projects for example, it is very important that stakeholders are frequently available to participate in design reviews and user testing, sometimes on a weekly basis. This also means that committing the necessary time—also means committing the necessary time to make business decisions within accelerated timeframes compared to what the organization might be typically used to.

So, it’s important that you apply agile principles in a way that will truly work for each organization and for your organization, particularly. Especially as I said, if it’s never done that type of thing before.

So, to add some additional clarity around the key elements of what we mean by this collaborative and iterative approach, first that stakeholders are engaged as I said, throughout every part of the process. You’re going to define what requirements are going to drive the system, design the system, build the system, and then do testing and roll out. And the process is responsive to stakeholder feedback throughout, and then you’re doing the sort of Define, Design, Build, Test, Rollout process to the extent possible by batching groups of related or prioritize system functionality together, and then delivering them to the organization in manageable amounts in that order of priority.

Now this sort of design and build language is more common to software development projects. You might translate that into design, configure for a system that you’re primarily implementing using screen configuration choices as opposed to something that requires any sort of custom design and software development. Either way, the goal is to try to make sure that you have good stakeholder engagement throughout. As the configuration or the development of the system is built out, people have an opportunity to engage with it and provide feedback that will help inform future iterative development. And then that ultimately, when you are delivering the product or the solution to your users, that you’re doing it in a—in manageable chunks.

Supportive Tools

So, I believe this is the last item to talk about, and I’m just going to cover it quickly to make sure we have a little time for any follow-up questions at the end, and that is the idea of leveraging supportive tools. And one of the characteristics of successful implementation projects is that they will create a digital goal—digital project collaboration environment that manages and socializes critical information related to the project. We prefer Teamwork Projects, as I mentioned before to tools like Basecamp, Asana or MS Project, but you can really use whatever suits the bill for your particular organization. The key is just to have a functional space that is universally adopted by all key project participants and in which folks can be on the same page in regard to milestones, tasks, agendas, notes, risks, critical conversations, and pretty much any information that is needed for the project to be successful. It could be a Slack channel, could be a Microsoft Teams and some channels, or what have you—could just be a set of shared documents.

This is the best way to make sure that everybody is up to date throughout the entire project. It’s good to emphasize these using the information in the system as a live point of reference within team meetings and to drive performance reporting to stakeholders, because otherwise the information in the project management tool or tools can tend to get out of date pretty quickly. And this is just a visual example of sort of a Status Dashboard, again this is from Teamwork Projects, and you can see what kind of functionality it covers. Then this is just an example of a Project Task Management for a rollout—a single rollout wave for an implementation project. You can see sandbox testing, kickoff sessions, different kinds of training and orientation sessions for the people that are going to be using the systems, listening sessions, etcetera, etcetera, and this was for a large and complex rollout.

Professional Skills Development

There was one other thing that I wanted to cover that I forgot the professional skills development I’ll just touch on this quickly. So, technology implementations, as I said earlier, particularly large and complex ones often require team members in the org to step into roles for which they’re not fully equipped. The most successful projects, take this into consideration and then take the steps to make sure the team members are provided with the professional skills development they’re required to be successful in those roles. And as far as supporting the implementation itself, special emphasis should be given to planning, communication, teamwork, time management, and change your adaptation skills. And so, you can see on this slide some of the new roles that might emerge in the course of implementing a new system. You might have a new systems administrator or somebody that’s assuming system administration responsibilities and same thing for data management.

You could have some of that needs to become a trainer or some sort of advocate, or sort of sponsor of best practices. You might need somebody to serve in a change management role on a temporary basis, and you also might need a Project Manager or Technical Project Manager to help support the project. If you’re going to staff these rules using in-house people that maybe haven’t been familiar with these things, professional development will be necessary for them to excel. And then again, obviously there will be new tools for existing roles if you’re moving from one system to another and there’ll be professional development that’s needed around those specific tools. So as an example, when the development staff are using Salesforce in the future, rather than the Raiser’s Edge or the accounting team is replacing Dynamics GP with Intacct and some of the other examples that you can see on screen here.

And I think the important thing is not just that they understand not just how to use the tools, but oftentimes there are new processes or new ways of business that are going to be accomplished and moving—or required and moving from one tool to the other. So for example, if you’re using a new tool that allows you to do allocations in the accounting system in a new way that you didn’t have before because it wasn’t a possibility in the old system, your staff might need some professional development and best practices for how to do allocations, not just how to do use the allocations functionality in the new tool. So, you can probably think of other examples from systems that you’ve participated in implementations, where over the years all of those little things that people need to develop an understanding of, or a skill set for in order to be effective with the new tool.

Q&A

So, we covered a whole ton of ground today. I really appreciate you sticking with me throughout this. If there’s anything that we didn’t cover today that you’d like information on—if you’d like to, for example, dig deeper in terms of communication flow or cadence, I’m happy to have a follow-up call or email exchange with you. If you just want to chat further about anything that we’ve covered here, I’m happy to do so. You can reach out to me on LinkedIn or via email.  And you can also, as I said, go to our website for the learning resources. I can also always be reached through the contact form on our website if you’d like to do that. If you would put in the body of the message that the messages for me and it will be routed to me, and I’ll be able to respond to it. And I’ll be happy to share examples of communications plans or how a communication plan was incorporated into a change management framework, for the person that asked that question. We didn’t have time to get into that in too much depth today, but again, happy to do a specific follow-up.

And we do have a couple of minutes for additional questions here at the end. So, if you have any questions, feel free to add them to the chat or the Q&A areas within Zoom.

I will say that one question I frequently get asked about is sort of how to create complete budgets for future software implementation projects, sort of what are the things that need to be considered and sort of the total cost of ownership when you’re thinking about both the implementation project itself and the cost across maybe a three-year lifespan for the system post-implementation. We do have some information that I can share about that in a future conversation. That’s not something that we were able to touch on today. So, if that was top of mind for you, you can feel free to follow up with me on that. And another question that I get oftentimes is, as I said earlier, it’s about—to what extent good leadership can make or break a technology implementation project?

As I said earlier, it has a strong, positive effect when the leaders are effectively engaged. You know, as we say, it always comes back to leadership. We have an Information Strategy Framework that we use to sort of help organizations assess their technology landscape and their technology readiness. It starts with leadership and policy—or leadership and governance, and then goes to operations and then to processes, data and technology. Leadership is intentionally first and because everything flows from a leadership. Organizational strategy, culture, and discipline flows from leadership and sets the stage for how operations function, which in turn lends effectiveness to the way the organization thinks about and designs and develops its processes and manages its data. And those are kind of all the things that you need to get right upstream of technology.

So, technology is intentionally last because those organizational aspects really need to be got right first in order to have successful implementations that deliver the intended return on investment over a period of time. And we’re very fortunate to have many great nonprofit organizations in the sector with great leadership that are capable of doing that. Frequently, it’s just that executives get pulled in a lot of different directions at once and they don’t know how to give the effective level of engagement and governance to data and technology projects. So, there’s always opportunity for growth there, including for myself as someone who serves as a part-time CIO for different nonprofit organizations and again, there’s information on our site for that as well. Well, would that we’re at time. So, thank you again very much for engaging in this webinar today, and I hope you have a great rest of your week. Take care. Bye.