00:00:00 Introduction

Hello, everyone. We're really excited to have you here today in the fourth of our series on getting started with ActivityInfo. If you've joined us for the first three sessions, congratulations on making it this far, all the way to the fourth in our series. We hope that you'll get some good insights in this session today to round out the information that you've learned so far throughout this series.

I'm quite excited to share with you today some insights based on our experience in supporting many organizations of all shapes and sizes as part of the customer success team here at ActivityInfo, helping organizations to actually roll out ActivityInfo within their teams. I'm also excited to share some learnings from my own personal experience, having led the rollout of ActivityInfo in my old job having worked as an M&E officer for the Pilipinas Shell Foundation. So hopefully you learn a thing or two from these experiences that you can take away and apply to your own experience as you roll out ActivityInfo within your own organizations.

So what are we going to cover today? Three main things. One is just a bit of context setting talking about change management and why that's so important in rolling out ActivityInfo. And in general, any new system to an organization or to any team. We'll talk about the central role that change management should play in your rollout and how we can apply that in this process. Secondly, we'll then talk about the practical matter of how to actually roll out ActivityInfo to your team. So we'll go over a four-step framework to make sure that you are implementing all of the necessary steps to ensure a successful rollout. And then finally, you will take a look at some common pitfalls that you might want to watch out for in this rollout process, and we'll offer some mitigation strategies that you can consider to help overcome those challenges.

00:02:35 Change management

So without any further ado, let's get started on this first section on change management. First off, you might ask ourselves, why should we think about change management in the first place at this point? Especially if you attended the last two sessions where we covered database design and creating reports, at this point, you might now have a well-functioning database already and you're probably thinking you should be ready to launch at this point, right? But the technological aspect of information management systems and databases actually represents only one part of a bigger system that you're actually trying to launch.

So we think that you have to consider the entire, the more comprehensive system that comprises a few more components beyond just the technology. So in any kind of system, it's important to think about these three pillars: technology, people, and process. Within each of these components, there are many more specific functional areas that your database impacts. Because as we covered in our very first session about how ActivityInfo touches the whole data lifecycle in your organization, rolling out this new system will actually have an impact on many other areas of your organization, including the implementation team, other supporting functions including finance, perhaps. Certainly, senior management will have a huge interest in seeing the success of this rollout, and also external stakeholders, your donors, your partners, who will probably benefit from the reports that the system will generate.

So there are all these things that you need to consider across these three pillars of technology, process, and people to suggest that what you're trying to launch at this point is quite a significant thing. It's really an entire system. And throughout the rest of the presentation, I'll be using the term system quite a bit to describe the entirety of these components. Because we are talking about such an important system that you're trying to launch, this represents a significant change in the way that your organization does things, in the way that your organization handles data. Because of the significance of what you're trying to achieve, we should be wary about possible resistance to this change. And in fact, I would even go so far as to say that you should expect at least some resistance to change. So change management comes into the picture in that regard that because we should be expecting at least some resistance, we need to be able to manage that change effectively.

Now let's talk a bit more about this concept of resistance to change. The first thing I'll say on this is that it's not necessarily wrong for people to resist change. There are many valid reasons why people resist change in the first place. So let's take a look at some of these reasons. First up, change might require a big upfront investment of time and effort that could take away from other pressing priorities. Another reason could be that there are some established ways of working that people have tended to rely on and are deeply ingrained in their day-to-day. So the users of your new system might be in this place where they're still reliant on these old ways of working to perform their tasks.

Another reason could be that some previous experiences have colored the way that people think about any changes in this particular area. If those previous experiences ended up in failure or had less than ideal results, then that might breed some negative expectations about the change that you're trying to implement at this point in time. Yet another reason could be that this change might represent a loss of control among some of your users whom you expect to use a system. It could be that you're introducing a new workflow or a change in areas of responsibility, and that might link to certain people not having the control that they used to have in their previous roles. That's always something that could be quite threatening to some people and a reason why they might resist this change.

On that note, another reason could be just that this change that you're trying to introduce could simply be perceived as a threat to someone, especially someone who might hold some influence in some area. Perhaps they perceive that this change means that their roles are being undermined in some way, even though in reality that is not what you had intended. But you can't remove that possibility that some people might perceive it in such a way. And another reason just to round out this list could be just simply that some people might resist things that they don't know enough about. There's always the fear of the unknown. If something represents something that is unfamiliar, there's always a sense of not sure what this means for me, and that always comes with a sense of discomfort about or reluctance to accept this change that you're trying to introduce.

It's important to acknowledge all of these underlying causes of resistance upfront and factor these into your rollout strategy. Launching a new information management system cannot happen in isolation. It needs to be done with a comprehensive change management approach which is crucial to overcome these pockets of potential resistance.

00:11:45 Best practices for change management

Having established the importance of change management, let's take a look at some best practices to keep in mind. The first is knowing your stakeholders. So it's important to first of all, identify who the important stakeholders are who have an interest in seeing the system launch successfully in your organization. Of course, the stakeholders include those people who you expect to actually use the system, who will be in there entering records into the forms, who will be administering the database, consuming the reports, and so on. But also think about others who may not be the direct users of the system but in some way would benefit from active usage of the system. These include senior leaders who need to make decisions based on the data that your system will generate. These could be donors who are expecting regular reporting on your program which is based on the data that is captured in your database. So make sure to identify all of these important stakeholders and really have a deep understanding of what they hope to see, perhaps what pain points they had from your previous system, so that you can incorporate all of those considerations in the way that you design your system and in the way that you launch it to your organization.

Second best practice is to identify champions and recruit allies. Especially important to do this early on in the process so that you can amplify the efforts that you're doing. Especially if you're in a large organization that has many different departments, many different functional areas, it can be an uphill battle for you to convince everyone of the value of your new system if you're doing it all on your own. So it's hugely valuable to identify champions who can advocate on your behalf, communicate the value of the change that you're trying to implement, and even help you with implementing some tasks related to the rollout as well.

Third is all about communication. So communicate often and maintain open lines of communication across your entire rollout process. It's important to make sure that you're communicating enough information to all of your stakeholders so that everyone is in the loop on the progress of your rollout. Everyone has a sense of what to expect and that helps to establish a level of comfort across all of your different stakeholders and gives them some reassurance that we're actually heading in the right way.

And then one final best practice that I put forward to you is to celebrate wins throughout this process. Celebrating wins, even small wins early on, is really helpful in generating that momentum upfront and then sustaining that momentum throughout the life of the implementation of this new system. In some implementations, especially in complex implementations, the whole rollout process can take several months, even up to a year, and it can be quite demotivating to not see any progress when you're expecting that the final output will happen a year down the line. So even if it's small things like adding the first few records to a small pilot project that you've tested on, creating your first report, these are really important wins that you can share with your organization, with the rest of your stakeholders, that can provide some early evidence that actually you're achieving the outcomes that you wanted to achieve by rolling out this new system.

Now, all of these best practices that we are putting forward to you today, they're all rooted in this idea of building trust, especially at the beginning of the rollout process, and also reinforcing that trust all throughout. All of these practices help to build trust in you as the initiator of this change in your organization, that you know what you're doing, that you have the best interests of the organization at heart, and that's why you're launching this new system. And also it breeds trust in the entire process that the activities that you are implementing are actually the right activities that will help ensure a successful implementation and adoption of the new system. So this trust will go a long way, really, in getting everyone on board and sailing on that ship of change with you.

00:17:55 How to roll out ActivityInfo to your team

Now that we've covered a bit about the principles around change management, why it's important to think about, now we can go into this next section, the more practical matter of how to actually roll out ActivityInfo to your team. Now, before we even begin to roll out and think about the practical steps, the very first thing that we need to do at this stage is to define your why. So this is really important to help get everyone on the same page. It helps to crystallize the reason for why you've launched such a significant effort to help your organization improve the way that it handles data.

What does this actually look like in practice? The main recommendation that I can give to you on this is to be very specific with the results that you wish to achieve. So what is the overall, the ultimate goal that you want to achieve? And in that statement, clearly explain what difference should the change make. So on this slide, I'd like to share an example from a hypothetical organization, ABC organization, and the kind of objective that they want to achieve by rolling out ActivityInfo. In this example, ABC organization is rolling out ActivityInfo to reduce the time it takes for our staff to complete the reports so that we can make decisions more quickly. So this is a great "why" statement that helps to clarify in people's minds what difference they're trying to make. Perhaps in the previous setup, the reporting process was so cumbersome that it took a lot of effort, it took a lot of people's time to complete, and it really slowed down that decision-making process. And now with ActivityInfo in place, it's hoped that ABC organization can actually streamline that process so that they can make decisions about other programs more quickly.

So in this section, I want to present to you this four-stage framework that we tend to see organizations follow in their rollout of ActivityInfo. So I'll take you through each of these stages in detail, and for each stage I'll explain what you'll need to do, what you're trying to achieve, and along the way we'll share some resources that might be helpful for you in carrying out that stage.

00:22:00 Stage 1: Assessment

Let's start with the first stage: assessment. So this stage is all about understanding the current state of data management within your organization, understanding what your baseline is, identifying any pain points that your program officers might have, your M&E officers or information management officers might have in the way that they work with data, and then organizing all of those insights to then orient yourself towards a way forward in how you want to design your system.

So what are your key tasks? In this stage, you might want to do some consultations with stakeholders, schedule some individual interviews with key people who you would find would be able to provide you some really useful insights about challenges and what they'd like to see. You can also review some existing documentation. Take a look at any existing data workflow process maps documentation, existing roles and responsibilities, existing reports or things like results frameworks or logical frameworks that give you a sense of what data exists and how data needs to be linked together and how data needs to flow through your organization so you have an understanding of what that baseline looks like.

On that note, actually measure some baseline figures for those key indicators that you would like to change as part of launching this new system. So think about what metrics would be useful for you to compare before and after you launch this new system. So these can include things like the time it takes for you to create a report for a donor. This can include other things like the number of errors that result as part of your reporting process that you need to correct for. So it's really helpful to actually capture the metrics around these that you can then come back to after you've launched your new system.

Another important task here is to determine your readiness for change. It could very well be that the time for you to actually launch this new system is not now or in the next week. It could be that there are some other tasks that you need to have in place that you need to complete for the conditions to be right for you to actually launch the system. So this includes things like: does your staff have the capacity and the required capabilities to actually utilize such a system as ActivityInfo? Do you have the appropriate structures in place to facilitate the new workflows that you need to implement as part of your new database? So it could very well be that some things need to happen first before you're able to launch your new system.

And then related to that, this final task here is to determine the resource requirements that you will need to actually go about operationalizing your new system. And when we talk about resource requirements, these include time, costs, and personnel, and also important to consider internal and external resources that you have available. So certainly when it comes to personnel, you'll have your staff within your organization, your M&E officers, your information management officers who do a lot of the heavy lifting, but also consider what external resources are available to you that you can draw on to meet your requirements. As part of this, you can certainly draw on the support that our team provides to our customers within the customer success team. Here at ActivityInfo, we do offer onboarding support to organizations who need that extra guidance to ensure that the database is configured correctly and that you guys are launching a system that really meets the needs of your stakeholders.

So once you've done those key tasks in this stage, the outputs that you expect to generate at the end of this stage are a list of detailed requirements that will inform what you're actually going to develop in this system. And it's important that this isn't just a long laundry list of the things that you would like to set up in your forms and in your reports. It's important to actually prioritize this list as well because you will likely realize in your assessment of your existing resources, that resources are finite. And so you'll want to have a prioritized list so that you can allocate your finite resources towards those elements of your system that are most important to you. The second output here is a work plan for implementation. So hand in hand with your detailed list of requirements is a plan for how you're going to develop all of those different elements and deliver on all of those different requirements.

00:29:20 Stage 2: Design

Then we get to stage two, the design stage. So this stage is all about taking those requirements that you identified in stage one and actually making it happen and turning that into a reality. So this is where you actually go about building the database, building those reports. But let's take a closer look at the key tasks here. So naturally, the big part here is the technological component, right? The configuration of your actual database. But we can't forget the other main components of an information management system. As we covered at the top of this presentation, there's process and people.

So under process, you'll need to think about the procedures that go along with using this new database. And part of that is documenting what those procedures should look like. Then we get to people. So this is all about thinking about the structures that should surround the use of ActivityInfo in your new database. Who are the people who are involved with the different steps in your data workflow? What are their exact roles and what are their exact responsibilities? It could very well be that your previous structures and your previous roles and responsibilities are well equipped and still quite relevant to the new system that you are rolling out. But in some cases, it could mean quite a drastic change in structures and change in roles and responsibilities. So it's important to identify how these structures and roles and responsibilities will be changing. And if there's a need to develop new structures, that's something that you'll need to do in this stage of the process.

Now, following those three main components, once you've built the technology, you've thought about the process and you consider the people aspects as well. Then you'll need to align everything and make sure that what you've built meets the needs of all of your stakeholders and is well aligned with any other procedures that your organization currently does. As you mentioned before, there are touch points with other functional areas. Finance for example, make sure that you're aligning the data requirements with your finance team as necessary. Then there's the matter of validating that what you've actually built meets all of your stakeholders' needs. And then finally testing that all of the different components actually work in practice in the real world. So it's useful to invite a few potential users to actually test those forms that you built, test those reports that you've built to make sure that the data looks as you had expected.

And then the final component here under the design stage is to monitor your usage of resources. So you've identified resources in stage one and so you should be aware about how much resources you have remaining throughout the duration of this design stage. And it's really important to flag early on. If you're noticing that you're consuming those resources faster than you've anticipated and that there might be a shortage coming up soon, you may realize that you need to draw in more people to help you finish the configuration of your database or you might need to purchase additional licenses, for example. So make sure to flag these moments early on and raise them to the relevant decision-makers who will be able to make those decisions about maybe reallocating some resources from elsewhere or unlocking some new resources for you to help you see that rollout process through to completion.

So once you've done these tasks, then the output for this stage will be a functional system that you should be ready to launch. Some resources that we have available for our customers at this stage: we have done a webinar in the past about some database design principles. So this should certainly help you in that technological component of configuring an optimal database for your organization. So do check that out if you haven't already.

00:34:50 Stage 3: Launch

Now we can move into the next stage, the launch stage. So the launch stage is when you actually go out and introduce the system to your team, make them aware of this new system that you've built and actually then invite them to start using the new system. So what are the key tasks here? You might start out with an internal launch event where you invite all of your key stakeholders, your end users, and basically let them know that hey, there's this new system that we are now going to use and here's how we're going to use it for our organization.

Following that event, you might run a series of training and onboarding sessions to actually instruct your end users about how to use the system according to those workflows that you've defined. And it could be that you'll need to carry out training across a whole series of different sessions, maybe targeted at different user groups, maybe targeting different program areas in your organization or different functional areas. So you might want to come up with a more comprehensive training program that charts out all these different training sessions that need to happen. Related to that will be the dissemination of the resources that will be useful for your end users as they start to use this new system. So things like manuals, cheat sheets, guides for how to do certain workflows, and even links to the documentation resources that we have on the ActivityInfo website. These are all things that you'll want to disseminate quite widely at this stage.

Now a point here I want to make as part of this stage is that you should consider doing a pilot or a phased rollout. And we do see many of our organizations, our customers do this kind of approach to their rollout, especially if you are a large organization that wants to ultimately roll out ActivityInfo across your entire organization. There's a lot of value in starting out with just a small pilot in the first instance. That way you can mitigate the risks and keep contained any issues that might arise from that initial rollout. This will help you to generate some early learnings that will help you then improve your implementation of ActivityInfo that you can then apply to a more general rollout to the rest of your organization. So that's something to keep in mind. And we do encourage you to think about whether that pilot or phased approach is right for your own organization.

So the main output at this stage is that staff are empowered to use the new system, that they have the know-how to actually use the system in the way that you expect them to. So some resources that we have available here for this stage: we've got a blog post on some tips for effective capacity development and another blog post on some best practices for developing internal training materials. So we do encourage you to check out those resources as you progress with this stage of your rollout.

00:38:40 Stage 4: Adoption

Now we get to the final stage, which is adoption. So this is the period after which you formally launched your system to your users. This is the stage now where your end users are now actively using the system. They're submitting records into your forms, they are checking the reports, and so on. So this is a crucial stage in the first couple of weeks, first couple of months following your official launch. We do recommend that you implement a period of what we call hypercare in those first few weeks from the launch where you provide an elevated level of attention in providing support to your end users just to make sure that you're responding to any questions, any concerns that they have in a very timely manner.

So what are some of the key tasks that you need to think about for this stage? Monitoring their usage, actually checking to see that the records are being added in the frequency that you wanted to, and part of that is collecting feedback from your end users, actually talking to them and asking them how their experience has been in using your new system. Then, beyond monitoring usage and collecting that feedback comes a more thorough evaluation of whether or not you've actually achieved the objectives that you stated at the beginning of this process. So at this stage, it's helpful to come back to your "why" statement and come back to those metrics that you measured in your baseline and see whether you've achieved any differences and any changes in those measures at this point in time.

Next, you'll want to make sure you're troubleshooting any issues that have come up and make any necessary adjustments to your configuration of your forms or your reports. It's very likely that what you've rolled out in your launch stage is not the perfect system, not the perfect configuration, and that's okay. ActivityInfo was designed to be a flexible tool that can adapt and evolve with your needs. So do feel confident in that you can make adjustments if they're necessary.

Then final task here is to communicate your results. So communicate the progress of how you're now able to create reports more quickly, the kind of new insights that you've been able to generate thanks to this new system. Make sure that your end users and all of the stakeholders are aware that the system is actually working or even if it's not working as expected. It's also important to communicate any issues or roadblocks that you have been encountering because then you'll be able to draw on other support from other parts of the organization that might be able to help you with resolving some of those issues that you've encountered. So the output that you want to see at the end of this stage is sustained usage of the system according to your expectations.

00:42:30 Common pitfalls and mitigation strategies

So now at this point we've covered all of the four stages of rolling out your new system to your team. So in this final section of the presentation, I just want to cover a few common pitfalls and offer some mitigation strategies that you might consider.

First is a lack of leadership support. So this is something that could happen quite often and would lead to some challenges along the way in your rollout, especially when you get some resistance from some pockets within your organization. If you don't have the support of a leader, it's hard for you to win the hearts and minds of those people who are resisting this change. So it's very valuable for you to have that leadership support upfront. So a practical thing that you can do is to actually identify a senior person in your organization and recruit them to be a sponsor of this project. And that involves them actually going out into your organization and expressing their support of this project and advocating on your behalf and directing, orienting all of those different stakeholder groups towards your vision and even allocating the resources that you need to implement this change.

Secondly, another common pitfall is going alone. So you might think that you've got all of the technical know-how to actually implement a new database yourself. So you might feel confident that you can do it all on your own. But something that would be very useful is to actually recruit other people along this journey with you so that you can spread that workload among more people and reduce that risk of burning yourself out in this process. And if not for anything else, it just is simply valuable to have other people who can speak on your behalf, who can help to spread that gospel of the benefits of ActivityInfo in your organization.

Next, aiming for perfection. So it could be that you spend hours and days perfecting a particular form or a particular report and that might come at the cost of delaying the launch of your new system. And so people might get weary waiting for the official launch of what you're building. So as a way to overcome this is to just try and create a safe space for this implementation, for this rollout and pilot and iterate quickly. So don't aim for that perfect state right upfront. Give yourself that flexibility to launch with something that may be less than perfect so that you can launch it and start to get some real-world data points to suggest whether it's working well for your organization.

Next, lack of information sharing. So this is another common pitfall and can result in a lot of challenges in breeding that kind of resistance that we talked about at the start of this presentation. Without people knowing why you're doing this, what the expectations are, people will continue to resist the change. So a practical thing that you can do to overcome this is to actually create a communication plan where you have clear key messages that you want to share with your users, with your stakeholder groups, and have a plan in place as to when you're going to send out those key messages and in what channels those messages will be shared. And it's helpful to actually use multiple channels to get your messages across. You might send out a couple of email blasts, but also post some messages in your internal chat groups with different teams in your organization. It helps to have multiple touch points to get those messages across.

Then finally, another common pitfall would be inaccessible support. So it's really important to make sure that the support is very much accessible, especially in those first few weeks following the launch. You don't want to leave anyone frustrated in the process of submitting a record into this form. You don't want to disillusion them about this new system early on and not having anyone there to help guide them through that issue. So a practical way to overcome this is to establish support channels and think about actually creating different support channels across different medium that are relevant to your own organization and the way that you communicate within your organization. Again, posting in your chat groups or creating a dedicated email address where support questions can be raised and actually assigning key people in your team to be responsible for responding to those support questions as they come in.

00:48:30 Conclusion

So there we have it. We've covered some change management principles, why they're important. We've covered a practical framework for how you can roll out ActivityInfo within your own organizations. And we've covered some common pitfalls and how you might overcome them. So hopefully with these insights that I've shared with you today you can be empowered and feel more confident in now rolling out ActivityInfo to the rest of your team. So at this point, I'd like to wish you the best of luck in your journey with ActivityInfo. And we do hope that you're able to roll out ActivityInfo successfully to your teams.

So at this point we just wanted to make you aware that we do have an office hours session coming up on the 8th of March that's focused on managing your ActivityInfo implementation. So if you've got any questions at all about things like maintaining your database, supporting your users, or just generally managing the change that comes with rolling out ActivityInfo within your own organization, feel free to come to that office hour session. And we can have a broader discussion about some of those topics. So with that, that formally ends the presentation part of today's webinar. We've got a few minutes left to respond to any questions, if you've got any.