A question from Dominika Krupocin and myself—it would be great to get more than one response if you have different experiences!
Do you have any experience with implementing a new system (project / task management, CRM, other enterprise software). If so:
1.1. What advice would you give to those who are embarking on this process?
1.2. What were the main bottlenecks / difficulties that you came across?
1.3. What would you have done differently?
If you haven’t yet but are considering it:
2.1 What is your current approach?
2.2 What are your main challenges or uncertainties?
One general answer and one specific answer. (Numbering is my own and doesn’t correspond to your questions.)
When implementing a new system that will be used by a variety of people in your org, it’s important to make this as easy as possible for them. As Martin said, if you end up with one person who doesn’t want to use the system, this will greatly increase your work. When you’re choosing a new tool or system for people, you should assume that all of your new users don’t care about it, and that any time they have to spend learning the new system will be time they’d rather spend doing something else. To that end:
Don’t just ask people to read the software’s own published user guide. Even if it’s really great and you couldn’t imagine making anything better! People don’t want to click on links, they don’t want to go somewhere else and see new branding, they just want you to tell them what to do.
Do write specific instructions, in an email, as clearly and concisely as possible. Even if those instructions mirror the software’s user guide, it’s likely you can make them more concise because your instructions are for your org’s specific use case.
Do offer to help anyone who struggles with the new system. It’s unlikely anyone will take you up on this offer, but I think it makes people feel like you know they don’t want to do this thing you’re asking them to do.
Be ready for people to keep trying to use the old system. Keep trying to shepherd them into the new system. Don’t give up, don’t resign yourself to the two-system world. People will fail to see your first email, but happily respond to your follow-up. Seize opportunities to walk someone through a concrete example: Maybe they didn’t set up their Expensify account the first time, but now they’re asking for reimbursement, so you can (nicely, graciously) force them to use Expensify to get it.
BERI uses QuickBooks Online (QBO) as our accounting software. It works well enough, but has a lot of quirks that make certain things much more difficult and confusing than they have to be. Consequently, I’m (slowly, hesitantly) looking into other options, Aplos in particular. Obviously I’ll want to try out all of our normal transactions and reports in Aplos before transitioning. But even if all of that works out really well, one thing I’m very worried about is loss of audit trail: QBO keeps a record of every change to every transaction, including the time, date, and user. I’ve only used this occasionally, but when I have it’s been a lifesaver. I’m not sure how I’ll get around this if we start using Aplos, but it’s definitely something I’ll be keeping in mind. This concern would apply to any important piece of software that stores a complex history of interactions.
We use Slack, Asana, Greenhouse, Notion, and Expensify (which we use in collaboration with BERI). It’s worth trying out a few software options with a small team to see which one suits your needs the best. I’d suggest that you have 3 people try out one software at a time for 1-2 days to see what works. Software should be ultimately easy to use and easy to onboard new people seamlessly. Any kind of software that has a lot of complicated features and takes a long time to learn is likely not going to be great because if it’s complicated to use then new members will be less inclined to use it and the software will ultimately become useless. One bottleneck for software that I’ve encountered is making sure that everyone actually uses it. For example, if you are going to use a software for hiring purposes but one person in your team doesn’t want to use it or not willing to learn it, then things will likely get more complicated on your end as the person who is managing the software. Even if one person doesn’t use the software, your work will grow quite a bit since you have to balance 2 systems instead of one. It’s a simple thing to tell people who are looking into implementing software but it’s an important thing to emphasize. Some software are more flexible in terms of its use (i.e. modifying layout to suit their needs, etc) which may mitigate this problem a bit. As long as everyone is using it, then this should be fine. It’s worth documenting norms and rules related to any software and have new members read that document prior to using the software (although I often find norms surrounding software are fairly easy to grasp simply by using it for some period of time / intuitive). Another thing I’ll note about software is that software should be easy to use collaboratively and you should make sure that the software has the ability to tag different people, share documents easily, have multiple people comment on one project, etc. I suspect pretty much all software has this feature but it’s something to keep in mind nonetheless.
My general philosophy is that software is quite important to consider since it’s going to be much harder to shift your team to use a different software down the line. Suppose you choose a software somewhat haphazardly and you want to use a different one down the line, then it’s going to be quite hard to do so. I’ve often found people are reluctant when it comes to learning new software. The classic woodworking advice, “measure twice, cut once” is sort of the motto here. Also, for me, I try to keep using the same software as long as possible until a serious problem shows up. Like I mentioned before, getting an entire team to use a new software is tedious and takes a long time to implement and even if you do implement it, perhaps you will encounter problems with the software that you didn’t think about before you started to use it. There will always be new software that come out and some of them likely offer slight improvements compared to your current system but personally, unless those improvements are substantial, I ignore them.
Several months ago, our team all switched over to using Asana. Before that, some were using Asana, some Trello, and maybe some neither. I believe the switch-over went pretty smoothly and there wasn’t much resistance to using the new software. A few things that we did which may have contributed to the good adoption were:
Before selecting Asana, we asked staff to list all the features they’d like in a task management software, did research to compare a few options, and chose the one that met most (or maybe all) of staff’s requested features
We acknowledged that this is a big shift, it’ll take a few months for everyone to get comfortable with it, but that we expect greater efficiency in the long-run; expressed appreciation for staff doing the work necessary to figure out this new tool; reminded staff that this is the tool which meets most/all of their requested features
Wrote a guide about how to use it (I thought this didn’t seem very necessary, since Asana has lots of their own tutorials and instructions, but given Sawyer’s comment, maybe that helped!)
Together as a team over the first few months, we established conventions about how we use Asana, and documented those as a separate section in the guide (new staff read this guide as part of onboarding)
We held frequent (weekly?) coworking sessions for a little while, where we could ask each other questions about Asana and/or share tips
A question from Dominika Krupocin and myself—it would be great to get more than one response if you have different experiences!
Do you have any experience with implementing a new system (project / task management, CRM, other enterprise software). If so: 1.1. What advice would you give to those who are embarking on this process? 1.2. What were the main bottlenecks / difficulties that you came across? 1.3. What would you have done differently?
If you haven’t yet but are considering it: 2.1 What is your current approach? 2.2 What are your main challenges or uncertainties?
One general answer and one specific answer. (Numbering is my own and doesn’t correspond to your questions.)
When implementing a new system that will be used by a variety of people in your org, it’s important to make this as easy as possible for them. As Martin said, if you end up with one person who doesn’t want to use the system, this will greatly increase your work. When you’re choosing a new tool or system for people, you should assume that all of your new users don’t care about it, and that any time they have to spend learning the new system will be time they’d rather spend doing something else. To that end:
Don’t just ask people to read the software’s own published user guide. Even if it’s really great and you couldn’t imagine making anything better! People don’t want to click on links, they don’t want to go somewhere else and see new branding, they just want you to tell them what to do.
Do write specific instructions, in an email, as clearly and concisely as possible. Even if those instructions mirror the software’s user guide, it’s likely you can make them more concise because your instructions are for your org’s specific use case.
Do offer to help anyone who struggles with the new system. It’s unlikely anyone will take you up on this offer, but I think it makes people feel like you know they don’t want to do this thing you’re asking them to do.
Be ready for people to keep trying to use the old system. Keep trying to shepherd them into the new system. Don’t give up, don’t resign yourself to the two-system world. People will fail to see your first email, but happily respond to your follow-up. Seize opportunities to walk someone through a concrete example: Maybe they didn’t set up their Expensify account the first time, but now they’re asking for reimbursement, so you can (nicely, graciously) force them to use Expensify to get it.
BERI uses QuickBooks Online (QBO) as our accounting software. It works well enough, but has a lot of quirks that make certain things much more difficult and confusing than they have to be. Consequently, I’m (slowly, hesitantly) looking into other options, Aplos in particular. Obviously I’ll want to try out all of our normal transactions and reports in Aplos before transitioning. But even if all of that works out really well, one thing I’m very worried about is loss of audit trail: QBO keeps a record of every change to every transaction, including the time, date, and user. I’ve only used this occasionally, but when I have it’s been a lifesaver. I’m not sure how I’ll get around this if we start using Aplos, but it’s definitely something I’ll be keeping in mind. This concern would apply to any important piece of software that stores a complex history of interactions.
We use Slack, Asana, Greenhouse, Notion, and Expensify (which we use in collaboration with BERI). It’s worth trying out a few software options with a small team to see which one suits your needs the best. I’d suggest that you have 3 people try out one software at a time for 1-2 days to see what works. Software should be ultimately easy to use and easy to onboard new people seamlessly. Any kind of software that has a lot of complicated features and takes a long time to learn is likely not going to be great because if it’s complicated to use then new members will be less inclined to use it and the software will ultimately become useless. One bottleneck for software that I’ve encountered is making sure that everyone actually uses it. For example, if you are going to use a software for hiring purposes but one person in your team doesn’t want to use it or not willing to learn it, then things will likely get more complicated on your end as the person who is managing the software. Even if one person doesn’t use the software, your work will grow quite a bit since you have to balance 2 systems instead of one. It’s a simple thing to tell people who are looking into implementing software but it’s an important thing to emphasize. Some software are more flexible in terms of its use (i.e. modifying layout to suit their needs, etc) which may mitigate this problem a bit. As long as everyone is using it, then this should be fine. It’s worth documenting norms and rules related to any software and have new members read that document prior to using the software (although I often find norms surrounding software are fairly easy to grasp simply by using it for some period of time / intuitive). Another thing I’ll note about software is that software should be easy to use collaboratively and you should make sure that the software has the ability to tag different people, share documents easily, have multiple people comment on one project, etc. I suspect pretty much all software has this feature but it’s something to keep in mind nonetheless.
My general philosophy is that software is quite important to consider since it’s going to be much harder to shift your team to use a different software down the line. Suppose you choose a software somewhat haphazardly and you want to use a different one down the line, then it’s going to be quite hard to do so. I’ve often found people are reluctant when it comes to learning new software. The classic woodworking advice, “measure twice, cut once” is sort of the motto here. Also, for me, I try to keep using the same software as long as possible until a serious problem shows up. Like I mentioned before, getting an entire team to use a new software is tedious and takes a long time to implement and even if you do implement it, perhaps you will encounter problems with the software that you didn’t think about before you started to use it. There will always be new software that come out and some of them likely offer slight improvements compared to your current system but personally, unless those improvements are substantial, I ignore them.
Several months ago, our team all switched over to using Asana. Before that, some were using Asana, some Trello, and maybe some neither. I believe the switch-over went pretty smoothly and there wasn’t much resistance to using the new software. A few things that we did which may have contributed to the good adoption were:
Before selecting Asana, we asked staff to list all the features they’d like in a task management software, did research to compare a few options, and chose the one that met most (or maybe all) of staff’s requested features
We acknowledged that this is a big shift, it’ll take a few months for everyone to get comfortable with it, but that we expect greater efficiency in the long-run; expressed appreciation for staff doing the work necessary to figure out this new tool; reminded staff that this is the tool which meets most/all of their requested features
Wrote a guide about how to use it (I thought this didn’t seem very necessary, since Asana has lots of their own tutorials and instructions, but given Sawyer’s comment, maybe that helped!)
Together as a team over the first few months, we established conventions about how we use Asana, and documented those as a separate section in the guide (new staff read this guide as part of onboarding)
We held frequent (weekly?) coworking sessions for a little while, where we could ask each other questions about Asana and/or share tips