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